Not going to lie to you. I still don't get this.
...which is not really a call to arms for py3 as far as I'm concerned.(pypy support and potentially having one binary running 2.7 and 3.x at the same time is much more exciting)
Not going to lie to you. I still don't get this.
...which is not really a call to arms for py3 as far as I'm concerned.(pypy support and potentially having one binary running 2.7 and 3.x at the same time is much more exciting)
Like replacing
def wat(a, b, *args)
with def wat(*args)
a, b, args = *args def wat(*args)
a, b, *args = args
..But I don't see how moving required arguments from the signature to the body (or turning a TypeError into a ValueError) might be useful, or how it differs from the presentation's first advanced unpacking example.Python core devs really miss the point that if you want people to move from one solution to another with a cost (here: breaking backward compatibility) you have to provide an high value reason to move (see the network effect). Here we only got minor (but cool) improvements, moving to python3 is just not worth it. It's like having to do a plain old boring homework imposed by a teacher with the only reason "because I told you to" (and the situation is even worst if you have to do compatible code for libs).
I'm not at all against breaking backward compatibility, you have to have a good reason and to make it worth it and, of all the (minor) improvements I see, none of them was a justification for this. Tell me things like "oh, we break backward compatibility because we want to drop the GIL and implement the erlang actors model natively in python" and I'm with you the day it's released (even if you don't provide automatic CPU balancing at the beginning).