[issue24132] Direct sub-classing of pathlib.Path

Barney Gale added the comment: If/when GH-31691 lands, I think this bug can be resolved: the original repro case will no longer raise AttributeError, and subclasses will be able to customize behaviour without needing to define further "flavour" or "accessor" subclasses. --

[issue24132] Direct sub-classing of pathlib.Path

Change by Barney Gale : -- pull_requests: +29812 pull_request: https://github.com/python/cpython/pull/31691 ___ Python tracker ___ _

[issue24132] Direct sub-classing of pathlib.Path

Change by Barney Gale : -- pull_requests: +29269 pull_request: https://github.com/python/cpython/pull/31085 ___ Python tracker ___ _

[issue24132] Direct sub-classing of pathlib.Path

miss-islington added the comment: New changeset 08f8301b21648d58d053e1a513db8ed32fbf37dd by Barney Gale in branch 'main': bpo-43012: remove `pathlib._Accessor` (GH-25701) https://github.com/python/cpython/commit/08f8301b21648d58d053e1a513db8ed32fbf37dd -- nosy: +miss-islington

[issue24132] Direct sub-classing of pathlib.Path

Change by Éric Araujo : -- versions: +Python 3.11 -Python 3.10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24132] Direct sub-classing of pathlib.Path

Richard added the comment: I agree this would be nice. For now, I'm doing this as a hack: class Path(type(pathlib.Path())): ... -- nosy: +nyuszika7h ___ Python tracker __

[issue24132] Direct sub-classing of pathlib.Path

Change by Kevin Follstad : -- pull_requests: +25482 pull_request: https://github.com/python/cpython/pull/26906 ___ Python tracker ___ __

[issue24132] Direct sub-classing of pathlib.Path

Change by Barney Gale : -- pull_requests: +25298 pull_request: https://github.com/python/cpython/pull/26708 ___ Python tracker ___ _

[issue24132] Direct sub-classing of pathlib.Path

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.o

[issue24132] Direct sub-classing of pathlib.Path

Change by Kevin Follstad : -- nosy: +kfollstad nosy_count: 11.0 -> 12.0 pull_requests: +25030 pull_request: https://github.com/python/cpython/pull/26438 ___ Python tracker ___

[issue24132] Direct sub-classing of pathlib.Path

Change by Barney Gale : -- pull_requests: +24778 pull_request: https://github.com/python/cpython/pull/26141 ___ Python tracker ___ _

[issue24132] Direct sub-classing of pathlib.Path

Barney Gale added the comment: Progress report: I've been working on tidying up the pathlib internals over the 3.9 and 3.10 releases. We're now in a position where: - `pathlib._Flavour` is entirely pure, and doesn't make any `os` calls - `pathlib._Accessor` handles all `os` access. The inte

[issue24132] Direct sub-classing of pathlib.Path

Change by Barney Gale : -- pull_requests: +24392 pull_request: https://github.com/python/cpython/pull/25701 ___ Python tracker ___ _

[issue24132] Direct sub-classing of pathlib.Path

Change by Barney Gale : -- pull_requests: +24005 pull_request: https://github.com/python/cpython/pull/25271 ___ Python tracker ___ _

[issue24132] Direct sub-classing of pathlib.Path

Change by Barney Gale : -- pull_requests: +23979 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25240 ___ Python tracker ___ __

[issue24132] Direct sub-classing of pathlib.Path

Change by Irit Katriel : -- components: +Library (Lib) stage: patch review -> needs patch type: behavior -> enhancement versions: +Python 3.10 -Python 3.6 ___ Python tracker __

[issue24132] Direct sub-classing of pathlib.Path

qb-cea added the comment: Hi, Thanks for reviving this! Feel free to reuse any code I wrote in my PR (or the whole PR itself), I do not think I will ever get around to finishing this work myself. -- ___ Python tracker

[issue24132] Direct sub-classing of pathlib.Path

Change by Xtrem532 : -- nosy: +Xtrem532 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.o

[issue24132] Direct sub-classing of pathlib.Path

Change by Piotr Dobrogost : -- nosy: +piotr.dobrogost ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue24132] Direct sub-classing of pathlib.Path

Barney Gale added the comment: I'm taking another look at making `pathlib` extensible. There's some discussion here: https://discuss.python.org/t/make-pathlib-extensible/3428 List or preparatory bugfixes and tidy-ups: https://docs.google.com/spreadsheets/d/1TicFDMudKKA6CZcrscg1Xq9kt5Q8To8y0h

[issue24132] Direct sub-classing of pathlib.Path

qb-cea added the comment: > What about AbstractPath instead of _PurePath ? I will use this, thanks. -- ___ Python tracker ___ ___ P

[issue24132] Direct sub-classing of pathlib.Path

Christophe BAL added the comment: Hello. What about AbstractPath instead of _PurePath ? Le 28/03/2018 à 02:30, qb-cea a écrit : > qb-cea added the comment: > > Hi all, > > I made a pull request proposing a fix for this issue. There is still quite a > lot to be done: > - I exposed some vari

[issue24132] Direct sub-classing of pathlib.Path

qb-cea added the comment: Hi all, I made a pull request proposing a fix for this issue. There is still quite a lot to be done: - I exposed some variables (and probably methods too) that used to be hidden; - I did not update the documentation; - I did not add a proper test. I will try to fi

[issue24132] Direct sub-classing of pathlib.Path

Change by qb-cea : -- keywords: +patch pull_requests: +5981 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list maili

[issue24132] Direct sub-classing of pathlib.Path

Change by qb-cea : -- nosy: +qb-cea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/ma

[issue24132] Direct sub-classing of pathlib.Path

Change by Torsten Bronger : -- nosy: +bronger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue24132] Direct sub-classing of pathlib.Path

Keith added the comment: Look at the architecture of Rio in Ruby (also ported to Squeak/Smalltalk) Leave Path to handle path stuff, and have another class to handle Platform stuff. https://rubygems.org/gems/rio/versions/0.6.0 -- nosy: +keithy ___

[issue24132] Direct sub-classing of pathlib.Path

Stephen M. Gava added the comment: @paul.moore is the original contributor mia? i seem to remember pathlib as once being marked 'provisional', i think it should have stayed that way until this problem was resolved. easy to say i know ;) when i don't have a patch. @projetmbc yes i found variou

[issue24132] Direct sub-classing of pathlib.Path

Christophe BAL added the comment: Mistyping : /search for class PPath/ with two P. Le 08/11/2017 à 13:59, Christophe BAL a écrit : > Christophe BAL added the comment: > > For the moment, you can take a look at this little script that acheives > subclassing of Path : > https://github.com/bc-pyt

[issue24132] Direct sub-classing of pathlib.Path

Christophe BAL added the comment: For the moment, you can take a look at this little script that acheives subclassing of Path : https://github.com/bc-python/mistool/blob/master/mistool/os_use.py (search for class Path). Le 08/11/2017 à 09:55, Paul Moore a écrit : > Paul Moore added the comm

[issue24132] Direct sub-classing of pathlib.Path

Paul Moore added the comment: @elguavas the problem is, no-one has proposed a patch. There's not likely to be much movement on this until someone provides one. -- ___ Python tracker _

[issue24132] Direct sub-classing of pathlib.Path

Stephen M. Gava added the comment: Using a set of paths with special properties and formats in a project, thought "the cleanest oop way to do this is try out python's oop paths in pathlib". Subclassed Path to implement my extra (non platfor specific) properties and fell at the first hurdle be

[issue24132] Direct sub-classing of pathlib.Path

Kevin Norris added the comment: If I were designing pathlib from scratch, I would not have a separate Path class. I would instead do something like this: In pathlib.py: if os.name == 'nt': Path = WindowsPath else: Path = PosixPath Alternatively, Path() could be a fact

[issue24132] Direct sub-classing of pathlib.Path

Paul Moore added the comment: > What is the good way to propose a patch ? If you have a patch, attach it here, and it will get reviewed. -- ___ Python tracker ___ __

[issue24132] Direct sub-classing of pathlib.Path

Christophe BAL added the comment: OK. I will try to find a way to achieve an easier and cleaner way to sub class pathlib.Path and co. What is the good way to propose a patch ? *Christophe BAL* *Enseignant de mathématiques en Lycée **et développeur Python amateur* *---* *French math teacher in a

[issue24132] Direct sub-classing of pathlib.Path

Paul Moore added the comment: > Are you the author of path lib ? Nope, that's Antoine. -- ___ Python tracker ___ ___ Python-bugs-list

[issue24132] Direct sub-classing of pathlib.Path

Christophe BAL added the comment: Are you the author of path lib ? *Christophe BAL* *Enseignant de mathématiques en Lycée **et développeur Python amateur* *---* *French math teacher in a "Lycée" **and **Python **amateur developer* 2015-05-06 21:01 GMT+02:00 Paul Moore : > > Paul Moore added th

[issue24132] Direct sub-classing of pathlib.Path

Paul Moore added the comment: I have no problem with that - it's a style choice certainly. As I said, I'd like to see simpler subclassing of pathlib objects. I just think it'll be quite hard to do (given the complexities of classes for Windows/Unix as well as pure and concrete paths). So if it

[issue24132] Direct sub-classing of pathlib.Path

Christophe BAL added the comment: I don't agree with you. I prefer to add new functionalities to the paths I use. This is the power of OOP. It is easier and cleaner to use *mypath.common_with(otherpath)* than *common_with(**mypath, **other path)* . Python is highly OOP, so you can't say *"don'

[issue24132] Direct sub-classing of pathlib.Path

Paul Moore added the comment: For that type of function, I'd suggest you use a standalone function rather than subclassing and methods or operator overloading. You don't gain enough to be worth the complexity of having to subclass path objects. And duck typing means that your function works fo

[issue24132] Direct sub-classing of pathlib.Path

Christophe BAL added the comment: Here are for example two extra methods that I have implemented. def __sub__(cls, path): """ This magic method allows to use ``onepath - anotherpath`` instead of the long version ``onepath.relative_to(anotherpath)`` given by ``pathlib.Path``. """ retu

[issue24132] Direct sub-classing of pathlib.Path

Christophe BAL added the comment: Hello. I will give a real example in 5 hours after my job. I will try tomorrow a solution to ease the subclassing using another dedicazted class PathPlus, sorry for the name. The idea would be to use this new class for customization, and also to define WindowsPa

[issue24132] Direct sub-classing of pathlib.Path

Antoine Pitrou added the comment: The Path classes were not designed to be subclassable by the user. I'm not against making subclassing easier, but someone will have to propose a viable approach for that. -- versions: +Python 3.5 -Python 3.4 ___ Pyth

[issue24132] Direct sub-classing of pathlib.Path

Paul Moore added the comment: One issue with your code - what would you expect str(test) to produce? "dir/test.txt" or "dir\test.txt"? That's the point of the "flavour" - is it a Windows path or a Unix path? Agreed that an easier method of creating Path subclasses that handle this type of thi

[issue24132] Direct sub-classing of pathlib.Path

Changes by Christophe BAL : -- title: Direct sub-classing of pathless.Path -> Direct sub-classing of pathlib.Path ___ Python tracker ___