Library philosophy

[Skip Montanaro]

    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...