[Python-Dev] PEP 362 Third Revision (original) (raw)

Larry Hastings larry at hastings.org
Fri Jun 15 07:23:30 CEST 2012

On 06/14/2012 08:41 PM, Nick Coghlan wrote:

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 "followsymlinks" 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.intinfo, sys.floatinfo, time.getclockinfo) 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120614/20d08e6d/attachment.html>

More information about the Python-Dev mailing list