On 06/14/2012 08:41 PM, Nick Coghlan wrote:
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
I disagree that 2. would be better. I would prefer a standardized way
of introspecting the availability of functionality to a collection of
unique approaches stored in unpredictable locations. I disagree with 1.
for much the same reason, though I like it more than 2.--at least it's
bound directly to the function.
Regarding 3., "parameter docstrings" suggest docstrings, which suggest
not-machine-readable. The purpose of having it at all is so one can
LBYL programmatically--if human-readable documentation is sufficient
then we don't need this at all.
As for "multi-valued attribute", I take it you're suggesting something
more complex than "is_implemented". As I just said in a reply to
Benjamin: I can't come up with a representation that's all things to all
people. I contend "is_implemented" solves a legitimate problem in a
reasonable way. If you can propose a superior representation, one that
can convey more complex situations without becoming miserable to use,
I'd like to see it.
However, you appear to be saying you don't know what such a
representation would be--you only conjecture that it *might* exist. I
can't debate hypothetical representations. Furthermore, I suggest that
if such a representation is possible, that it would be implementable in
current Python. So again I ask: please suggest a superior
representation. I would be genuinely interested in seeing it. Failing
that, I'd prefer to restrict the discussion to whether or not the use
case merits adding the flag.
(I apologize in advance if I have misrepresented your position.)
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
I disagree with the description "ill-defined". I would be very
surprised indeed if either you or Benjamin genuinely didn't understand
exactly what "is_implemented" represents. If you're suggesting that the
documentation is inadequate we can certainly address that.
Perhaps you meant "ill-concieved"?
//arry/
_______________________________________________
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
