If you are going this far, why not also support a throws() modifier (or whatever you might call it).
Right now I do something like: @throws(IOError) def foo(...) : as a way to indicate that foo() can throw a specific exception. I might suggest def foo(...) throws(...) : as a more integrated approach. On this direct topic because there is no type-specific polymorphism in Python, I occasionally write functions that do slightly different things depending on the type of input. Is there an approach to say a specific argument can take any number of different types? C. G. Guido van Rossum wrote: > On 4/10/06, Jim Jewett <[EMAIL PROTECTED]> wrote: >> Every so often Guido talks about adding optional typing to python. >> >> Adaptation may offer the cleanest way to do this. >> >> >> Turning >> >> def fn(a, b, c="default"): ... >> >> into any of >> >> def fn(Seq a, Index b, Text c="default"): ... >> def fn(Seq(a), Index(b), Text(c)="default"): ... >> >> or (wrapped version) >> >> def fn(Seq a, >> Index b, >> Text c="default"): ... >> >> doesn't seem so awful. (I'm not sure it is a net positive for >> readability, but I'm also not sure it isn't.) I read the type >> information as "normally this is just an assertion, but I suppose some >> protocols might *make* it true for me." > > I do think that we now have enough proposals on the table that require > specifying types (or other metadata!) for each argument of certain > function definitions that it's time to do something about this. > > A bit more than a year ago I blogged extensively about this. The only > syntax that is acceptable to me is slightly different; the above would > look like > > def fn(a: Seq, b: Index, c: Text = "default"): ... > > where Seq, Index and Text can be expressions (the main problem with > the syntax you propose is that the type can't be much more than an > identifier before it gets ambiguous or unreadable). > > A completely separate issue is what kind of objects Seq, Index and > Text would be; but that's a discussion we have separate from the > syntactic discussion. > > I would imagine that instead of the currently proposed > > @foo.register(list, int, str) > def foo_1(a, b, c): ... > > we'd be allowed to write > > @foo.register > def foo_1(a: list, b: int, c: str): ... > > FWIW (to ward of immediate questions) the syntax for an argument would > be something like this: NAME [':' EXPR] ['=' EXPR] where currently it > is NAME ['=' EXPR]. The only defined semantics would be that the name, > the type and the default can all be inspected through the > __signature__ attribute on the function object. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > _______________________________________________ > 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/eprparadocs%40gmail.com > _______________________________________________ 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
