skip at mojam.com
Thu Aug 26 21:52:24 CEST 1999
Paul> I believe that Python's libraries are in many places too thin of a
Paul> layer on top of the C library and are thus not very
Paul> Pythonish. Evidence of this includes indecipherable function names
Paul> like strtfmt and APIs that return tuples instead of objects and
Paul> take integers as "flags" instead of strings or objects.
This is a known issue. I'll put words in g--d-'s mouth (and let him take
them out when he returns) once again and indicate that the thin libraries
were made that way on purpose. I can't pretend to understand all the
reasons that is the case, but it appears to be a pretty consistent approach.
It also makes the most sense to me when you are exposing a C API with an
extension module. If you come up with some higher-level classes (e.g. a
logical filesystem that doesn't expose chmod and friends and that acts
uniformly across different OS platforms), my guess is that it would be
looked upon favorably.
Paul> Would it it make sense to start wrapping the low-level modules
Paul> with high-level, easier to use modules that would be "the default"
Paul> in Python 2?
Makes good sense to me.
Skip Montanaro | http://www.mojam.com/
skip at mojam.com | http://www.musi-cal.com/~skip/
847-971-7098 | Python: Programming the way Guido indented...
More information about the Python-list