<div class="gmail_quote">On Mon, Oct 8, 2012 at 1:59 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On Sat, Oct 6, 2012 at 9:44 PM, Calvin Spealman <<a href="mailto:ironfroggy@gmail.com">ironfroggy@gmail.com</a>> wrote:<br>
> Responding late, but I didn't get a chance to get my very strong<br>
> feelings on this proposal in yesterday.<br>
><br>
> I do not like it. I'll give full disclosure and say that I think our<br>
> earlier failure to include the path library in the stdlib has been a<br>
> loss for Python and I'll always hope we can fix that one day. I still<br>
> hold out hope.<br>
><br>
> It feels like this proposal is "make it object oriented, because<br>
> object oriented is good" without any actual justification or obvious<br>
> problem this solves. The API looks clunky and redundant, and does not<br>
> appear to actually improve anything over the facilities in the os.path<br>
> module. This takes a lot of things we can already do with paths and<br>
> files and remixes them into a not-so intuitive API for the sake of<br>
> change, not for the sake of solving a real problem.<br>
<br>
The PEP needs to better articulate the rationale, but the key points are:<br>
- better abstraction and encapsulation of cross-platform logic so file<br>
manipulation algorithms written on Windows are more likely to work<br>
correctly on POSIX systems (and vice-versa)<br></blockquote><div><br>Frankly, for 99% of file path work, anything I do on one "just works" on the other, and complicating things with these POSIX versus NT path types just seems to be a whole lot of early complication for a few edge cases most people never see.<br>

<br>Simplest example is requiring the backslash separator on NT when it handles forward slash, just like POSIX, just fine, and has for a long, long time.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


- improved ability to manipulate paths with Windows semantics on a<br>
POSIX system (and vice-versa)<br>
- better support for creation of "mock" filesystem APIs<br></blockquote><div><br>I admit the mock FS intrigues me<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



> As for specific problems I have with the proposal:<br>
><br>
> Frankly, I think not keeping the / operator for joining is a huge<br>
> mistake. This is the number one best feature of path and despite that<br>
> many people don't like it, it makes sense. It makes our most common<br>
> path operation read very close to the actual representation of the<br>
> what you're creating. This is great.<br>
<br>
It trades readability (and discoverability) for brevity. Not good.<br></blockquote><div><br>I thought it had all three. In these situations, where my and another's perception of a systems strengths and weaknesses are opposite, I don't really know how to make a good response. :-/ <br>

<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Not inheriting from str means that we can't directly path these path<br>
> objects to existing code that just expects a string, so we have a<br>
> really hard boundary around the edges of this new API. It does not<br>
> lend itself well to incrementally transitioning to it from existing<br>
> code.<br>
<br>
It's the exact design philosophy as was used in the creation of the<br>
new ipaddress module: the objects in ipaddress must still be converted<br>
to a string or integer before they can be passed to other operations<br>
(such as the socket module APIs). Strings and integers remain the data<br>
interchange formats here as well (although far more focused on strings<br>
in the path case).<br>
<br>
><br>
> The stat operations and other file-facilities tacked on feel out of<br>
> place, and limited. Why does it make sense to add these facilities to<br>
> path and not other file operations? Why not give me a read method on<br>
> paths? or maybe a copy? Putting lots of file facilities on a path<br>
> object feels wrong because you can't extend it easily. This is one<br>
> place that function(thing) works better than thing.function()<br>
<br>
Indeed, I'm personally much happier with the "pure" path classes than<br>
I am with the ones that can do filesystem manipulation. Having both<br>
"p.open(mode)" and "open(str(p), mode)" seems strange. OTOH, I can see<br>
the attraction in being able to better fake filesystem access through<br>
the method API, so I'm willing to go along with it.<br>
<br>
> Overall, I'm completely -1 on the whole thing.<br>
<br>
I find this very hard to square with your enthusiastic support for<br>
path.py. Like ipaddr, which needed to clean up its semantic model<br>
before it could be included in the standard library (as ipaddress), we<br>
need a clean cross-platform semantic model for path objects before a<br>
convenience API can be added for manipulating them.<br><div class="HOEnZb"><div class="h5"></div></div></blockquote><div><br>I somewhat dislike this because I loved path.py so much and this proposal seems to actively avoid exactly the aspects of path.py that I enjoyed the most (like the / joining).<br>

 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
Cheers,<br>
Nick.<br></div></div></blockquote></div><br>path.py was in teh wild, and is still in use. Why do we find ourselves debating new libraries like this as PEPs? We need to let them play out, see what sticks. If someone wants to make this library and stick it on PyPI, I'm not stopping them. I'm encouraging it. Let's see how it plays out. if it works out well, it deserves a PEP. In two or three years.<br clear="all">

<br>-- <br>Read my blog! I depend on your acceptance of my opinion! I am interesting!<br><a href="http://techblog.ironfroggy.com/">http://techblog.ironfroggy.com/</a><br>Follow me if you're into that sort of thing: <a href="http://www.twitter.com/ironfroggy">http://www.twitter.com/ironfroggy</a><br>