[Python-Dev] When should pathlib stop being provisional?

[Brett Cannon]

On Wed, 6 Apr 2016 at 14:03 Wes Turner <wes.turner at gmail.com> wrote:

>
> On Apr 6, 2016 12:47 PM, "Brett Cannon" <brett at python.org> wrote:
> >
> >
> >
> > On Wed, 6 Apr 2016 at 10:41 Wes Turner <wes.turner at gmail.com> wrote:
> >>
> >> * +1 for __path__, __fspath__
> >>   (though I don't know what each does)
> >
> >
> > Returns a string representing a file system path.
>
> Why two methods? __uripath__?
>
> (scheme, host (port), path, query, fragment) so, not __uripath__
>
> what would be the difference between __path__ and __fspath__?
>

There is no difference; we're trying to choose a name.


> >
> >>
> >> * why not Text(basestring / bytestring) and pathlib.Path(Text)?
> >
> >
> > See the points about next() vs __next__()
>
> Path(b'123') / u'456'
>
> similarly,
> Path(b'123') / UTF8 / UTF16
>

As other people pointed out on the other thread, while bytes paths do
exist, we don't want to promote them as they are a mess to work with.

-Brett


> >
> >>
> >>    * are there examples of cases where this cannot be?
> >
> >
> > I don't understand what you think "cannot be".
>
> What one recommends (path.py(str) / str(pathlib.Path()) + getattr) is
> distinct from what any given programmer chooses to do with their code.
>
> >
> >>
> >>       * if not, +1 for subclassing str/Text
> >>
> >>       * where are the examples of method collisions between the str
> interface and the pathlib.Path interface?
> >
> >
> > There aren't any and that's partially why some people wanted the str
> subclass to begin with.
> >
> > Please consider this thread a str-subclass-free zone. This line of
> discussion is to flesh out the proposal for a path protocol as a proposal
> against subclassing str, not to settle the whole discussion outright. If
> you want to continue to debate the subclassing-str side of this please use
> the other thread.
>
> this seems to be a sudden, arbitrary distinction.
>
> are these proposals necessarily disjoint?
>
> so,
> adding getattr(path, '__path__', path) to stdlib and other code is going
> to prevent which edge cases (before  os.path.normpath()* anyway) for which
> benefit?
>
> when do I do getattr(path, '__fspath__', path)?
>
> >
> > -Brett
> >
> >>
> >>          * str.__div__ is nonsensical
> >>          * pathlib.Path.__div__ is super-useful
>
> ah, not .__add__() but .append()
>
> I suppose the request here is for the cases which would be prevented (that
> we need to learn to look for)
>
> >>
> >>
> >>
> >> On Apr 6, 2016 10:10 AM, "Ethan Furman" <ethan at stoneleaf.us> wrote:
> >>>
> >>> On 04/05/2016 11:57 PM, Nick Coghlan wrote:
> >>>>
> >>>> On 6 April 2016 at 16:53, Nathaniel Smith <njs at pobox.com> wrote:
> >>>>>
> >>>>> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan <ncoghlan at gmail.com>
> wrote:
> >>>
> >>>
> >>>>>> I'd missed the existing precedent in DirEntry.path, so simply taking
> >>>>>> that and running with it sounds good to me.
> >>>>>
> >>>>>
> >>>>> This makes me twitch slightly, because NumPy has had a whole set of
> >>>>> problems due to the ancient and minimally-considered decision to
> >>>>> assume a bunch of ad hoc non-namespaced method names fulfilled some
> >>>>> protocol -- like all .sum methods will have a signature that's
> >>>>> compatible with numpy's, and if an object has a .log method then
> >>>>> surely that computes the logarithm (what else in computing could
> "log"
> >>>>> possibly refer to?), etc. This experience may or may not be relevant,
> >>>>> I'm not sure -- sometimes these kinds of twitches are good guides to
> >>>>> intuition, and sometimes they are just knee-jerk responses to an old
> >>>>> and irrelevant problem :-)
> >>>>>
> >>>>> But you might want to at least think about
> >>>>> how common it might be to have existing objects with unrelated
> >>>>> attributes that happen to be called "path", and the bizarro problems
> >>>>> that might be caused if someone accidentally passes one of them to a
> >>>>> function that expects all .path attributes to be instances of this
> new
> >>>>> protocol.
> >>>>
> >>>>
> >>>> sys.path, for example.
> >>>>
> >>>> That's why I'd actually prefer the implicit conversion protocol to be
> >>>> the more explicitly named "__fspath__", with suitable "__fspath__ =
> >>>> path" assignments added to DirEntry and pathlib. However, I'm also not
> >>>> offering to actually *do* the work here, and the casting vote goes to
> >>>> the folks pursuing the implementation effort.
> >>>
> >>>
> >>> If we decide upon __fspath__ (or __path__) I will do the work on
> pathlib and scandir to add those attributes.
> >>>
> >>> --
> >>> ~Ethan~
> >>> _______________________________________________
> >>> Python-Dev mailing list
> >>> Python-Dev at python.org
> >>> https://mail.python.org/mailman/listinfo/python-dev
> >>>
> >>> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
> >>
> >> _______________________________________________
> >> Python-Dev mailing list
> >> Python-Dev at python.org
> >> https://mail.python.org/mailman/listinfo/python-dev
> >> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160406/e0758efe/attachment.html>