[Python-Dev] Rationale for sum()'s design?

Michael Walter michael.walter at gmail.com
Thu Mar 17 02:48:01 CET 2005

On Wed, 16 Mar 2005 08:28:22 -0800, Guido van Rossum
<gvanrossum at gmail.com> wrote:
> > > Thinking ahead to generic types, I'd like the full signature to be:
> > >
> > >   def sum(seq: sequence[T], initial: T = 0) -> T.
> >
> > Would this _syntax_ work with generic types:
> >
> >   def sum(seq: sequence[T], initial: T = T()) -> T.
> Maybe, but it would preclude union types; continuing with the (bad)
> example of strings, what should one choose for T when seq == ['a',
> u'b']? The general case is a sequence of objects of different types
> that are mutually addable. This can be made to work with the
> (hypothetical!!!!) type system by using unions, but you can't
> instantiate an instance of a union without being more specific.

Continuing that hypothetical thought, it would be perfectly acceptable
to make require an argument for union types T. Maybe T() should only
be valid for non-union types. Several questions like "when should T()
be evaluated" [1], "how can we avoid ': T = T()' leading to a type
error" and "how about optional parameters in front of ': T = T()'"
just popped up in my mind.


[1] Thanks, John!

More information about the Python-Dev mailing list