On Tue, Aug 2, 2011 at 5:03 PM, rantingrick <rantingr...@gmail.com> wrote: > This thread was intended to expose another PyWart and get the > community juices flowing. os.path is broken and cannot be repaired > because os.path was an improper API to begin with. The only way to > solve this problem is to introduce a new Path object. > > A new Path object is the answer.
http://xkcd.com/927/ > I feel Python community is in an awkward teenage stage at this point > not really sure of it's self or direction. Living only for today with > no ability to project the future and wasting too much time arguing > over minutiae. We need a collective wake-up-call in the form of a slap > on the face. We need to start making the hard choices necessary to > clean up this library. > > Python3000 was only the beginning! ONLY THE BEGINNING! Some of us have reached the level of maturity necessary to understand that stability is valuable. Also to notice when requirements internally conflict - how are we going to develop the One Perfect API without spending a lot of time arguing minutiae? One thing I have learned in life is that mature products have their warts for a reason, and that reason is usually compatibility. That's not necessarily a good thing, but nor is it necessarily bad. For instance, the Python source code is managed by automake. We could save ourselves a LOT of trouble by simply moving to the future - a future in which Linux is the only operating system we bother with, that 64-bit hardware and 64-bit OSes are everything, and so on. Why bother supporting the past? But that "past" is actually a huge part of the world today, too. Large-scale adoption is an incredibly valuable thing, and you are narrowing your adoption potential considerably if you do not support these things. As an example, have you ever noticed how horribly useless and skeletal the Python documentation is? Neither have I. It's used by so many people that it gets eyeballs, and therefore time, to fix up its failings. Compare with Pike, a much more obscure language (syntactically similar to C, but under the covers quite similar to Python); scroll down this list of constants from its Stdio module: http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/Stdio.html A good number of them simply say FIXME, and even those that _are_ documented have only brief explanations. For quite a few things, you need to go direct to the language's source code. (Do a docs search for FIXME and you'll find that this is not an isolated case.) That doesn't happen with Python, largely a consequence (if somewhat indirectly) of its being so widely used. Sure you can make your life easier. But is it really better? Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
