[Python-Dev] PEP 362 Third Revision

[Larry Hastings]

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
>>> "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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120614/20d08e6d/attachment.html>