[Python-3000] Adaptation and type declarations

[Chaz.]

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 <jimjjewett at gmail.com> 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 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/eprparadocs%40gmail.com
>