On Fri, Jun 15, 2012 at 1:20 PM, Benjamin Peterson <benjamin at python.org> wrote: > 2012/6/14 Larry Hastings <larry at hastings.org>: >> Also, it's more granular than that. For example, Python now understands >> symbolic links on Windows--but only haphazardly at best. The >> "follow_symlinks" argument works on Windows for os.stat() but not for >> os.chmod(). > > Then indeed it's more granular than a parameter being "implemented" or > not. A parameter may have a more restricted or extended meaning on > different operating systems. (sendfile() on files for example). I agree with Benjamin here: I'd like to leave the flag out for now. I can see there could be a legitimate use case for something *like* that, but: 1. Context-specific function annotations may be a better answer 2. Context-specific "info" containers (such as sys.flags, sys.int_info, sys.float_info, time.get_clock_info) may be a better answer 3. A multi-valued attribute or an arbitrary string attribute (parameter docstrings, anyone?) may be a better answer There's no need to enshrine a flag for a currently ill-defined concept in the initial version of the API. If it still seems like a good idea by the time 3.4 rolls around, then we can add it than as a new attribute on inspect.Parameter objects Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4