<html>

 <head>

  <meta content="text/html; charset=ISO-8859-1"

   http-equiv="Content-Type">

 </head>

 <body bgcolor="#FFFFFF" text="#000000">

  <br>

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

  <blockquote

cite="mid:CADiSq7ez9VG+yvCdbDBgKJJqAB2PP60_TtjQpdcALsWZ6V8tNQ@mail.gmail.com"

   type="cite">

   <pre wrap="">On Fri, Jun 15, 2012 at 1:20 PM, Benjamin Peterson <a class="moz-txt-link-rfc2396E" href="mailto:benjamin@python.org">&lt;benjamin@python.org&gt;</a> wrote:

</pre>

   <blockquote type="cite">

    <pre wrap="">2012年6月14日 Larry Hastings <a class="moz-txt-link-rfc2396E" href="mailto:larry@hastings.org">&lt;larry@hastings.org&gt;</a>:

</pre>

    <blockquote type="cite">

     <pre wrap="">Also, it's more granular than that.&nbsp; For example, Python now understands

symbolic links on Windows--but only haphazardly at best.&nbsp; The

"follow_symlinks" argument works on Windows for os.stat() but not for

os.chmod().

</pre>

    </blockquote>

    <pre wrap="">

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).

</pre>

   </blockquote>

   <pre wrap="">

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

</pre>

  </blockquote>

  <br>

  I disagree that 2. would be better.&nbsp; I would prefer a standardized

  way of introspecting the availability of functionality to a

  collection of unique approaches stored in unpredictable locations.&nbsp;

  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.<br>

  <br>

  Regarding 3., "parameter docstrings" suggest docstrings, which

  suggest not-machine-readable.&nbsp; 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.<br>

  <br>

  As for "multi-valued attribute", I take it you're suggesting

  something more complex than "is_implemented".&nbsp; As I just said in a

  reply to Benjamin: I can't come up with a representation that's all

  things to all people.&nbsp; I contend "is_implemented" solves a

  legitimate problem in a reasonable way.&nbsp; 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.<br>

  <br>

  However, you appear to be saying you don't know what such a

  representation would be--you only conjecture that it *might* exist.&nbsp;

  I can't debate hypothetical representations.&nbsp; Furthermore, I suggest

  that if such a representation is possible, that it would be

  implementable in current Python.&nbsp; So again I ask: please suggest a

  superior representation.&nbsp; I would be genuinely interested in seeing

  it.&nbsp; Failing that, I'd prefer to restrict the discussion to whether

  or not the use case merits adding the flag.<br>

  <br>

  (I apologize in advance if I have misrepresented your position.)<br>

  <br>

  <br>

  <blockquote

cite="mid:CADiSq7ez9VG+yvCdbDBgKJJqAB2PP60_TtjQpdcALsWZ6V8tNQ@mail.gmail.com"

   type="cite">

   <pre wrap="">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

</pre>

  </blockquote>

  <br>

  I disagree with the description "ill-defined".&nbsp; I would be very

  surprised indeed if either you or Benjamin genuinely didn't

  understand exactly what "is_implemented" represents.&nbsp; If you're

  suggesting that the documentation is inadequate we can certainly

  address that.<br>

  <br>

  Perhaps you meant "ill-concieved"?<br>

  <br>

  <br>

  <i>/arry</i><br>

 </body>

</html>