It sounds fine to just submit a patch to add and document the DirEntry constructor. I don't think anyone intended to disallow your use case, it's more likely that nobody thought of it.
On Tue, Aug 16, 2016 at 12:35 PM, Brendan Moloney <[email protected]> wrote: > Hi, > > I have been using the 'scandir' package (https://github.com/benhoyt/ > scandir) for a while now to > speed up some directory tree processing code. Since Python 3.5 now > includes 'os.scandir' in the > stdlib (https://www.python.org/dev/peps/pep-0471/) I decided to try to > make my code work with > the built-in version if available. > > The first issue I hit was that the 'DirEntry' class was not actually being > exposed > (http://bugs.python.org/issue27038). However in the discussion of that > bug I noticed that the > constructor for the 'DirEntry' class was deliberately being left > undocumented and that there > was no clear way to manually create a DirEntry object from a path. I > brought up my objections > to this decision in the bug tracker and was asked to have the discussion > over here on > python-ideas. > > I have a bunch of functions that operate on DirEntry objects, typically > doing some sort of filtering > to select the paths I actually want to process. The overwhelming majority > of the time these functions > are going to be operating on DirEntry objects produced by the scandir > function, but there are some > cases where the user will be supplying the path themselves (for example, > the root of a directory tree > to process). In my current code base that uses the scandir package I just > wrap these paths in a > 'GenericDirEntry' object and then pass them through the filter functions > the same as any results > coming from the scandir function. > > With the decision to not expose any method in the stdlib to manually > create a DirEntry object, I am > stuck with no good options. The least bad option I guess would be to copy > the GenericDirEntry code > out of the scandir package into my own code base. This seems rather > silly. I really don't understand > the rationale for not giving users a way to create these objects > themselves, and I haven't actually seen > that explained anywhere. I guess people are unhappy with the overlap > between pathlib.Path objects > and DirEntry objects and this is a misguided attempt to prod people into > using pathlib. I think a better > approach is to document the differences between DirEntry and pathlib.Path > objects and encourage > users to default to using pathlib.Path unless they have good reasons for > using DirEntry. > > Thanks, > Brendan > > _______________________________________________ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
