A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2005-March/052227.html below:

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

[Python-Dev] Rationale for sum()'s design? [Python-Dev] Rationale for sum()'s design?Guido van Rossum gvanrossum at gmail.com
Wed Mar 16 17:28:22 CET 2005
> > 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.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4