On 28.06.2017 16:01, Koos Zevenhoven wrote:
For a moment, I was wondering what the double emphasis was for, but then I realized you are simply calling `statement.__why__()` directly instead of the recommended `spoiler(statement)`.
Doing this for years now. Sometimes, when 'statement.__why__()' returns None, 'spoiler(statement)' returns some thought-terminating cliché. ;)
But sure, I just got on vacation and I even found a power extension cord to use my laptop at the pool, so what else would I do ;).
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
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.
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.
But regarding containers, it often makes just as much sense for a function to return a generator as it does to return a sequence. The name or purpose of a function may give no hint about whether an iterable or sequence is returned, and you can't expect everyone to prefix their function names with iter_ and seq_ etc. And it's not just function return values, it's also arguments passed into your function.
Exactly. Neither want I those prefixes. And I can tell you they aren't necessary in practice at all. 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. Regards, Sven