If we decide to revert the addition of Path.scandir()
then I’m OK with that, for what it’s worth.
I am interested in adding an abstract version of pathlib.Path
, and tbh this was my main motivation for adding a scandir()
method. The abstract base class already exists in cpython, but it’s private:
Previously the PathBase.iterdir()
method was abstract, but this hampered performance for the PathBase.walk()
, glob()
and copy()
methods, which were implemented using self.iterdir()
. These methods are now implemented using self.scandir()
, which improves performance a great deal. And it improves performance of Path.copy()
too, because Path
inherits the PathBase.copy()
implementation.
But the pathlib ABCs are still private, and so it’s possible to conclude that none of the above matters. I’m sympathetic to this view and I’m open to adding scandir()
only if we decide to make PathBase
public, which would require a PEP but not much more technical work.
Some other non-ABC motivation for adding a scandir()
method can be found in a previous post of mine