5 ms·

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, cod

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.
jerf 5y ago
I have seen someone who could program, but was a non-programmer, try to learn Python for testing purposes, using a testing framework that did all sorts of magic with decorators, magically deciding what to call your function with based on what parameter names you gave your callbacks, etc. It was awful. That was when I officially stopped recommending Python as a new language. It's just got too many things to explain now. And too many of those things to explain are like decorators, which requires two explanations, one to explain what it looks like they are doing when you use a decorator prepared by someone else, and a second explanation about what they are actually doing if someone ever wants to write one of their own. It looks like "x.y" resolves the "y" value out of the instance, but actually, it's this complicated thing so that properties and other things work. It looks like the for loop simply ranges over the list, but it's actually this thing with iterators. It looks like calling this function "yields" a list but it's actually this magical thing where using a "yield" in the function body completely and non-locally changes the entire function. It looks like.... When Python was new and the list of this "it looks like..." was short, it was kinda need to be able to override __getitem__ for certain useful effects and such, but stacking on more and more of these with every release has created a real monster of comprehension. Now it feels like Python has raised "it looks like... but actually..." to a design principle. It looks like the match operator simply takes the argument you give it and sees if it is the same "shape" as the case statements, but it actually consults a new magic class variable and has this logic and that logic and....
- andybak 5y ago
  > using a testing framework that did all sorts of magic with decorators This seems a little unfair. Testing frameworks are notorious for pushing the envelope of language constructs and weird introspection tricks. And if in this case you picked an exceptionally ripe example I'm not sure that should reflect on the entire language. Back in the day people used to use the baroque nature of some frameworks such as Zope to bash Python but Zope was an outlier. There will always be some gorgonzola in any ecosystem.
  - KronisLV 5y ago
    > And if in this case you picked an exceptionally ripe example I'm not sure that should reflect on the entire language. I'm not sure i agree entirely: regardless of whether we're talking about decorators/annotations in Python/Java/.NET/... in the context of testing/web/... frameworks, any and every of those combinations have only caused me pain and headaches. While i do agree in principle that it's nice to abstract away code with something that annotates a method and gives it additional meaning, in practice this sort of indirection usually has something to do with dynamic code calls, reflection or whatever the idiom is called in any particular language. All of those feel harder to debug and more brittle than just writing 3 lines of code instead of 1 annotation/decorator. The problem with that, is that it's usually: - hard to make your own decorators/annotations (especially if you want to extend their functionality) - hard to introduce state, dependencies and just get them working nicely with the rest of your codebase and IoC/testing frameworks, or pass data between the logic behind them (from one decorator/annotation to another) - hard to use them, as opposed to your "regular mode" of writing code, IDEs won't offer many refactoring options - hard to debug them, especially in the case of wanting to examine their internals and use breakpoints To me, it just generally seems like someone is trying to tack on functionality in ways that are hard to utilize, as opposed to just writing code in the first place, the very same thing that you see happen with generics, deeply nested inheritance and other "tricks" which are supposed to make one's life easier but do the opposite in practice in many cases. Personally, i enjoy libraries like Typer (https://typer.tiangolo.com/ https://typer.tiangolo.com/) for Python and think that it has plenty of use cases, but i've been hurt far too many times by similar functionality in non-trivial cases in every single language that i've used that supports something like that, so at best i'm guarded about utilizing them. Java rant: But perhaps that's just because Java is a major source of pain for me in that regard. To give you a concrete example: i'm migrating Spring to Spring boot and someone used Jersey instead of RESTEasy as their JAX-RS implementation and now i need to transpose hundreds of API endpoint definitions (for example @GET to @GetMapping with bunches of parameters). If it were just Java code, i could probably use some clever refactoring in it with the help of my IDE, but now i'd have to figure out where the annotations come from, create a stub to replace them, call the proper stuff from within them and hope it works, unless the reflection that's used by them breaks. Not only that, but debugging is kind of hard when the source code and the actual logic behind said annotation is hidden below dozens of layers of Eldritch indirection and you have no chances of feasibly finding all of that stuff out.

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.

jerf 5y ago

I have seen someone who could program, but was a non-programmer, try to learn Python for testing purposes, using a testing framework that did all sorts of magic with decorators, magically deciding what to call your function with based on what parameter names you gave your callbacks, etc. It was awful. That was when I officially stopped recommending Python as a new language. It's just got too many things to explain now. And too many of those things to explain are like decorators, which requires two explanations, one to explain what it looks like they are doing when you use a decorator prepared by someone else, and a second explanation about what they are actually doing if someone ever wants to write one of their own. It looks like "x.y" resolves the "y" value out of the instance, but actually, it's this complicated thing so that properties and other things work. It looks like the for loop simply ranges over the list, but it's actually this thing with iterators. It looks like calling this function "yields" a list but it's actually this magical thing where using a "yield" in the function body completely and non-locally changes the entire function. It looks like.... When Python was new and the list of this "it looks like..." was short, it was kinda need to be able to override __getitem__ for certain useful effects and such, but stacking on more and more of these with every release has created a real monster of comprehension. Now it feels like Python has raised "it looks like... but actually..." to a design principle. It looks like the match operator simply takes the argument you give it and sees if it is the same "shape" as the case statements, but it actually consults a new magic class variable and has this logic and that logic and....

andybak 5y ago
> using a testing framework that did all sorts of magic with decorators This seems a little unfair. Testing frameworks are notorious for pushing the envelope of language constructs and weird introspection tricks. And if in this case you picked an exceptionally ripe example I'm not sure that should reflect on the entire language. Back in the day people used to use the baroque nature of some frameworks such as Zope to bash Python but Zope was an outlier. There will always be some gorgonzola in any ecosystem.
- KronisLV 5y ago
  > And if in this case you picked an exceptionally ripe example I'm not sure that should reflect on the entire language. I'm not sure i agree entirely: regardless of whether we're talking about decorators/annotations in Python/Java/.NET/... in the context of testing/web/... frameworks, any and every of those combinations have only caused me pain and headaches. While i do agree in principle that it's nice to abstract away code with something that annotates a method and gives it additional meaning, in practice this sort of indirection usually has something to do with dynamic code calls, reflection or whatever the idiom is called in any particular language. All of those feel harder to debug and more brittle than just writing 3 lines of code instead of 1 annotation/decorator. The problem with that, is that it's usually: - hard to make your own decorators/annotations (especially if you want to extend their functionality) - hard to introduce state, dependencies and just get them working nicely with the rest of your codebase and IoC/testing frameworks, or pass data between the logic behind them (from one decorator/annotation to another) - hard to use them, as opposed to your "regular mode" of writing code, IDEs won't offer many refactoring options - hard to debug them, especially in the case of wanting to examine their internals and use breakpoints To me, it just generally seems like someone is trying to tack on functionality in ways that are hard to utilize, as opposed to just writing code in the first place, the very same thing that you see happen with generics, deeply nested inheritance and other "tricks" which are supposed to make one's life easier but do the opposite in practice in many cases. Personally, i enjoy libraries like Typer (https://typer.tiangolo.com/ https://typer.tiangolo.com/) for Python and think that it has plenty of use cases, but i've been hurt far too many times by similar functionality in non-trivial cases in every single language that i've used that supports something like that, so at best i'm guarded about utilizing them. Java rant: But perhaps that's just because Java is a major source of pain for me in that regard. To give you a concrete example: i'm migrating Spring to Spring boot and someone used Jersey instead of RESTEasy as their JAX-RS implementation and now i need to transpose hundreds of API endpoint definitions (for example @GET to @GetMapping with bunches of parameters). If it were just Java code, i could probably use some clever refactoring in it with the help of my IDE, but now i'd have to figure out where the annotations come from, create a stub to replace them, call the proper stuff from within them and hope it works, unless the reflection that's used by them breaks. Not only that, but debugging is kind of hard when the source code and the actual logic behind said annotation is hidden below dozens of layers of Eldritch indirection and you have no chances of feasibly finding all of that stuff out.