3 ms·
It is. But stablished idioms became obsolete, and the code that used them becames unidiomatic. And you have to learn them if you want to read other people's cod
by samuel 5y ago
It is. But stablished idioms became obsolete, and the code that used them becames unidiomatic. And you have to learn them if you want to read other people's code.
Python doesn't need more features but better implementations, IMO.
Edit: Just remembered the Zen of Python, I don't think modern Python is following it.
...
Simple is better than complex.
...
Readability counts.
...
There should be one-- and preferably only one --obvious way to do it.
- el_oni 5y agoAnd yet i would argue that comprehensions and decorators are more readable and simple than wrapped functions and for-loops that append to a list. Having one way of doing something and sticking with it even when better ways emerge is nonsensical imo. f-strings are more readable (for me) and concise than string formatting or .format() I do agree on the implementation front though, many of the other implementations are still on 2.7 or 3.6 at most, and don't have mainstream appeal. Made more with interop in mind (like ironpython with .net and jython with the jvm)
- rightbyte 5y ago> And yet i would argue that comprehensions and decorators are more readable and simple than wrapped functions and for-loops that append to a list. Not for beginners though. One of Pythons main strengths was that it looked simple. Not anymore.
- _dain_ 5y agoDecorators, I'll grant. But I remember loving comprehensions as a beginner, because they resembled the set-builder notation I was already familiar with from mathematics. I actually found it harder to remember how to construct lists the "manual" way: do I use `append`, or `extend`, or `+=`?
- saalaa 5y agoBut we're way past decorators and comprehensions. I don't understand why people focus on these 2 features to fuel the debate here. Point is Python used to be a complete yet simple language with few constructs. It more or less followed the path of least surprise and people revered it for that. For several years, it feels like PEPs just add more and more clutter to that foundation. It sort of looks like an arms race and I just don't get why or what's going on. Certainly, Python doesn't feel the same anymore.
- rightbyte 5y agoPython has turned into the C++ of dynamic languages, but without the speed. My feeling is that Python is suffering the same fate as Pascal, where a "teaching and prototyping language" is used for things it was not intended for. Programmers that grew up with Python want more features, not thinking about the next generation of programmers.
- Joker_vD 5y agoAn example loop: elif cmd.op == 'TUPLE': arity, = cmd.args tuple_args = [] for _ in range(arity): tuple_args.append(self.data_stack.pop()) result = '{' + ', '.join(map(str, tuple_args)) + '}' self.data_stack.append(result) Is following use of comprehension any better? I don't think so: elif cmd.op == 'TUPLE': arity, = cmd.args tuple_args = [str(arg) for arg in reversed(self.data_stack[-arity:])] self.data_stack = self.data_stack[:-arity] result = '{' + ', '.join(map(str, tuple_args)) + '}' self.data_stack.append(result) Any other suggestions for improvement?
- andybak 5y agoMy personal rule is to use comprehensions when they improve readability and to avoid them when they don't. There's usually a threshold where I go "nope" and unroll it into a good old loop. But when you're in their sweet spot, they definitely improve readability.
- michaelhoffman 5y agoelif cmd.op == 'TUPLE': arity, = cmd.args stack = self.data_stack text = ', '.join(str(stack.pop()) for _ in range(arity)) stack.append(f'{{{text}}}')