[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