[Python-ideas] Allow manual creation of DirEntry objects

Brendan Moloney moloney at ohsu.edu
Thu Aug 18 15:40:59 EDT 2016


Thanks, opened an issue here: http://bugs.python.org/issue27796

-Brendan
________________________________
From: gvanrossum at gmail.com [gvanrossum at gmail.com] on behalf of Guido van Rossum [guido at python.org]
Sent: Wednesday, August 17, 2016 7:20 AM
To: Nick Coghlan; Brendan Moloney
Cc: Victor Stinner; python-ideas at python.org
Subject: Re: [Python-ideas] Allow manual creation of DirEntry objects

Brendan,

The conclusion is that you should just file a bug asking for a working constructor -- or upload a patch if you want to.

--Guido

On Wed, Aug 17, 2016 at 12:18 AM, Nick Coghlan <ncoghlan at gmail.com<mailto:ncoghlan at gmail.com>> wrote:
On 17 August 2016 at 09:56, Victor Stinner <victor.stinner at gmail.com<mailto:victor.stinner at gmail.com>> wrote:
> 2016-08-17 1:50 GMT+02:00 Guido van Rossum <guido at python.org<mailto:guido at python.org>>:
>> We could expose the class with a
>> constructor that always fails (the C code could construct instances through
>> a backdoor).
>
> Oh, in fact you cannot create an instance of os.DirEntry, it has no
> (Python) constructor:
>
> $ ./python
> Python 3.6.0a4+ (default:e615718a6455+, Aug 17 2016, 00:12:17)
>>>> import os
>>>> os.DirEntry(1)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: cannot create 'posix.DirEntry' instances
>
> Only os.scandir() can produce such objects.
>
> The question is still if it makes sense to allow to create DirEntry
> objects in Python :-)

I think it does, as it isn't really any different from someone calling
the stat() method on a DirEntry instance created by os.scandir(). It
also prevents folks attempting things like:

    def slow_constructor(dirname, entryname):
        for entry in os.scandir(dirname):
            if entry.name<http://entry.name> == entryname:
                entry.stat()
                return entry

Allowing DirEntry construction from Python further gives us a
straightforward answer to the "stat caching" question: "just use
os.DirEntry instances and call stat() to make the snapshot"

If folks ask why os.DirEntry caches results when pathlib.Path doesn't,
we have the answer that cache invalidation is a hard problem, and
hence we consider it useful in the lower level interface that is
optimised for speed, but problematic in the higher level one that is
more focused on cross-platform correctness of filesystem interactions.

I don't know whether it would make sense to allow a pre-existing stat
result to be based to DirEntry, but it does seem like it might be
useful for adapting existing stat-based backend APIs to a more user
friendly DirEntry based front end API.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com<mailto:ncoghlan at gmail.com>   |   Brisbane, Australia



--
--Guido van Rossum (python.org/~guido<http://python.org/~guido>)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160818/e1de6ffa/attachment.html>


More information about the Python-ideas mailing list