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.
http://docs.python.org/3/library/os.html#dir-fd

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

Christian
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to