On 04/06/2016 08:50 PM, Chris Barker wrote: > On Wed, Apr 6, 2016 at 5:57 PM, Ethan Furman wrote: >> It's mostly for the stdlib itself. I imagine that most libraries >> would just take what they are given and pass it along to open or >> os.stat or whatever. > > Exactly -- so we really don't need a builtin shortcut. Hey, we have to program the stdlib too! No need to make it harder for ourselves. >> It would be more along the lines of pickle -- give me the standard >> serialized form of this Path, please. > > well, give me the standard serialized-path of this arbitrary object, > yes? Yes. :) >> We are imagining that future libraries that have to muck about with >> paths will work with Path objects, either by accepting them or >> converting to them as the (possibly) stringified paths are passed in >> -- and when necessary those libs can pass either the Path obj or the >> stringified path to the stdlib. > > if that's the case, we don't need the __fspath__ protocol -- then > reason for the protocol is that we imagine there may be any number of > third-party objects to represent/work-with paths, that aren't strings > or stdlib Path objects. The purpose of the __os_path__ method is two-fold: - it's presence declares that the object is a path (or convertible to one) - it does the conversion Since we need it for ourselves there's no reason to prevent others from taking advantage of it. >> The point is to allow future programs to work with Path and be able >> to work with the stdlib as seamlessly and painlessly as possible. > > again, we don't need a new protocol for that -- we only need the > protocol if we want arbitrary future programs to work with arbitrary > path implementations. I am certainly not opposed to that. > which I suppose we do -- there are already other path implimentaitons > out there (though at least some are strings :-) ) Right. And I'm already making changes to mine to work with this new stuff. > People can totally screw up path variables as strings or Path objects > too -- I'm having trouble seeing that this is all that more likely -- > after all, python is a dynamic language -- if we wanted full type > safety, we wouldn't be using python... Very True. ;) > Speaking of which, how is this going to work with the new type > system? Do we need an ABC, rather than just a protocol? I do not know, good question. > But as long as we get to the stdlib taking Path objects, I'm happy :-) Excellent! -- ~Ethan~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4