On Mon, Mar 18, 2013 at 8:57 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On Mon, Mar 18, 2013 at 1:47 AM, larry.hastings > <python-check...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
