[Python-Dev] [Python-checkins] peps: Update for 436, explicitly supporting positional parameters forever, amen.

[Guido van Rossum]

On Mon, Mar 18, 2013 at 8:57 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Mon, Mar 18, 2013 at 1:47 AM, larry.hastings
> <python-checkins at python.org> wrote:
>>  Notes / TBD
>>  ===========
>>
>> +* The DSL currently makes no provision for specifying per-parameter
>> +  type annotations.  This is something explicitly supported in Python;
>> +  it should be supported for builtins too, once we have reflection support.
>> +
>> +  It seems to me that the syntax for parameter lines--dictated by
>> +  Guido--suggests conversion functions are themselves type annotations.
>> +  This makes intuitive sense.  But my thought experiments in how to
>> +  convert the conversion function specification into a per-parameter
>> +  type annotation ranged from obnoxious to toxic; I don't think that
>> +  line of thinking will bear fruit.
>> +
>> +  Instead, I think wee need to add a new syntax allowing functions
>> +  to explicitly specify a per-parameter type annotation.  The problem:
>> +  what should that syntax be?  I've only had one idea so far, and I
>> +  don't find it all that appealing: allow a optional second colon
>> +  on the parameter line, and the type annotation would be specified...
>> +  somewhere, either between the first and second colons, or between
>> +  the second colon and the (optional) default.
>> +
>> +  Also, I don't think this could specify any arbitrary Python value.
>> +  I suspect it would suffer heavy restrictions on what types and
>> +  literals it could use.  Perhaps the best solution would be to
>> +  store the exact string in static data, and have Python evaluate
>> +  it on demand?  If so, it would be safest to restrict it to Python
>> +  literal syntax, permitting no function calls (even to builtins).
>> +
>
> I think the hack we're using for the default-as-shown-in-Python will
> work here as well: use the converter parameterisation notation.
>
> Then "pydefault" (I think that is a better name than the current
> "default") and "pynote" would control what is shown for the conversion
> in the first line of the docstring and in any future introspection
> support. If either is not given, then the C default would be passed
> through as the Python default and the annotation would be left blank.

Right. In fact, I think the decision of what (if anything) should be
put in the annotation should be up to the converter class. It can be a
specific method on the converter object.

-- 
--Guido van Rossum (python.org/~guido)