Many of the tempfile modules' classes and utils could maybe return
Path instead of str. I'm not sure how disruptive that would be, but I
would definitely welcome something that avoids having to wrap
everything in Path.
I think they might need to return a "StrPath" for compatibility, but
IMHO only
On Thu, Aug 20, 2020 at 9:08 PM Ethan Furman wrote:
> > But for a while is was painful to use, 'cause there was som much code
> > that still used strings for paths. That was made a lot better when we
> > introduced the __fspath__ protocol, and then updated the standard
> > library to use it
On 8/20/20 6:06 PM, Christopher Barker wrote:
But for a while is was painful to use, 'cause there was som much code
that still used strings for paths. That was made a lot better when we
introduced the __fspath__ protocol, and then updated the standard
library to use it (everywhere?).
For the specific case of `__file__`, yes, I think that would be too
disruptive. This isn't a function that *consumes* a path -- it's a path
that is consumed by innumerable other modules, most of which aren't under
active maintenance, and a sizable fraction of those would break if this
turned into
I have no idea how hard/bad/maintenance heavy this would be, but wouldn't
the easy way be simply to provide another attribute (e.g. __path__) with
what you want and maintain __file__?
I've never used a Path object (directly), I feel like I'm missing out now!
On Fri, 21 Aug 2020 at 02:09,
What about code that depends on __file__ to add installation dependent import
paths to sys.path? I have written code like that myself, and I've seen it
elsewhere too.
--Edwin
On 8/20/2020 9:06 PM, Christopher Barker wrote:
> I really like pathlib.
>
> But for a while is was painful to use,
