4 ms·

The syntax and semantics of the language change in non-reverse-compatible ways between every minor release. This is independent of project management. As an e

The syntax and semantics of the language change in non-reverse-compatible ways between every minor release. This is independent of project management. As an example, between 2.3 and 2.5, the syntax for package variables was changed (and then the semantics were changed between 2.5 and 2.7). There is nothing you can do as a python user to ameliorate the impact of such changes other than to not use those language features. Can you explain how "managing my project better" would have allowed me to avoid the impact of this change?

dragonwriter 3y ago
> The syntax and semantics of the language change in non-reverse-compatible ways between every minor release. Even accepting this and assuming the average project was bit by every single one, the release cadence for minor versions is aboit once per year (recently, almost exactly that, in October), and minor versions are supported for 5 years, so this would justify updates every year if you were a maximally eager adopter, or every five years with a maximally conservative while only using in-support versions approach, or somewhere in between for less extreme cases, not every three months. > As an example, between 2.3 and 2.5, the syntax for package variables was changed (and then the semantics were changed between 2.5 and 2.7). 2.7 was released 13 years ago. Why would you reach that far back for a relevant example?
- retrocryptid 3y ago
  Because you asked for an example. If you don't want the answer, don't ask the question.
acdha 3y ago
That’s three years, not months, and consider that it’s possible that how we develop software as a field might have matured over multiple decades. The edge case you’re referring two didn’t even affect most packages in the 2000s so it’s quite a stretch to say that something which happened in 2006 embodies how Python is developed now.
- retrocryptid 3y ago
  Don't take this the wrong way, but I don't really care about how your 2.3 apps were or were not affected. It's not my job to maintain them. The apps I cared about were the apps I had to mantain. And it turns out that if you have tens of thousands of lines of python, you eventually hit a problem that needs to be fixed. So sure... if you have a 200 line program, maybe you won't hit any code whose semantics have changed. Large apps will (and still do.)
  - acdha 3y ago
    So say “when I worked on a Python project many years, we had a lot of problems with one release” – people might find it weird that you’re bringing up old history but nobody is going to doubt that you personally had an unpleasant experience. It’s okay not to like Python! What’s getting criticism are these huge sweeping claims like “you rewrite your code every three months” or “syntax and semantics of the language change in non-reverse-compatible ways between every minor release” which you have been completely unable to support or the attempts to dismiss anyone else’s different experiences as somehow less valid.

dragonwriter 3y ago

> The syntax and semantics of the language change in non-reverse-compatible ways between every minor release. Even accepting this and assuming the average project was bit by every single one, the release cadence for minor versions is aboit once per year (recently, almost exactly that, in October), and minor versions are supported for 5 years, so this would justify updates every year if you were a maximally eager adopter, or every five years with a maximally conservative while only using in-support versions approach, or somewhere in between for less extreme cases, not every three months. > As an example, between 2.3 and 2.5, the syntax for package variables was changed (and then the semantics were changed between 2.5 and 2.7). 2.7 was released 13 years ago. Why would you reach that far back for a relevant example?

retrocryptid 3y ago
Because you asked for an example. If you don't want the answer, don't ask the question.

acdha 3y ago

That’s three years, not months, and consider that it’s possible that how we develop software as a field might have matured over multiple decades. The edge case you’re referring two didn’t even affect most packages in the 2000s so it’s quite a stretch to say that something which happened in 2006 embodies how Python is developed now.

retrocryptid 3y ago
Don't take this the wrong way, but I don't really care about how your 2.3 apps were or were not affected. It's not my job to maintain them. The apps I cared about were the apps I had to mantain. And it turns out that if you have tens of thousands of lines of python, you eventually hit a problem that needs to be fixed. So sure... if you have a 200 line program, maybe you won't hit any code whose semantics have changed. Large apps will (and still do.)
- acdha 3y ago
  So say “when I worked on a Python project many years, we had a lot of problems with one release” – people might find it weird that you’re bringing up old history but nobody is going to doubt that you personally had an unpleasant experience. It’s okay not to like Python! What’s getting criticism are these huge sweeping claims like “you rewrite your code every three months” or “syntax and semantics of the language change in non-reverse-compatible ways between every minor release” which you have been completely unable to support or the attempts to dismiss anyone else’s different experiences as somehow less valid.