On 5/5/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mike Orr wrote:
> > On 5/4/06, Paul Moore <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
([EMAIL PROTECTED] address is semi-reliable)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
