PRE-PEP: new Path class; open, openwith, __call__

[Christoph Becker-Freyseng]

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" 
is harder.
> 
> 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:
watchFile(onChangeFunc, path_string)

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 
here
.... 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 
>>one.)
> 
> 
> 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.
Fine :-)


Christoph Becker-Freyseng


P.S.: ((I'll post the other things in different Re:'s))