Library philosophy

Robin Becker robin at jessikat.demon.co.uk
Fri Aug 27 03:40:35 CEST 1999


In article <14277.39227.719967.140778 at dolphin.mojam.com>, Skip Montanaro
<skip at mojam.com> writes
>
...
>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
interestingly tcl took exactly the opposite view recently with sensible
stuff being  deferred or reduced to common denominators. The sockets
stuff was brain dead on windows etc etc. The commands looked the same,
but often there were hidden semantic/operational differences. Tk on the
other hand has been moving the opposite way. Instead of one look for all
platforms we get more and more 'native' behaviour.
>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.
>
me too
-- 
Robin Becker




More information about the Python-list mailing list