6 ms·

Once my favorite language by far, Python is starting to became too cluttered. Very few of the additions to the language in the 3.x branch are worth it IMO. I r

by samuel 5y ago

Once my favorite language by far, Python is starting to became too cluttered. Very few of the additions to the language in the 3.x branch are worth it IMO. I remember that in the early 00's people called it "executable pseudocode". I bet nobody would use now that expression for modern Python with decorators, comprehensions, walruses and the like.

killingtime74 5y ago
Is it not all optional? You don’t have to use it if it doesn't improve your code
- joelthelion 5y ago
  It still ends up in other people's code, so it's hard to meaningfully contribute to python projects without learning at least the basics for all these new features.
- 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 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. 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 ago
        Decorators, 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 ago
        But 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 ago
        Python 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 ago
      An 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?
- qwertox 5y ago
  I was going to say the same, but if you start to read other's code, you will need deal with it. Buy I personally like it when I read other people's code and see something which I don't understand, which I've never seen, and then it turns out to be a feature which actually makes coding easier and more efficient. Then I think about all the places where I could have used that feature in my old code.
BiteCode_dev 5y ago
I hear that quite often, but up to now, I haven't seen it translate in the field. Code examples in docs and tutorials are still easy, libs api still clean, code base still readable. Optional things stayed indeed, optional. My grip is actually the contrary, many python code bases are stuck in the past. But I'm ok with it, people are not all pro devs, they need a productive language subset. And the new syntax is providing some fantastic new tools, such as pydantic/fastapi/typer (if you haven't try it, it's really paradigm shift, and I say that as a django fan). f-string are awesome. dataclasses are nothing but convenient and readable. Advanced unpacking as well. I seldom use the walrus, almost nobody does, but when one does, it's useful. > decorators, comprehensions, Those existed in python 2, 10 years ago. It's hardly new python. And web frameworks would be terrible without those.
- dlisboa 5y ago
  > My grip is actually the contrary, many python code bases are stuck in the past. From the outside looking in the Python community seems aggressively anti reworking their code to adapt to new language features. The 2 to 3 debacle comes to mind when compared to other languages, like JS, which made a much bigger change and everyone jumped in it and rewrote their code to adapt, or Ruby which went through some backwards incompatible changes at the same time as Python.
  - scoopertrooper 5y ago
    I don't think there has been a non-backwards compatible JS change in a very long time. They even named the array flatten method as 'flat', just to avoid having a conflict with MooTools!
    - dlisboa 5y ago
      My point with JS is more that the JS community sees no problem and will actively rewrite vast swaths of code to use features that are not yet supported in browsers. Hence the extensive use of polyfills and transpilers. Major language changes are generally seen as a good thing (which they mostly are in JS' case). With Python I don't get the same feeling, they seem more resistant to change in general. I don't think it's just that Python has more so-called "non-programmers" (meaning, data science and math people). Most of the libraries for these things are made by full-time programmers anyway. Perhaps the idea that "there's only one way to do it" brought about a "the current way is good enough, why rewrite in a new one?" attitude. But anyway, I'm not familiar enough, just an outside perspective.
jcelerier 5y ago
a new simple language is created (Python) -> beginners start using it -> they become proficient in it, some build successful businesses around the language -> limits due to the simplicity are hit -> people lobby for advanced features (lambdas, match, etc) which make code much easier for the subset who understand it -> other people complain that they can't understand the code anymore -> a new simple language is created (Go) -> ... -> people lobby for advanced features (generics) -> ...
- jerf 5y ago
  Go's over ten years in, though, and the first really significant overhaul is still about six months out. It breaks that cycle. More on topic, I do sort of feel like maybe the Python team should have made a Newthon (with a better name) or something, because Python is becoming a shambling beast. Starting as one of the world's most dynamic OO language and then shambling towards being a static language, maybe a bit of a functional language, it's crazy. I often joke about "Katamari Dama-C++!", which has the irresistible phonetic allusion, but damn if Python isn't trying to keep up at this point. If you don't like Python for some task... use something else suited for your task, then. It's not like using something else means you must put Python down and never use it again on pain of being shot or something. Stop waiting for Python to mutate into O'Caml or something and just use O'Caml or whatever.
  - kowlo 5y ago
    I googled "Katamari Dama-C++" to see what it was all about and found your post from 2014 [1]. That is impressive commitment. https://news.ycombinator.com/item?id=7315163 https://news.ycombinator.com/item?id=7315163
tragomaskhalos 5y ago
Well. I have a book that uses a minimal subset of Python as the illustrative language, and oh boy would the examples have been vastly improved if the author had gone the extra yard and added comprehensions into the mix rather than ploddingly building his transformed lists in loops like a Neanderthal. Decorators though I totally agree; had some tooling at work that was gussied up to the point of impenetrability by gratuitous use of decorators. A colleague got so fed up with it he rewrote it in Perl, which was, shockingly, actually a maintainability improvement.
- mikepurvis 5y ago
  Decorators become pretty hard to reason about as soon as you have to apply more than one of them to the same method. So I think there are cases for them where the ergonomics are fantastic, but exercising restraint is critical— and it's restraint on the part of API/library authors that is needed more than on the part of users, since a lot of the time, it's actually out of users' hands.
  - stinos 5y ago
    This. Nothing wrong with decorators per se. Just one typical example: measuring a couple of functions execution time by just decorating them definitely fullfils what the OP wants: simple and readable. Obviously there is more than one way to measure execution time, but the 'there should be one way' mantra really only holds true for very basic things anyway imo. And yes just like any other pattern out there it can be abused. One could try and blame the language for allowing such abuse, but that is not always fair I think, and also not in this case. Bad code is written all the time all over the place, and if a language would try to really really fix that it would be way to restrictive probably and hinder development in other ways. Same story for list comprehensions: it's almost beyond me how one can be against a simple single list comprehension. It's simple, readable, almost beautiful. Now if people start nesting 5 comprehensions it's not so nice anymore; but then is the language to blame (as in, would we really want to forbid nested comprehensions?), or the people?
- JoBrad 5y ago
  I really love the idea of decorators. However, after having used them in some rather large projects, I have to agree that it contributes to “magic” happening elsewhere in your code that can complicate debugging quite a bit.
hvocode 5y ago
Part of me wants to disagree since some of these features make my code shorter, but I have to agree since they commit a sin of language design that I dislike - implicit magic. Decorators are useful because they can help you shrink code by letting the decorator generate boilerplate for you. The code gets smaller, but now it’s harder to know what’s going on since you need to know what magic happened behind the scenes due to the decorator. It feels very much like issues I ran into when I used C++ meta programming libraries - my code shrank, and at the same time my understanding of what it actually did also shrank. Same with the walruses - my code gets smaller because now there’s some implicit stuff happening. Comprehensions are a little less magical - if anything, they are more explicit. If I want to create a list where each element is generated by some function over another list, I just say it. Doing so with loops is obscuring what I wanted to say in the first place. The problem with comprehensions isn’t so much the comprehension, but the obtuse ways people can use them to eke out performance by avoiding explicit loops. I’m all for things that are closer to what a programmer means, but less keen on features that entail obscuring details that may come back to haunt the programmer later (I see this most often with decorators).
- nyuszika7h 5y ago
  I don't really agree that it's so magical, especially the walrus operator. Sure, a beginner may be confused by it, but it's really easy once you learn the difference between `=` and `:=` IMO. Python is not a language designed to be only used by beginners. Decorators may be a little more "magic", but it makes little difference in practice if you do @bar or foo = bar(foo), the former is just a cleaner syntax (and stops linters wanting you to put two blank lines between the function and the "decorator").
- bluecalm 5y ago
  Oh c'mon with the walrus. Assignment being an expression is the case in so many languages. They should have made it the case in Python and just be done with it. "But someone will make a typo one day resulting in = instead of ==" argument is nonsense as that hasn't been an issue since forever in other languages. You can either require parentheses if you want to use the value (the way C compilers want it) or just make it := to begin with.
dochtman 5y ago
List comprehensions date from Python 2.0 (October 2000), decorators from 2.4 (November 2004) -- so both of those are from when people called it "executable pseudocode", right? At the least there's a big discontinuity before the walrus operator appears (3.8, October 2019). I was once an avid Python user, but I switched to mostly Rust a few years ago and now write very little Python. A while ago I wrote some not quite trivial script-like code in Python, but ended up converting it to Rust before it finished running. The attraction of Python used to be that it was simple, but I now value robustness (through the type system in particular) much more than simplicity of the language.

by samuel 5y ago

killingtime74 5y ago

Is it not all optional? You don’t have to use it if it doesn't improve your code

joelthelion 5y ago
It still ends up in other people's code, so it's hard to meaningfully contribute to python projects without learning at least the basics for all these new features.
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 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. 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 ago
      Decorators, 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 ago
        But 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 ago
        Python 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 ago
    An 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?
qwertox 5y ago
I was going to say the same, but if you start to read other's code, you will need deal with it. Buy I personally like it when I read other people's code and see something which I don't understand, which I've never seen, and then it turns out to be a feature which actually makes coding easier and more efficient. Then I think about all the places where I could have used that feature in my old code.

BiteCode_dev 5y ago

I hear that quite often, but up to now, I haven't seen it translate in the field. Code examples in docs and tutorials are still easy, libs api still clean, code base still readable. Optional things stayed indeed, optional. My grip is actually the contrary, many python code bases are stuck in the past. But I'm ok with it, people are not all pro devs, they need a productive language subset. And the new syntax is providing some fantastic new tools, such as pydantic/fastapi/typer (if you haven't try it, it's really paradigm shift, and I say that as a django fan). f-string are awesome. dataclasses are nothing but convenient and readable. Advanced unpacking as well. I seldom use the walrus, almost nobody does, but when one does, it's useful. > decorators, comprehensions, Those existed in python 2, 10 years ago. It's hardly new python. And web frameworks would be terrible without those.

dlisboa 5y ago
> My grip is actually the contrary, many python code bases are stuck in the past. From the outside looking in the Python community seems aggressively anti reworking their code to adapt to new language features. The 2 to 3 debacle comes to mind when compared to other languages, like JS, which made a much bigger change and everyone jumped in it and rewrote their code to adapt, or Ruby which went through some backwards incompatible changes at the same time as Python.
- scoopertrooper 5y ago
  I don't think there has been a non-backwards compatible JS change in a very long time. They even named the array flatten method as 'flat', just to avoid having a conflict with MooTools!
  - dlisboa 5y ago
    My point with JS is more that the JS community sees no problem and will actively rewrite vast swaths of code to use features that are not yet supported in browsers. Hence the extensive use of polyfills and transpilers. Major language changes are generally seen as a good thing (which they mostly are in JS' case). With Python I don't get the same feeling, they seem more resistant to change in general. I don't think it's just that Python has more so-called "non-programmers" (meaning, data science and math people). Most of the libraries for these things are made by full-time programmers anyway. Perhaps the idea that "there's only one way to do it" brought about a "the current way is good enough, why rewrite in a new one?" attitude. But anyway, I'm not familiar enough, just an outside perspective.

jcelerier 5y ago

a new simple language is created (Python) -> beginners start using it -> they become proficient in it, some build successful businesses around the language -> limits due to the simplicity are hit -> people lobby for advanced features (lambdas, match, etc) which make code much easier for the subset who understand it -> other people complain that they can't understand the code anymore -> a new simple language is created (Go) -> ... -> people lobby for advanced features (generics) -> ...

jerf 5y ago
Go's over ten years in, though, and the first really significant overhaul is still about six months out. It breaks that cycle. More on topic, I do sort of feel like maybe the Python team should have made a Newthon (with a better name) or something, because Python is becoming a shambling beast. Starting as one of the world's most dynamic OO language and then shambling towards being a static language, maybe a bit of a functional language, it's crazy. I often joke about "Katamari Dama-C++!", which has the irresistible phonetic allusion, but damn if Python isn't trying to keep up at this point. If you don't like Python for some task... use something else suited for your task, then. It's not like using something else means you must put Python down and never use it again on pain of being shot or something. Stop waiting for Python to mutate into O'Caml or something and just use O'Caml or whatever.
- kowlo 5y ago
  I googled "Katamari Dama-C++" to see what it was all about and found your post from 2014 [1]. That is impressive commitment. https://news.ycombinator.com/item?id=7315163 https://news.ycombinator.com/item?id=7315163

tragomaskhalos 5y ago

Well. I have a book that uses a minimal subset of Python as the illustrative language, and oh boy would the examples have been vastly improved if the author had gone the extra yard and added comprehensions into the mix rather than ploddingly building his transformed lists in loops like a Neanderthal. Decorators though I totally agree; had some tooling at work that was gussied up to the point of impenetrability by gratuitous use of decorators. A colleague got so fed up with it he rewrote it in Perl, which was, shockingly, actually a maintainability improvement.

mikepurvis 5y ago
Decorators become pretty hard to reason about as soon as you have to apply more than one of them to the same method. So I think there are cases for them where the ergonomics are fantastic, but exercising restraint is critical— and it's restraint on the part of API/library authors that is needed more than on the part of users, since a lot of the time, it's actually out of users' hands.
- stinos 5y ago
  This. Nothing wrong with decorators per se. Just one typical example: measuring a couple of functions execution time by just decorating them definitely fullfils what the OP wants: simple and readable. Obviously there is more than one way to measure execution time, but the 'there should be one way' mantra really only holds true for very basic things anyway imo. And yes just like any other pattern out there it can be abused. One could try and blame the language for allowing such abuse, but that is not always fair I think, and also not in this case. Bad code is written all the time all over the place, and if a language would try to really really fix that it would be way to restrictive probably and hinder development in other ways. Same story for list comprehensions: it's almost beyond me how one can be against a simple single list comprehension. It's simple, readable, almost beautiful. Now if people start nesting 5 comprehensions it's not so nice anymore; but then is the language to blame (as in, would we really want to forbid nested comprehensions?), or the people?
JoBrad 5y ago
I really love the idea of decorators. However, after having used them in some rather large projects, I have to agree that it contributes to “magic” happening elsewhere in your code that can complicate debugging quite a bit.

hvocode 5y ago

Part of me wants to disagree since some of these features make my code shorter, but I have to agree since they commit a sin of language design that I dislike - implicit magic. Decorators are useful because they can help you shrink code by letting the decorator generate boilerplate for you. The code gets smaller, but now it’s harder to know what’s going on since you need to know what magic happened behind the scenes due to the decorator. It feels very much like issues I ran into when I used C++ meta programming libraries - my code shrank, and at the same time my understanding of what it actually did also shrank. Same with the walruses - my code gets smaller because now there’s some implicit stuff happening. Comprehensions are a little less magical - if anything, they are more explicit. If I want to create a list where each element is generated by some function over another list, I just say it. Doing so with loops is obscuring what I wanted to say in the first place. The problem with comprehensions isn’t so much the comprehension, but the obtuse ways people can use them to eke out performance by avoiding explicit loops. I’m all for things that are closer to what a programmer means, but less keen on features that entail obscuring details that may come back to haunt the programmer later (I see this most often with decorators).

nyuszika7h 5y ago
I don't really agree that it's so magical, especially the walrus operator. Sure, a beginner may be confused by it, but it's really easy once you learn the difference between `=` and `:=` IMO. Python is not a language designed to be only used by beginners. Decorators may be a little more "magic", but it makes little difference in practice if you do @bar or foo = bar(foo), the former is just a cleaner syntax (and stops linters wanting you to put two blank lines between the function and the "decorator").
bluecalm 5y ago
Oh c'mon with the walrus. Assignment being an expression is the case in so many languages. They should have made it the case in Python and just be done with it. "But someone will make a typo one day resulting in = instead of ==" argument is nonsense as that hasn't been an issue since forever in other languages. You can either require parentheses if you want to use the value (the way C compilers want it) or just make it := to begin with.

dochtman 5y ago

List comprehensions date from Python 2.0 (October 2000), decorators from 2.4 (November 2004) -- so both of those are from when people called it "executable pseudocode", right? At the least there's a big discontinuity before the walrus operator appears (3.8, October 2019). I was once an avid Python user, but I switched to mostly Rust a few years ago and now write very little Python. A while ago I wrote some not quite trivial script-like code in Python, but ended up converting it to Rust before it finished running. The attraction of Python used to be that it was simple, but I now value robustness (through the type system in particular) much more than simplicity of the language.