8 ms·

As a long time Python fan, I find the current state of the language frustrating. Tools like black and poetry are nice, but are not part of the standard library.

As a long time Python fan, I find the current state of the language frustrating. Tools like black and poetry are nice, but are not part of the standard library. Yet they seem to be required by every popular project out there. (Also, black’s formatting is quite ugly, as noted in this blog post) Meanwhile, the language itself is increasingly baroque and complicated. Type-annotated, asyncio-enabled Python hardly resembles the easy-to-understand language I fell in love with back in 2006. Perhaps this is just an “old man yells at cloud” moment...

pdonis 7y ago
> Tools like black and poetry are nice, but are not part of the standard library. If black does non-PEP 8 formatting, as the article says, then I would not expect it to be in the standard library, since PEP 8 formatting is the Python standard. > the language itself is increasingly baroque and complicated I don't find current Python 3 any more baroque or complicated than Python 2.7. In fact I have plenty of Python code that runs just fine, unmodified, under both interpreters. And I have plenty of other Python code that only needs from __future__ import print_function to run unmodified under both interpreters. That's not to say I think there are no issues with current Python 3; just that I wouldn't describe those issues as "the language is increasingly baroque and complicated". See further comments below. > Type-annotated, asyncio-enabled Python hardly resembles the language I fell in love with back in 2006. You don't have to use these features if you don't want or need them. Nobody uses 100% of any language's features, and the subset that is used can be very different from person to person. I don't see that as a problem. I did see the way the Python 3 transition was handled as a big problem, but that's water under the bridge now and the issues that gave many people headaches during the transition were pretty much resolved by Python 3.3. The two big problems I see with current Python 3 are memory usage and the GIL. Python 3 objects take more memory than Python 2 objects did; for programs that create a lot of objects that can be an issue. (To be fair, many such programs are numerical simulations that can take advantage of the many optimizations in the NumPy and SciPy libraries.) There seems to be work in progress on supporting multiple interpreters running in the same Python process, which would fix the GIL issue, but it's too soon to see if that will really address the issues surrounding the GIL.
- saagarjha 7y ago
  > Nobody uses 100% of any language's features There are massive differences between languages, though. I think I might use close to 70% of Objective-C's or Java's features regularly, while I can't even hope to use 50% of C++'s.
- petersellers 7y ago
  > You don't have to use these features if you don't want or need them. Nobody uses 100% of any language's features, and the subset that is used can be very different from person to person. I don't see that as a problem. The problem is that other people might use those features and you also might have to read the code created by those people.
  - jordic 7y ago
    And what's the problem on having some type hints on some func signatures?) You can read python exactly the same way (with and without type hints)....
    - tonyedgecombe 7y ago
      It's just one more thing you have to get to learn. I have the same problem with classes in JavaScript. You can't ignore them and stick to prototypes nor ignore prototypes and stick to classes. What should have been a simplification has turned out to make things more complex.
      - oefrha 7y ago
        Unlike ES6 classes, you absolutely can ignore type hints (and they're easy to ignore). In fact they're basically inline comments, and the interpreter ignores them too.
      - jordic 7y ago
        Anyway es6 classes it's just a proper way of doing Oop in js.. the prototypal thing it's so ugly...
blondin 7y ago
> Type-annotated, asyncio-enabled Python hardly resembles the easy-to-understand language I fell in love with back in 2006. true. i am all for types in general and for types annotations in python. but i have seen some heavily type-annotated python code lately and i don't think that's where we want to be. we are starting to look like a heavily templatized cpp code.
- jordic 7y ago
  Don't mix things, guy! - asyncio it's one thing: From my point of view it's amazing... makes python be able to compete with nodejs or go.. (not so hard, if you work also on the browser) - mypy: that's another story, but it's also optional, use it if you want... (my opinion, like in typescript, if I want types I will do it with go or rust)
  - wyclif 7y ago
    Right. Projects can always choose not to enable asyncio. I don't see what the problem is. Right tool for the job, &c.
  - nine_k 7y ago
    Good luck finding a pandas or scipy implementation for go or rust :-/
    - philipov 7y ago
      "BlackJack strives to be a full featured crate for general data processing. Long term goal is to create a lightweight Pandas equivalent by and for the Rust community, but with slight differences in focus..." https://docs.rs/black-jack/0.1.0/blackjack/ https://docs.rs/black-jack/0.1.0/blackjack/ EDIT: That one looks like it's not being worked on actively. Here's a reddit thread with more ideas. Weld looks interesting. https://www.reddit.com/r/rust/comments/apo66e/dataframes_what_do_you_need/ https://www.reddit.com/r/rust/comments/apo66e/dataframes_wha... https://www.weld.rs/ https://www.weld.rs/ And Arrow looks like a new project Wes McKinney is contributing to. http://arrow.apache.org/ http://arrow.apache.org/
didibus 7y ago
I think this can be the curse of popularity. The demand from more and more users of different feature, especially backed by industries who rely on the language, means that slowly over time, all popular languages accumulate scope and feature creep to some extent. But at the same time, for serious industry work, those features do come in handy when you do need them. I think this is why to some extent you never hear that much good of the old tried and tested languages. They always feel bloated, disorganized, confusing, with too much cruft, and yet it's all that which make them what they are.
jaimex2 7y ago
Theres always Ruby
- unixhero 7y ago
  Ruby is so great. I will switch as soon as I can.
- NegativeLatency 7y ago
  Ruby has solid package management too
rumanator 7y ago
Why do you believe that providing hints to which is the type of a variable is something that makes the language barroque and complicated?
- Barrin92 7y ago
  not the OP but I share the sentiment. On a syntax level simply because it adds types, and one of the joys of writing a dynamic language is that you don't have types filling so much of your code. But much more important to me, on a semantic level. Late binding of all things is a feature of dynamic languages, not a bug. I have no idea why we're trying to force a static typing mindset onto a dynamic language. I wish we could all remember that the original idea of OO is that objects interpret the messages they receive, not external typecheckers.
  - slightwinder 7y ago
    > On a syntax level simply because it adds types, and one of the joys of writing a dynamic language is that you don't have types filling so much of your code. Then good that you don't have to do that. Type hinting in python is optional and it's unlikely that this will ever change. > I have no idea why we're trying to force a static typing mindset onto a dynamic language. Because python ist not a toy-language anymore. It's used for big projects too, and for them features like this are very neccessary.
    - Barrin92 7y ago
      >Because python ist not a toy-language anymore. It's used for big projects too, and for them features like this are very neccessary. I've worked on multi-million line dynamic codebases in settings that require robustness and correctness (telecommunications/Erlang) and it's an absolute ridiculous idea that one needs type checking to build industry standard codebases and architecture. The Java/C++ paradigm is not the only software paradigm to built correct software.
Silhouette 7y ago
Perhaps this is just an “old man yells at cloud” moment... Fellow "old man" reporting for duty. I see a similar set of problems with both Python and JavaScript today (and with various other languages as well, but IME Python and JS are the worst offenders). Both have proven to be useful for various applications. Each started with quite a distinctive style. There were plenty of warts in each case, but overall the "feel" of each language was well understood, and there was a certain simplicity about them that made them accessible to new programmers or to programmers who primarily used other languages. However, over time, people have applied the kitchen sink approach to both language and tooling. Functional programming is all the rage, and these languages have lambdas (albeit very clumsy ones), so let's all write lots of FP-style code in them! Except you can't, because they are horrible for writing FP-style code, because they lack FP features, they lack efficient and clear syntax for FP idioms, and they do not provide some of the guarantees that benefit FP. Similarly, a lot of programmers are realising that static typing has its merits when you're trying to build serious software at scale, so let's all add type annotations and start marking up our code! Except that both the existing type systems and idiomatic use of these languages are built around dynamic behaviour, so they lack powerful tools for constructing new types, and they lack efficient and clear syntax for specifying static types, and they lack comprehensive type inference, and the continued presence of dynamic typing means you can't prove a lot of otherwise useful properties of your code anyway. The amount of tooling expected to do even basic development with these languages today is absurd. Professional-quality programming ought to need no more than a compiler/interpreter, a decent editor and a decent source control system to be productive. On the next level, we might find a tool to automate running tests and reporting the results, a debugger and a profiler; I count these as secondary because it should really be possible to work reasonably well without them but they can make common tasks significantly more efficient and/or accurate. The lack of a package manager tool in both of these lists is not an accident. I think just as much of today's programming industry has forgotten about the benefits of stability, backward and forward compatibility, and standardisation in the software we make, we have also forgotten about them in our own tools. Do we really need 27 new frameworks for building web apps this year? Is having 41 libraries to do basic unit testing that each use slightly different syntax and vary in <5% of the features they provide really worth the added complexity in the ecosystem? How on earth does JS not have a decent standard library yet? Maybe it's time to slow down, and make carefully considered choices about the tools and libraries we use in our work, instead of instinctively reaching for that package manager and installing... well, let's be honest, most of the time we don't really know exactly what we're installing, do we?
koonsolo 7y ago
> hardly resembles the easy-to-understand language I fell in love with back in 2006. I used to love Python back in those days. Even did a big project with multiple developers in it. Then I didn't use it for a while and came back for some easy scripting. I was absolutely horrified how complex things are right now. Ditched it and doing my scripting with node.js.
- FridgeSeal 7y ago
  > ditching Python on account of it being too complex > chooses NodeJS Congratulations on picking a language with even more weird pitfalls and edge cases? JS is not what I’d call a simple, straightforward language.
  - koonsolo 7y ago
    I care about writing clean and simple code in an easy way. I found that the node ecosystem with npm packages allows me to do this very well. I had that same feeling in the 2.4-2.5 days of Python. But now it was really hard to find simple API's. Let me give you an example about parsing JSON. This is the Python way: json.load(fp, , cls=None, object_hook=None, parse_float=None, parse_int=None, parse_constant=None, object_pairs_hook=None, kw) Seriously, how F(&#$%@ING complex can you make the thing? This is Javascript: JSON.parse(text[, reviver]) Ah, that's the way I like it :) But hey, if you want all that argument power, no problem for me. I'm a simple programmer, liking simple things. And that was my point, Python has lost its simple ways. The JavaScript language might have some weird shit, but I don't care about that because I can stay far away from it. I care about simple programming.
    - Cpoll 7y ago
      > json.load(fp, , cls=None, object_hook=None, parse_float=None, parse_int=None, parse_constant=None, object_pairs_hook=None, kw) It looks like you copied that from https://docs.python.org/3/library/json.html https://docs.python.org/3/library/json.html Those are all optional parameters, if you don't need them it's just: json.load(fp) Which, to the best of my knowledge will behave just like the JS version.
adonese 7y ago
> Type-annotated, asyncio-enabled Python hardly resembles the easy-to-understand language I fell in love with back in 2006. I'm all with this, but you can pretty much use python without touching these at all. They have a niche business use cases. E.g., when you work on large projects and you want to catch some errors to not be in the runtime. async was very needed to be able to write performant web servers such as nodejs. I'm not using python as i used to, and i think the language is getting more complex, and i'd definitely vow for more fundamental changes to the runtime. But if you ignored all of that, python is still remain python. And when your business logic gets more complex, it is imperative your code becomes more complex and you get to discover and use more "language advanced features". The good thing they are available, they are not perfect, but they can be of a good help.
- fastball 7y ago
  I don't think catching errors before runtime is a niche business use case.
jimmaswell 7y ago
print as a function and headache-inducing string handling hardly resemble the python I came to like either. those two things bring python3 down from great to meh for me. biggest language change blunders I've ever seen. I feel a wave of disappointment every time I have to type a paren on a print call in python3.
- tcbasche 7y ago
  I can't even tell if this is sarcastic or not
  - jimmaswell 7y ago
    it's not. the language has abandoned its principles of simplicity and convenience.
    - tcbasche 7y ago
      right. by adding parentheses to the print function ... ? Surely you have bigger things to worry about
- _ZeD_ 7y ago
  > print as a function yessss... because a pair of parentesys are too much... I always hated that I couldn't pass "print" as a callback, or the weird >> syntax to write on stderr

pdonis 7y ago

> Tools like black and poetry are nice, but are not part of the standard library. If black does non-PEP 8 formatting, as the article says, then I would not expect it to be in the standard library, since PEP 8 formatting is the Python standard. > the language itself is increasingly baroque and complicated I don't find current Python 3 any more baroque or complicated than Python 2.7. In fact I have plenty of Python code that runs just fine, unmodified, under both interpreters. And I have plenty of other Python code that only needs from __future__ import print_function to run unmodified under both interpreters. That's not to say I think there are no issues with current Python 3; just that I wouldn't describe those issues as "the language is increasingly baroque and complicated". See further comments below. > Type-annotated, asyncio-enabled Python hardly resembles the language I fell in love with back in 2006. You don't have to use these features if you don't want or need them. Nobody uses 100% of any language's features, and the subset that is used can be very different from person to person. I don't see that as a problem. I did see the way the Python 3 transition was handled as a big problem, but that's water under the bridge now and the issues that gave many people headaches during the transition were pretty much resolved by Python 3.3. The two big problems I see with current Python 3 are memory usage and the GIL. Python 3 objects take more memory than Python 2 objects did; for programs that create a lot of objects that can be an issue. (To be fair, many such programs are numerical simulations that can take advantage of the many optimizations in the NumPy and SciPy libraries.) There seems to be work in progress on supporting multiple interpreters running in the same Python process, which would fix the GIL issue, but it's too soon to see if that will really address the issues surrounding the GIL.

saagarjha 7y ago
> Nobody uses 100% of any language's features There are massive differences between languages, though. I think I might use close to 70% of Objective-C's or Java's features regularly, while I can't even hope to use 50% of C++'s.
petersellers 7y ago
> You don't have to use these features if you don't want or need them. Nobody uses 100% of any language's features, and the subset that is used can be very different from person to person. I don't see that as a problem. The problem is that other people might use those features and you also might have to read the code created by those people.
- jordic 7y ago
  And what's the problem on having some type hints on some func signatures?) You can read python exactly the same way (with and without type hints)....
  - tonyedgecombe 7y ago
    It's just one more thing you have to get to learn. I have the same problem with classes in JavaScript. You can't ignore them and stick to prototypes nor ignore prototypes and stick to classes. What should have been a simplification has turned out to make things more complex.
    - oefrha 7y ago
      Unlike ES6 classes, you absolutely can ignore type hints (and they're easy to ignore). In fact they're basically inline comments, and the interpreter ignores them too.
    - jordic 7y ago
      Anyway es6 classes it's just a proper way of doing Oop in js.. the prototypal thing it's so ugly...

blondin 7y ago

> Type-annotated, asyncio-enabled Python hardly resembles the easy-to-understand language I fell in love with back in 2006. true. i am all for types in general and for types annotations in python. but i have seen some heavily type-annotated python code lately and i don't think that's where we want to be. we are starting to look like a heavily templatized cpp code.

jordic 7y ago
Don't mix things, guy! - asyncio it's one thing: From my point of view it's amazing... makes python be able to compete with nodejs or go.. (not so hard, if you work also on the browser) - mypy: that's another story, but it's also optional, use it if you want... (my opinion, like in typescript, if I want types I will do it with go or rust)
- wyclif 7y ago
  Right. Projects can always choose not to enable asyncio. I don't see what the problem is. Right tool for the job, &c.
- nine_k 7y ago
  Good luck finding a pandas or scipy implementation for go or rust :-/
  - philipov 7y ago
    "BlackJack strives to be a full featured crate for general data processing. Long term goal is to create a lightweight Pandas equivalent by and for the Rust community, but with slight differences in focus..." https://docs.rs/black-jack/0.1.0/blackjack/ https://docs.rs/black-jack/0.1.0/blackjack/ EDIT: That one looks like it's not being worked on actively. Here's a reddit thread with more ideas. Weld looks interesting. https://www.reddit.com/r/rust/comments/apo66e/dataframes_what_do_you_need/ https://www.reddit.com/r/rust/comments/apo66e/dataframes_wha... https://www.weld.rs/ https://www.weld.rs/ And Arrow looks like a new project Wes McKinney is contributing to. http://arrow.apache.org/ http://arrow.apache.org/

didibus 7y ago

I think this can be the curse of popularity. The demand from more and more users of different feature, especially backed by industries who rely on the language, means that slowly over time, all popular languages accumulate scope and feature creep to some extent. But at the same time, for serious industry work, those features do come in handy when you do need them. I think this is why to some extent you never hear that much good of the old tried and tested languages. They always feel bloated, disorganized, confusing, with too much cruft, and yet it's all that which make them what they are.

jaimex2 7y ago

Theres always Ruby

unixhero 7y ago
Ruby is so great. I will switch as soon as I can.
NegativeLatency 7y ago
Ruby has solid package management too

rumanator 7y ago

Why do you believe that providing hints to which is the type of a variable is something that makes the language barroque and complicated?

Barrin92 7y ago
not the OP but I share the sentiment. On a syntax level simply because it adds types, and one of the joys of writing a dynamic language is that you don't have types filling so much of your code. But much more important to me, on a semantic level. Late binding of all things is a feature of dynamic languages, not a bug. I have no idea why we're trying to force a static typing mindset onto a dynamic language. I wish we could all remember that the original idea of OO is that objects interpret the messages they receive, not external typecheckers.
- slightwinder 7y ago
  > On a syntax level simply because it adds types, and one of the joys of writing a dynamic language is that you don't have types filling so much of your code. Then good that you don't have to do that. Type hinting in python is optional and it's unlikely that this will ever change. > I have no idea why we're trying to force a static typing mindset onto a dynamic language. Because python ist not a toy-language anymore. It's used for big projects too, and for them features like this are very neccessary.
  - Barrin92 7y ago
    >Because python ist not a toy-language anymore. It's used for big projects too, and for them features like this are very neccessary. I've worked on multi-million line dynamic codebases in settings that require robustness and correctness (telecommunications/Erlang) and it's an absolute ridiculous idea that one needs type checking to build industry standard codebases and architecture. The Java/C++ paradigm is not the only software paradigm to built correct software.

Silhouette 7y ago

Perhaps this is just an “old man yells at cloud” moment... Fellow "old man" reporting for duty. I see a similar set of problems with both Python and JavaScript today (and with various other languages as well, but IME Python and JS are the worst offenders). Both have proven to be useful for various applications. Each started with quite a distinctive style. There were plenty of warts in each case, but overall the "feel" of each language was well understood, and there was a certain simplicity about them that made them accessible to new programmers or to programmers who primarily used other languages. However, over time, people have applied the kitchen sink approach to both language and tooling. Functional programming is all the rage, and these languages have lambdas (albeit very clumsy ones), so let's all write lots of FP-style code in them! Except you can't, because they are horrible for writing FP-style code, because they lack FP features, they lack efficient and clear syntax for FP idioms, and they do not provide some of the guarantees that benefit FP. Similarly, a lot of programmers are realising that static typing has its merits when you're trying to build serious software at scale, so let's all add type annotations and start marking up our code! Except that both the existing type systems and idiomatic use of these languages are built around dynamic behaviour, so they lack powerful tools for constructing new types, and they lack efficient and clear syntax for specifying static types, and they lack comprehensive type inference, and the continued presence of dynamic typing means you can't prove a lot of otherwise useful properties of your code anyway. The amount of tooling expected to do even basic development with these languages today is absurd. Professional-quality programming ought to need no more than a compiler/interpreter, a decent editor and a decent source control system to be productive. On the next level, we might find a tool to automate running tests and reporting the results, a debugger and a profiler; I count these as secondary because it should really be possible to work reasonably well without them but they can make common tasks significantly more efficient and/or accurate. The lack of a package manager tool in both of these lists is not an accident. I think just as much of today's programming industry has forgotten about the benefits of stability, backward and forward compatibility, and standardisation in the software we make, we have also forgotten about them in our own tools. Do we really need 27 new frameworks for building web apps this year? Is having 41 libraries to do basic unit testing that each use slightly different syntax and vary in <5% of the features they provide really worth the added complexity in the ecosystem? How on earth does JS not have a decent standard library yet? Maybe it's time to slow down, and make carefully considered choices about the tools and libraries we use in our work, instead of instinctively reaching for that package manager and installing... well, let's be honest, most of the time we don't really know exactly what we're installing, do we?

koonsolo 7y ago

> hardly resembles the easy-to-understand language I fell in love with back in 2006. I used to love Python back in those days. Even did a big project with multiple developers in it. Then I didn't use it for a while and came back for some easy scripting. I was absolutely horrified how complex things are right now. Ditched it and doing my scripting with node.js.

FridgeSeal 7y ago
> ditching Python on account of it being too complex > chooses NodeJS Congratulations on picking a language with even more weird pitfalls and edge cases? JS is not what I’d call a simple, straightforward language.
- koonsolo 7y ago
  I care about writing clean and simple code in an easy way. I found that the node ecosystem with npm packages allows me to do this very well. I had that same feeling in the 2.4-2.5 days of Python. But now it was really hard to find simple API's. Let me give you an example about parsing JSON. This is the Python way: json.load(fp, , cls=None, object_hook=None, parse_float=None, parse_int=None, parse_constant=None, object_pairs_hook=None, kw) Seriously, how F(&#$%@ING complex can you make the thing? This is Javascript: JSON.parse(text[, reviver]) Ah, that's the way I like it :) But hey, if you want all that argument power, no problem for me. I'm a simple programmer, liking simple things. And that was my point, Python has lost its simple ways. The JavaScript language might have some weird shit, but I don't care about that because I can stay far away from it. I care about simple programming.
  - Cpoll 7y ago
    > json.load(fp, , cls=None, object_hook=None, parse_float=None, parse_int=None, parse_constant=None, object_pairs_hook=None, kw) It looks like you copied that from https://docs.python.org/3/library/json.html https://docs.python.org/3/library/json.html Those are all optional parameters, if you don't need them it's just: json.load(fp) Which, to the best of my knowledge will behave just like the JS version.

adonese 7y ago

> Type-annotated, asyncio-enabled Python hardly resembles the easy-to-understand language I fell in love with back in 2006. I'm all with this, but you can pretty much use python without touching these at all. They have a niche business use cases. E.g., when you work on large projects and you want to catch some errors to not be in the runtime. async was very needed to be able to write performant web servers such as nodejs. I'm not using python as i used to, and i think the language is getting more complex, and i'd definitely vow for more fundamental changes to the runtime. But if you ignored all of that, python is still remain python. And when your business logic gets more complex, it is imperative your code becomes more complex and you get to discover and use more "language advanced features". The good thing they are available, they are not perfect, but they can be of a good help.

fastball 7y ago
I don't think catching errors before runtime is a niche business use case.

jimmaswell 7y ago

print as a function and headache-inducing string handling hardly resemble the python I came to like either. those two things bring python3 down from great to meh for me. biggest language change blunders I've ever seen. I feel a wave of disappointment every time I have to type a paren on a print call in python3.

tcbasche 7y ago
I can't even tell if this is sarcastic or not
- jimmaswell 7y ago
  it's not. the language has abandoned its principles of simplicity and convenience.
  - tcbasche 7y ago
    right. by adding parentheses to the print function ... ? Surely you have bigger things to worry about
_ZeD_ 7y ago
> print as a function yessss... because a pair of parentesys are too much... I always hated that I couldn't pass "print" as a callback, or the weird >> syntax to write on stderr