Python 3 keeps getting better and better. I've been writing more code in Python 3 than 2 for about three years now, and I absolutely love it. When I have to write code in 2.7 now, it feels like shifting from fifth gear down to second.
If your codebase is large, it can feel daunting, but it's not usually that bad.
Although, I still find myself running tests and cursing at the fact that I keep writing print "string" without the brackets :D
You mean, second gear up to fifth?
I tried writing some Python 3 code and the lack of parameter tuple unpacking by itself stunned me and drove me crazy, never mind other stuff. Python 3 seems very user-unfriendly compared to Python 2. Won't touch it with a ten foot pole unless my life depends on it.
def fxn(a, (b, c), d):
pass
Python 3 will still allow
def fxn(a, x, d):
(b, c) = x
pass
//javascript
let [x, y] = [1,2]
#python
[x, y] = [1,2]
(x, y) = (1,2)
function fxn(a, [b, c], d) {
console.log(a, b, c, d);
}Uh, thanks?
I would call it anything but "rightful". Making life harder for introspection tools is hardly a rightful reason for removing a core language feature. The code is what most developers are trying to develop, not the introspection tools.
Well that's one reason yes, and by itself not really a good enough one. But if you read the PEP there are another 4 good reasons that you omitted from your comment, why is that?
Because the other reasons were twice as horrible.
"No loss of abilities"? Uh, you can't do this in lambdas anymore.
"Exception to the rule"? Who cares? It was useful and readable, that's all that matters.
"Uninformative Error Messages"? This has never been a pain point for me. If you don't like it then no one forced you to use it...
"Little Usage"? Well I guess everyone matters but me. Which is fine, but then you shouldn't wonder why it would tick me off.
I don't mean to sound like I'm trying to belittle your position, I would like to understand more. The PEP below doesn't seem to do a very good job explaining why people like them, and I'd like to hear a proponents position on the feature.
Unless I'm missing something, I don't see this as a show stopper personally, and see it as increasing readability.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> I don't mean to sound like I'm trying to belittle your position, I would like to understand more. The PEP below doesn't seem to do a very good job explaining why people like them, and I'd like to hear a proponents position on the feature.
Basically, I need it for functional programming. See here:
What are the cases where you use it / rely on it?
Basically any time I need to unpack inside a lambda (e.g. functional programming) and have to use something like itertools.groupby(), I run into trouble with Python 3. For example:
from itertools import groupby
def groupby_unsorted(items, key):
return map(lambda (g, l): (g, map(lambda (k, v): v, l)), groupby(sorted(map(lambda v: (key(v), v), items)), lambda (k, v): k))
print(groupby_unsorted([1, 2, 3, 4], lambda v: v % 2))
def groupby_unsorted(iterable, key):
return [(k, [v for k, v in g])
for k, g in
groupby(sorted((key(v), v) for v in iterable),
lambda item: item[0])]
print(groupby_unsorted([1, 2, 3, 4], lambda v: v % 2))The point was that writing something like
lambda item: item[0]
lambda (k, v): k
The problem is not (and has never been) whether something is "necessary" or "possible". Tuple unpacking obviously completely unnecessary to begin with, it has nothing to do with whether this is done in a parameter or not. The problem is whether the code is expressed better via unpacking.
Using it you can safely cleanup/commit transaction/release lock/etc when exiting a block of statements (even if an exception was raised). Plain 'with' statement cannot call asynchronous code in '__exit__' methods, 'async with' can do that (in '__aexit__').
I was under the impression that type checking was not one of the goals of PEP 484 etc.
In C#, the using statement combines with async/await. It is cool that Python finally gains proper async/await, there is no need to diss other languages.
An edge over what? You're still limited to a single thread via the GIL. Until that problem is solved, Python is certainly not the best bet (all else aside) for server development.
Do you really need to share mutable state between threads in your server? If yes, what's your story when you'll need to scale to multiple servers?
If not because you can keep shared mutable state in a separate service (DB or similar), you can deal with one-machine scaling very similarly to scaling across machines - just start/fork a process per CPU. You get simplicity, avoid the whole thread-safety can of bugs, and all the administration benefits of stateless servers.