(original) (raw)
On 06/15/2012 12:06 PM, Benjamin Peterson wrote:
2012/6/15 Larry Hastings <larry@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