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

[Nick Coghlan]

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.

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia