Python is DOOMED! Again!
nicholas.cole at gmail.com
Thu Jan 22 11:46:18 CET 2015
On Thursday, 22 January 2015, Chris Angelico <rosuav at gmail.com
> On Thu, Jan 22, 2015 at 7:10 PM, Mario Figueiredo <marfig at gmail.com>
> > Possibly one common use case will be Unions. And that factory syntax is
> > really awful and long when you look at a function definition with as
> > little as 3 arguments. The one below has only 2 arguments.
> > def handle_employees(emp: Union[Employee, Sequence[Employee]], raise:
> > Union[float, Sequence[float]]) -> Union[Employee, Sequence[Employee],
> > None]:
> Hold on a moment, how often do you really do this kind of thing with
> "might be one of them or a sequence"? Do you really have a function
> that could take an Employee and a float, or a sequence of Employees
> and a single float, or a single Employee and a sequence of floats, or
> a sequence of both? Or do you, much more likely, actually have two
> separate functions:
> def handle_employee(emp: Employee, raise: float) -> Optional[Employee]:
> def handle_employees(emp: Sequence[Employee], raise: Sequence[float])
> -> List[Employee]:
> The union in the return value seems particularly unlikely... and unhelpful.
Hang on! The particular example may not make a lot of sense but there are
plenty of places in ordinary Python where functions can accept different
objects in arguments and return different things. The point here is that
that will become rapidly messy and hard to read.
Perhaps the new PEP will discourage this kind of thing and perhaps that is
to be welcomed not feared, but I don't think the example itself was
particularly contrived. I've seen it in plenty of code in the wild.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list