On Fri, Jun 15, 2012 at 1:20 PM, Benjamin Peterson <benja...@python.org> wrote: > 2012/6/14 Larry Hastings <la...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
