SV: Python Productivity over C++

David Bolen db3l at fitlinxx.com
Wed Jun 14 16:04:22 EDT 2000


Thomas Thiele <thiele at muc.das-werk.de> writes:

> But there is no mechanism to ensure that the behaviour of your
> memfileobjectsis like a fileobject. For instance if you don't note
> that you forgot to write the write()-function.  In a worst case
> scenario it works for many months until a user calls a function in
> which the write() -function is needed.

I think there are probably both good and bad points to this very fact.

On the bad side I agree that there is no explicit mechanism to support
the verification of interfaces (e.g., it's not like inheriting from an
abstract base class in C++ where you'll get a compiler error if you
don't provide an implementation for each method).  So if you want that
validation, there's no built-in method to ensure it.  You could roll
your own pretty easily with introspection and some definition of what
you needed to validate as supported by the class, but that's extra work.

On the good side, it means you aren't absolutely wedded to the
interface in cases where you know you won't need it, and can produce a
useful partial implementation to get the ball rolling.  For example, I
don't have to implement every file object method to create or use an
object to replace sys.stdout - just having a "write" is enough.  This
contributes to more efficiency during prototyping and interative
development.  And as you continue to build out, it isn't really that
much effort to ensure that you conform to the interface.

But I do admit that some additional built-in method of indicating
interfaces supported by a class might be nice.  Of course you can
probe for whatever set of functions you may need if you are the user
of the class, but it would be nice to encapsulate a set of probes
based on an interface definition - or something along those lines.
I'm not that familiar with it, but Ruby's approach of including
modules into classes (where the module is basically the interface
definition) seems interesting.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/



More information about the Python-list mailing list