[Python-ideas] + operator on generators

[Koos Zevenhoven]

On Wed, Jun 28, 2017 at 9:01 PM, Sven R. Kunze <srkunze at mail.de> wrote:

> Good man. Today, a colleague of mine showed me a mobile mini-keyboard with
> a phone bracket (not even a dock). So, having his 7'' smartphone, he can
> work from his vacations and answer emails as well. ;) Cheap notebook
> replacement, if you don't prefer large screens and keyboards. :D
>
>
​Oh, I've been very close to getting one of those. But then I should
probably get a pair of glasses too ;).
​

> It all depends on what you need to do with the result of the
> concatenation. When all you need is something to iterate over, a
> generator-like thingy is fine. But when you need something for indexing and
> slicing or len etc., you want to be sure that that is what you're getting.
> But maybe someone passed you an argument that is not a sequence, or you
> forgot if a function returns a sequence or a generator. In that case, you
> want the error right away, instead of from some completely different piece
> of code somewhere that thinks it's getting a sequence. I don't think Python
> should depend on a static type checker to catch the error early. After all,
> type hints are optional.
>
>
> I understand that. In the end, I remember people on this mailing-list
> recommending me to use "list(...)" to make sure you got one in your hands.
> I remember this being necessary in the conversion process from Python2 to
> 3. The pattern is already here.
>
>
​That pattern annoys people and negates the benefits of views and
generators.​


> PS: I consider this proposal to be like allowing adding floats and ints
>> together. If I don't know if there was a float in the sum, don't know if my
>> result will be a float.
>>
>
> ​Not to say that the float/int case is never problematic, but the
> situation is still different. Often when a float makes any sense, you can
> work with either floats or ints and it doesn't really matter. But if you
> specifically *need* an int, you usually don't call functions that return
> floats. But if you do use division etc., you probably need to think about
> floor/ceil/closest anyway. And yes, there have probably been Python 2->3
> porting bugs where / division was not appropriately replaced with //.
>
>
> Division is one thing, numeric input parameters from unknown sources is
> another. In this regard, calling "int(...)" or "list(...)" follows the same
> scheme IMO.
>
>
​Sure, but you may want to turn your unknown sources into something
predictable as soon as possible. You'll need to deal with the errors in the
input anyway. Returning sequences vs generators is a different matter.​ You
don't want to turn generators into lists if you don't have to.

>
​[...]​

Just my 2 cents on this:
> At work, we heavily rely on Django. Django provides a so-called QuerySet
> type, its db-result abstraction. Among those querysets, our functions
> return lists and sets with no indication of whatsoever type it may be. It
> works quite well and we didn't had any issues with that. If we need a list,
> we wrap it with "list(...)". It's as simple as that. The valid concern,
> that it could be confusing which type the return value might have, is
> usually an abstract one. I can tell you that in practice it's not really an
> issue to talk about.
>

Very often one doesn't really need a list, but just something that has
indexing, slicing and/or len(). Wrapping things with list() can be ok, but
uses memory and is O(n). Generating lists from all kinds of iterables all
the time is just a whole bunch of unnecessary overhead. But yes, it
happens, because that's the convenient way of doing it now. That's like
going back to Python 2, but with additional calls to list() required. Maybe
you're lucky that your iterables are small and not a bottle neck and/or you
just don't feel guilty every time you call list() where you shouldn't have
to ;).

​-- Koos​

-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170628/03e52d5b/attachment.html>