Library philosophy

C.Laurence Gonsalves clgonsal at keeshah.penguinpowered.com
Sat Aug 28 03:29:29 EDT 1999


On Thu, 26 Aug 1999 17:33:52 GMT, Paul Prescod <paul at prescod.net> wrote:
> I am curious about the opinions of Python community members on the
> following issue:
> 
> I believe that Python's libraries are in many places too thin of a layer
> on top of the C library and are thus not very Pythonish. Evidence of
> this includes indecipherable function names like strtfmt and APIs that
> return tuples instead of objects and take integers as "flags" instead of
> strings or objects.
> 
> Would it it make sense to start wrapping the low-level modules with
> high-level, easier to use modules that would be "the default" in Python
> 2?

Hi Paul. :-)

I have to agree. Many of the standard modules seem *very* thin to me. I
won't name names, but many of the "Internet Protocols and Support"
modules essentially require that you know a lot of gory details about
the protocols that they attempt to encapsulate.

I don't think there should just be high-level modules though. I think a
two-(or more)-tiered approach would work better. The low-level modules
would act as a bare wrapper for the protocol, API, or whatever it is
they encapsulate, not hiding any implementation details. Other modules
could contain high-level classes that use the low-level modules.

This would be useful not just for backwards compatibility with the
existing low-level modules, but it would also allow for those cases
where the high level module unfortunately abstracts a bit too much.
(which will probably be the case a lot, until the high-level interfaces
have matured)

There are also some protocols which are inherently broken, and it would
be very hard to create a high-level interface to them that works all of
the time. FTP is a prime example of this. (darn, I said I wouldn't name
names...) 

Ever try using a VMS FTP server? Blech... FTP unfortunately does not
hide many details about the server from the client. The client is
responsible for knowing things like "what do pathnames look like" and
"what format will LIST return stuff in". Nasty...

As others have mentioned, making the high-level modules will require a
lot of work in terms of API design, as well as documentation.

-- 
  C. Laurence Gonsalves            "Any sufficiently advanced
  clgonsal at kami.com                 technology is indistinguishable
  http://www.cryogen.com/clgonsal/  from magic." -- Arthur C. Clarke




More information about the Python-list mailing list