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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
