[Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Christian Heimes christian at python.org
Mon May 13 16:49:19 CEST 2013

Am 13.05.2013 02:21, schrieb Ben Hoyt:
> Are you suggesting just accessing .cached_lstat could call os.lstat()?
> That seems very bad to me. It's a property access -- it looks cheap,
> therefore people will expect it to be. From PEP 8 "Avoid using
> properties for computationally expensive operations; the attribute
> notation makes the caller believe that access is (relatively) cheap."
> Even worse is error handling -- I'd expect the expression
> "entry.cached_lstat" to only ever raise AttributeError, not OSError in
> the case it calls stat under the covers. Calling code would have to
> have a try/except around what looked like a simple attribute access.
> For these two reasons I think lstat() should definitely be a function.

OK, you got me! I'm now convinced that a property is a bad idea.

I still like to annotate that the function may return a cached value.
Perhaps lstat() could require an argument?

    def lstat(self, cached):
        if not cached or self._lstat is None:
            self._lstat = os.lstat(...)
        return self._lstat

> True. My isdir/isfile/islink implementations should catch any OSError
> from the lstat() and return False (like os.path.isdir etc do). But
> then calling code still doesn't need try/excepts around the isdir()
> calls. This is how os.walk() is implemented -- there's no extra error
> handling around the isdir() call.

You could take the opportunity and take the 'file was deleted' case into
account. I admit it has a very low priority. Please regard the case for
bonus points only. ;)

> Sure. I'm primarily a Windows dev, so not too familiar with all the
> fancy stat* functions. But what you're saying makes sense.

I'm glad to be of assistance! The feature is new (added in 3.3) and is
available on most POSIX platforms.

If you need any help or testing please feel free to ask me. I really
like to get this feature into 3.4.


More information about the Python-Dev mailing list