PyWart: os.path needs immediate attention!

[Chris Angelico]

On Tue, Aug 2, 2011 at 5:03 PM, rantingrick <rantingrick at 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