[Python-ideas] PEP 428 - object-oriented filesystem paths

[Ethan Furman]

Antoine Pitrou wrote:
> On Sun, 14 Oct 2012 07:50:06 -0700
> Ethan Furman <ethan at stoneleaf.us> wrote:
>   
>> Steven D'Aprano wrote:
>>     
>>> On 14/10/12 22:03, Antoine Pitrou wrote:
>>>       
>>>> On Sun, 14 Oct 2012 21:48:59 +1100
>>>> Steven D'Aprano<steve at pearwood.info> wrote:
>>>>         
>>>>> Ah, I wondered if anyone else had picked up on that. When I read the 
>>>>> PEP,
>>>>> I was concerned about the mental conflict between iteration and 
>>>>> indexing
>>>>> of Path objects: given a Path p the sequence p[0] p[1] p[2] ... does
>>>>> something completely different from iterating over p directly.
>>>>>           
>>>> p[0] p[1] etc. are just TypeErrors:
>>>>         
>>> Ah, my mistake... I didn't register that you sequenced over the parts
>>> attribute, not the path itself. Sorry for the noise.
>>>
>>>
>>>
>>>       
>> I actually prefer Steven's interpretation. If we are going to iterate 
>> directly on a path object, we should be yeilding the pieces of the path 
>> object.
>> After all, a path can contain a file name (most of mine do) and 
>> what sense does it make to iterate over the children of 
>> /usr/home/ethanf/some_table.dbf?
>>     
>
> Well, given that:
>
> 1. sequence access (including the iterator protocol) to the path's
> parts is already provided through the ".parts" property
>
> 2. it makes little sense to actually iterate over those parts (what
> operations are you going to do sequentially over '/', then 'home', then
> 'ethanf', etc.?)
>
> ... I think yielding the directory contents is a much more useful
> alternative when iterating over the path itself.
>
> Regards
>
> Antoine.
>   
Useful, sure.  Still potentially confusing.  I'm perfectly happy with 
not allowing any default iteration at all.

What behavior can I expect with your Path implementation when I try to 
iterate over

/usr/home/ethanf/some_table.dbf

?

~Ethan~