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
   ">

(original) (raw)


On 06/14/2012 08:41 PM, Nick Coghlan wrote: 
On Fri, Jun 15, 2012 at 1:20 PM, Benjamin Peterson <benjamin@python.org> wrote:  

2012/6/14 Larry Hastings <larry@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