[Python-Dev] PEP 362 Third Revision (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Jun 16 16:51:30 CEST 2012

On Sat, Jun 16, 2012 at 10:52 AM, Benjamin Peterson <benjamin at python.org> wrote:

2012/6/15 Larry Hastings <larry at hastings.org>:

Note that I'm genuinely interested in your answer--"isimplemented" appears to have a groundswell of anti-support and I rather suspect will be axed. Meantime I still need to solve this problem. How about a list of functions that support it. Then you could do things like "chown" in os.supportsatvariant

Indeed, PEP 362 is not the right answer for obtaining a more user friendly interface to sysconfig.

The real answer for this kind of case is to just try whatever you want to do and see if it throws an exception. Just as LBYL is sometimes unusable due to problems with race conditions, in this case, a dedicated LBYL interface should be rejected because it requires double-keying data. If you try it and it fails, you know it's not supported. If some separate metadata claims it's not supported, it might just be that the metadata is wrong.

We don't have to implement bad ideas just because some people don't like to rely on exceptions - LBYL vs EAFP isn't always just a stylistic choice, there are cases where one or the other can be a genuinely poor concept.

If someone really does want to do LBYL in this case, then finding out the underlying criteria and perform the same check themselves is the right way to do it. They'll get the wrong answer if the criteria ever changes, but that's the inevitable risk with LBYL in cases like this.

At most, it may make sense to provide more user friendly interfaces for specifically requested sysconfig checks (perhaps in sysconfig or platform).

For example:

if platform.provides_openat():
   # Can use dirfd param to os.open()

if platform.provides_fd_times():
   # Can use fd param to os.utime()

I'm not convinced this need to be in the standard library, though - we will already be providing an obvious way to do these checks (i.e. catch the exceptions). It definitely shouldn't be rushed into 3.3.

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list