PRE-PEP: new Path class; open, openwith, __call__
webmaster at beyond-thoughts.com
Thu Jan 8 21:55:27 CET 2004
Gerrit Holl wrote:
> Christoph Becker-Freyseng wrote:
>>openwith would be a nice add-on. I see two problems with it:
>>1.) it's long. I mean
>> f(str(path), *args)
>> is shorter than
>> path.openwith(f, *args)
> This is indead a disadvantage. On the other hand, although p.openwith is
> longer, I do think it is more readable. It occurs often that shorter is
> not more readable: just think of all those 'obfuscated-oneliners'
> contests in C and Perl.
Sure. However this case seems to be quite obvious both ways.
>>path > (f, arg1, arg2, ...)
>>(this works by overwriting path.__gt__)
> I think this is not a good idea. In my opinion, any __gt__ method should
> always compare, no more, no less. Further, it's very unusal to call
> something like this.
Additionaly getting the right documentation for these "operator-tricks"
> Another possibility is defining __call__:
> path(f, *args) == f(str(path), *args)
> which may be unconvinient as well, however. Is it intuitive to let
> calling mean opening?
I like this one. What else could calling a path mean?
>>2.) the position of the argument for the path can only be the first one.
>>(maybe one could misuse even more operators e.g. the __r...__ ones; But
>>I think this will result in obscure code)
> Hm, I think almost all file constructors have the path as the first
> argument. Are there counter-examples?
The whole openwith (other then path.open) is IMO mainly for
"backward-compatibility" if the function doesn't know the path-class.
I think openwith or better __call__ could be used for other things, too
--- not only for opening a file. E.g. there could be some
"FileWatcher-Modules" that might only accept strings and have a call like:
For different postition of the path_string we could make a special case
if the path-object is given as an argument of the call.
path(f, arg1, arg2, path, arg3, arg4, ...)
results in: f(arg1, arg2, str(path), arg3, arg4, ...)
Changing old code to use the new Path-class could be done with a minimal
amount of work then.
OLD: result= f(arg1, arg2, path, arg3, arg4, ...) # path is/was a string
.... result= f,arg1, arg2, path, arg3, arg4, ...)
.... result= (f, arg1, arg2, path, arg3, arg4, ...)
NEW: result= path(f, arg1, arg2, path, arg3, arg4, ...)
>>path.open shouldn't always call the ordinary file-constructor. I mean it
>>should be changed for special path-classes like FTPPath ...
>>(Of course for ordinary file-paths the ordinary file-class is the right
> Yes... I was planning to define it in a class which is able to 'touch'
> the filesystem, so an FTPPath could subclass basepath without the need
> to overload open, or subclass ReadablePath with this need.
P.S.: ((I'll post the other things in different Re:'s))
More information about the Python-list