PyWart: os.path needs immediate attention!

[Robert Kern]

Guido has a rule of thumb: "No constant arguments". Or another way to put
it: if a function takes an argument which is nearly always a constant
(usually, but not always, a flag) then it is usually better off as two
functions.

That's not quite right (although I can never find a direct quote from Guido
whenever I need to dissect the niceties of the rule). The rule of thumb is more
like: "No literal arguments." That is, if you are typically going to use True
and False literals for a flag, it's better to have two functions. However, if
you have a suite of interoperating functions with the same flag argument, and
one might reasonably want to pass the same flag value to several different calls
using a variable, that's a reasonable use.

But having said that, I'm currently writing a library where nearly all the
functions violate the No Constant Argument rule. (The API isn't yet stable,
so I may still change my mind.) Make of that what you will.

I suspect this may be an instance of the latter case.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Teemu Likonen]

Been there, done that, floundered on the inability of people to work
out the details.

http://www.python.org/dev/peps/pep-0355/

I'm very much a Lisp person and obviously got the idea of pathname
objects from Common Lisp. Lazily I'm also learning Python too but at the
moment I can't comment on the details of that PEP. Yet, generally I
think that's the way to improve pathnames, not the "rantinrick's".

 

[rantingrick]

I'm very much a Lisp person and obviously got the idea of pathname
objects from Common Lisp. Lazily I'm also learning Python too but at the
moment I can't comment on the details of that PEP. Yet, generally I
think that's the way to improve pathnames, not the "rantinrick's".

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.

Some have said "been there, done that" with a sarcastic and defeatist
point of view. I say we need to re-visit the proposal of PEP-0355 and
hash out something quickly. We also need to realize that one day or
another this Path object is going to become reality and the longer we
drag our feet getting it implemented the more painful the transition
is going to be.

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!

 

[Chris Angelico]

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

 

[alex23]

He hasn't replied to his last two troll threads, though. It does seem
odd to write a wall of text and then not respond to replies. To be fair,
though, most replies either mock him or point out that he's a troll.

His recent rants do seem a lot more Xah-Lee-like; a huge nonsensical
diatribe that badly applies logic to try and mask its emotive agenda.
A lot of the same "great mind struggling against the tyranny of
idiots" subtext too.

Not so much swearing though.

 

[Gelonida N]

Just tested this: You can type c:/foldername into the box at the top
of a folder in Explorer, and it works. It will translate it to
c:\foldername though.

We are not here to talk solely to OSes. We are here primarily to talk
to users. If you want to display a path to the user, it's best to do
so in the way they're accustomed to - so on Windows, display
backslashes.

well normcase might help to find out, whether two filenames are the same.


under unix 'myfile' and 'myFile' would be different
under windows they would refer to the same file.

normcase (perhaps to be combined with normpath) can tel you this.