(original) (raw)

On 03/18/2013 12:16 AM, Larry Hastings wrote:

I'll amend my PEP soonish to reflect this. Specifically the semantics of the /, \[, and \] lines in the parameter section.

I've just posted this revision.

I'd like to draw everyone's attention to the top entry in the Notes section, reproduced below:

\* 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 we 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).

Syntax suggestions welcome,

/arry