RetroSearch Browse

Sat May 6 08:29:36 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-May/064896.html

On 5/5/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Mike Orr wrote:
> > On 5/4/06, Paul Moore <p.f.moore at gmail.com> wrote:
> >> (But all the current proposals seem to build on os.path, so maybe I
> >> should assume otherwise, that os.path will remain indefinitely...)
> >
> > They build on os.path because that's what we're familiar with using.
> > There's no reason to write the platform-specific classes until we
> > agree on an API; that would just be work down the drain.  When the new
> > classes are in the library, we can:  (one or more)
> >
> > - Leave os.path.foo() alone because it works and most existing programs need it.
>
> The threading module doesn't really obsolete the thread module, it just
> provides a higher level, more convenient API.
>
> Similarly, I don't believe it's a given that a nice path object will obsolete
> the low level operations. When translating a shell script to Python (or vice
> versa), having access to the comparable low level operations would be of benefit.

I think you meant to say Perl in that sentence.  In Python there
should be one way to do it, and beautiful is better than ugly.  The
os.path functions are bad enough, but shutil.copy2 is just plain evil.
   Is it that much of a step to translate:

    Y="$(dirname $(dirname $X))/lib"

as

    y = Path(x).parent.parent + "lib"
    y = Path(x).parent.parent.join("lib")
    or whatever the syntax do jour is

rather than

    y = os.path.join(os.path.dirname(os.path.dirname(x)), "lib")

?

--
Mike Orr <sluggoster at gmail.com>
(mso at oz.net address is semi-reliable)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-May/064896.html below:

[Python-Dev] Alternative path suggestion