On 5/11/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Well, remember that the default use of type annotations is to ignore > them! You can write your own decorator that implements a specific > interpretation of the annotations, and you can make it do anything you > like. > > I think it would be useful to have a notation that can express > signatures. I haven't spent much time thinking about what this would > look like, but I'd like it to require no new syntax beyond the concept > of type annotations. If this means you can't have the inline > equivalent of your (int int -> int), then perhaps it could be done by > referencing some prototype with the appropriate annotations. Or > perhaps someting as crude as Function(type, type, ..., returns=type) > would be good enough for inlining this.
This exact thing (Function(type, type, ..., returns=type)) has been kicked around for inclusion in typecheck. One problem with using a keyword arg to indicate the return type means that functions passed in can't use that keyword argument themselves (unless you're not going to allow Function(arg1=type, arg2=type, ...)-style type annotations). One solution to this might be that you can't use Function inline, using an attribute to declare the return type (which should default to None). This lends itself to solving the next issue... > Regarding the question what to do if something un-annotated is passed, > you could have a strict and a lenient mode, sort of the equivalents of > guilty-unless-proven-innocent and innocent-unless-proven-guilty. I > guess the latter is more Pythonic, but the former is more in style > with type checking systems... :-) Maybe we could let the user decide which mode to use. If we use an attribute to declare the return type, we could use another to indicate whether they want this particular Function() instance to be strict or lenient. If some form of type annotations is introduced in 2.x, we could then observe which strictness option people prefer and make that the default in Python 3000. Of course, the question still remains what mode 2.x should default to. Collin Winter _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
