[Python-Dev] PEP 362 Third Revision

Larry Hastings larry at hastings.org
Fri Jun 15 21:31:03 CEST 2012


On 06/15/2012 12:06 PM, Benjamin Peterson wrote:
> 2012/6/15 Larry Hastings<larry at hastings.org>:
>> On 06/15/2012 11:46 AM, R. David Murray wrote:
>>
>> Adding a os.have_openat seems more reasonable than adding is_implemented
>> to every __signature__ object.  And more useful, as well; it provides
>> a much more specific piece of information.
>>
>>
>> We already have "os.have_openat"; it's spelled
>> sysconfig.get_config_var('HAVE_OPENAT').  But, assuming I land issue 14626,
>> this leads us to:
>>
>> Q: Can I use the dir_fd parameter to os.open?
>> A: Only if sysconfig.get_config_var('HAVE_OPENAT') is true.
>>
>> Q: Can I use the fd parameter to os.utime?
>> A: Only if sysconfig.get_config_var('HAVE_FUTIMENS') or
>> sysconfig.get_config_var('HAVE_FUTIMES') is true.
>>
>> I feel this interface lacks civility.
> There's no reason this couldn't be wrapped into some sort of os level
> attribute or function.

No, but how would you spell it in a graceful way?  It really is specific 
to a particular parameter on a particular function.  And there are a 
bunch of parameters that are available if any one of a couple C 
functions is locally available--fd and follow_symlinks on utime, 
follow_symlinks on chown.  follow_symlinks for stat is available if you 
have lstat *or* you're on Windows.  ('HAS_LSTAT' isn't set on Windows, 
we don't use configure there.)  So certainly I don't like the idea of 
just checking if the C function(s) is (are) available.

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.

I can't say I like any of these:

    os.can_use(os.stat, "fd")  # too generic
    os.can_use_fd(os.stat)  # too specific

Binding it to the function itself seems to be Just Right to me.  But 
since they're PyCFunctionObjects I can't add arbitrary attributes.

(Perhaps the right thing would be to take this discussion to issue 14626.)


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120615/53447706/attachment.html>


More information about the Python-Dev mailing list