Re: [path-PEP] Path inherits from basestring again
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


comp.lang.python archive

Re: [path-PEP] Path inherits from basestring again

From: phil hunt <zen19725@zen.co.uk>
Date: Sun Jul 31 2005 - 11:18:25 CEST

On Sun, 31 Jul 2005 09:48:45 +0200, Reinhold Birkenfeld <reinhold-birkenfeld-nospam@wolke7.net> wrote:
>>
>> An improvement to what? To how the class is implemented, or to how
>> it is used?
>
>No, the second function is cleaner and more readable than the first,
>IMHO.

True, but the first function, at all of seven lines, is hardly
complicated. I mean, if anyone couldn't understand it, they'd never
make a programmer.

>> If you mean the former, yes is it, due to the os.path module not
>> providing a function that does this.
>>
>> If you mean the latter, I disagree, because I would then have to
>> call it with something like:
>>
>> pn = normalizePath(Path(p), q)
>
>That's easily helped by s/tp = p/tp = Path(p)/.

I have no idea what that comment means.

>> and then I would have the problem that (pn) isn't a string so
>> calling a function to write some data into the file at that filename
>> would no longer work, i.e. this:
>>
>> writeFile(pn, someData)
>>
>> would become this:
>>
>> writeFile(pn.getString(), someData)
>
>Why? A Path is a string.

Aha, having read about path on the web, I know that now.

I also withdraw my objections; it looks like it could well have been
useful on some of the projects I've worked on.

-- 
Email: zen19725 at zen dot co dot uk
Received on Thu Sep 29 17:17:12 2005