5 ms·
> When I have to write code in 2.7 now, it feels like shifting from fifth gear down to second. You mean, second gear up to fifth? I tried writing some Python
by wfunction 11y ago
> When I have to write code in 2.7 now, it feels like shifting from fifth gear down to second.
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.
- jay_kyburz 11y agoProbably means from 3rd gear down to 2nd.
- orf 11y agoI've been using Python for 7+ years, and I had no idea parameter tuple unpacking was a thing. Never once seen any code that uses it, or seen anyone mention it. If you think the (rightful) removal of a hardly used feature[1] that has some big problems is a blocking issue then I feel sorry for you. Py3 is awesome. 1. https://www.python.org/dev/peps/pep-3113/ https://www.python.org/dev/peps/pep-3113/
- dvlsg 11y agoInteresting. Javascript is actually adding something very similar, calling it destructuring. It's actually quite handy - although admittedly more handy for destructuring object arguments than array arguments.
- ben336 11y agoPython 2 & 3 have destructuring. This is talking about having def fxn(a, (b, c), d): pass Be a valid function signature. So the destructuring is held in the function definition. Python 3 will still allow def fxn(a, x, d): (b, c) = x pass Both Python and ES6 JavaScript allow destructuring arrays: //javascript let [x, y] = [1,2] #python [x, y] = [1,2] (x, y) = (1,2)
- Arnavion 11y agoES6 does allow that via destructuring - https://babeljs.io/repl/#?experimental=true&evaluate=true&loose=false&spec=false&playground=true&code=function%20fxn(a%2C%20%5Bb%2C%20c%5D%2C%20d)%20%7B%0A%20%20console.log(a%2C%20b%2C%20c%2C%20d)%3B%0A%7D https://babeljs.io/repl/#?experimental=true&evaluate=true&lo... function fxn(a, [b, c], d) { console.log(a, b, c, d); }
- wfunction 11y ago> If you think the (rightful) removal of a hardly used feature[1] that has some big problems is a blocking issue then I feel sorry for you. 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.
- orf 11y ago> Making life harder for introspection tools is hardly a rightful reason for removing a core language feature 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?
- wfunction 11y ago> 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.
- lelandbatey 11y agoAs someone who's bounced back and forth between Python 2 and Python 3, I'm curious about your need of parameter tuple unpacking[0]. I've never encountered it, and after some research I don't understand the use case. 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. [0] - https://www.python.org/dev/peps/pep-3113/ https://www.python.org/dev/peps/pep-3113/
- unoti 11y agoA good example of a use case I can think of would be to pass an (x,y) coordinate pair as a single parameter, and unpack it in the parameter definition. This would save having an extra line that says (x,y) = pt. Unless I'm missing something, I don't see this as a show stopper personally, and see it as increasing readability.
- jacobolus 11y agoYou should use a namedtuple for that sort of thing, and then refer to the members as pt.x and pt.y.
- mycelium 11y agoI use it like es6 or haskell destructuring. Sure it's a little weak compared to both those implementations, but the tuple case covers enough to be useful.
- paulsutter 11y agoAt first glance, parameter tuple unpacking seems like a silly hack that was wisely removed, explained here http://legacy.python.org/dev/peps/pep-3113/ http://legacy.python.org/dev/peps/pep-3113/ What are the cases where you use it / rely on it?
- wfunction 11y ago> 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)) Never ran into problems with it either.
- aldanor 11y agoBut tuple unpacking inside lambdas is actually supported in Python 3, isn't it?
- wfunction 11y agoCould you give me an example of what you mean?
- azag0 11y agoPython has comprehensions for this style of programming: 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))
- wfunction 11y agoYes, list comprehensions can take care of some of these, but you're completely missing the entire point. The point was that writing something like lambda item: item[0] in your code is inferior to lambda (k, v): k in terms of readability and comprehensibility. It is both longer and it also doesn't document the fact that the item is semantically a key-value pair. 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.