[Python-Dev] [Python-checkins] peps: New DSL syntax and slightly changed semantics for the Argument Clinic DSL.

[Larry Hastings]

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130318/3e370770/attachment.html>