[Python-Dev] PEP 362 Third Revision

[Nick Coghlan]

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--"is_implemented" 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.supports_at_variant

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