4 ms·

Is this a cpu-heavy workload? If it's mostly io-heavy, I could see a gevent + pypy approach getting 50x better.

by ddorian43 3y ago

retrocryptid 3y ago
[flagged]
- infecto 3y ago
  Why is that?
- dragonwriter 3y ago
  I don’t tend rewrite Python code any more often than is needed due to feature changes or occasionally refactoring to pay off some maintenance friction caused by design that has in practice turned out to be suboptimal. What are you talking about?
  - retrocryptid 3y ago
    When you move from one minor rev of python to the next, some language feature changes (either syntax or semantics or features no longer work.) For instance... if you use async io in 2.x, the debugger stops working. Between 2.3, 2.5 and 2.7, the syntax of package variable scoping changed and then the semantics changed from package to class variables. If you used a feature like package variables in your code in 2.3, that code would not work in 2.5. If you fixed it in 2.5, the semantics changed so that if you defined a package variable according to the 2.5 syntax, but it was defined within a class, it became a class variable. This is just an example.
    - dragonwriter 3y ago
      > When you move from one minor rev of python to the next, some language feature changes Even if there was a breaking change affecting your project every minor version, to have the cadence of backward-compatibility induced changes you siggest you’d have to be switching Python versions forward about four times as fast as they are released, which, if you started with the oldest in support version at the beginning of the project, you could only sustain for about a year and a half, before running out of versions to switch forward to. > If you used a feature like package variables in your code in 2.3, Then you are probably out yelling at kids to get off your lawn; 2.3 being out of support for 12 years.
      - retrocryptid 3y ago
        I bring up 2.3 to 2.5 to 2.7 as an example, not as a recommendation.
- coldtea 3y ago
  In what planet? This has absolutely no bearing to the Python experience. And I'm using the stuff for 20 years.
  - retrocryptid 3y ago
    That's great that your 5 line scripts don't use features that change between revs, but people who have to maintain large python apps have to book time to pore over the latest language version's definition, update our linting tools to find where in the codebase we use a deprecated feature, change the code, update the tests, retest and redeploy. Not to mention getting a version clean dependency closure. Though we have forked and rewritten some of the non-standard modules we're dependent on to be less broken and to give credit where due, it does seem like standard modules supporting python3 are version clean unlike python2 and 1.6. The heuristic we use is about an hour of dev time per 750 lines of code so our 70,000 line legacy python app takes somewhere around 100 dev hours per minor revision upgrade. Compare this to a legacy C application written in 1989. How do we port it to the latest version of C? We just copy it and compile. That community went to a lot of trouble to ensure code written in previous versions of the language still worked. The last time I heard of a language feature being deprecated was in 2011 (though I think gcc recently undefeated support for trigraphs.) In my opinion, your python baby is ugly. It was ugly in 1.6. It was ugly in 2.x. And it remains ugly in the 3.x era. You should come to terms with the fact that some people just don't like python.
    - acdha 3y ago
      > You should come to terms with the fact that some people just don't like python. Nobody cares about that - it’s a given that any language will have fans and detractors and most of us are mature enough to focus on what works for the projects and teams we’re part of. What we’re objecting to is portraying your experience as a global truth. If you don’t like it, sure, but unverifiable hyperbole isn’t contributing anything but noise. This could be your opportunity to learn what tools or practices people use or consider whether the way you want to use the language is at odds with the core developers’ view.
- acdha 3y ago
  Flagged for being silly flamebait. The Python projects you have personal experience with might have been poorly run but that’s not representative of the language, and it’s not going to lead to a conversation where anyone learns something.
  - retrocryptid 3y ago
    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.

Is this a cpu-heavy workload? If it's mostly io-heavy, I could see a gevent + pypy approach getting 50x better.

retrocryptid 3y ago

[flagged]

infecto 3y ago
Why is that?
dragonwriter 3y ago
I don’t tend rewrite Python code any more often than is needed due to feature changes or occasionally refactoring to pay off some maintenance friction caused by design that has in practice turned out to be suboptimal. What are you talking about?
- retrocryptid 3y ago
  When you move from one minor rev of python to the next, some language feature changes (either syntax or semantics or features no longer work.) For instance... if you use async io in 2.x, the debugger stops working. Between 2.3, 2.5 and 2.7, the syntax of package variable scoping changed and then the semantics changed from package to class variables. If you used a feature like package variables in your code in 2.3, that code would not work in 2.5. If you fixed it in 2.5, the semantics changed so that if you defined a package variable according to the 2.5 syntax, but it was defined within a class, it became a class variable. This is just an example.
  - dragonwriter 3y ago
    > When you move from one minor rev of python to the next, some language feature changes Even if there was a breaking change affecting your project every minor version, to have the cadence of backward-compatibility induced changes you siggest you’d have to be switching Python versions forward about four times as fast as they are released, which, if you started with the oldest in support version at the beginning of the project, you could only sustain for about a year and a half, before running out of versions to switch forward to. > If you used a feature like package variables in your code in 2.3, Then you are probably out yelling at kids to get off your lawn; 2.3 being out of support for 12 years.
    - retrocryptid 3y ago
      I bring up 2.3 to 2.5 to 2.7 as an example, not as a recommendation.
coldtea 3y ago
In what planet? This has absolutely no bearing to the Python experience. And I'm using the stuff for 20 years.
- retrocryptid 3y ago
  That's great that your 5 line scripts don't use features that change between revs, but people who have to maintain large python apps have to book time to pore over the latest language version's definition, update our linting tools to find where in the codebase we use a deprecated feature, change the code, update the tests, retest and redeploy. Not to mention getting a version clean dependency closure. Though we have forked and rewritten some of the non-standard modules we're dependent on to be less broken and to give credit where due, it does seem like standard modules supporting python3 are version clean unlike python2 and 1.6. The heuristic we use is about an hour of dev time per 750 lines of code so our 70,000 line legacy python app takes somewhere around 100 dev hours per minor revision upgrade. Compare this to a legacy C application written in 1989. How do we port it to the latest version of C? We just copy it and compile. That community went to a lot of trouble to ensure code written in previous versions of the language still worked. The last time I heard of a language feature being deprecated was in 2011 (though I think gcc recently undefeated support for trigraphs.) In my opinion, your python baby is ugly. It was ugly in 1.6. It was ugly in 2.x. And it remains ugly in the 3.x era. You should come to terms with the fact that some people just don't like python.
  - acdha 3y ago
    > You should come to terms with the fact that some people just don't like python. Nobody cares about that - it’s a given that any language will have fans and detractors and most of us are mature enough to focus on what works for the projects and teams we’re part of. What we’re objecting to is portraying your experience as a global truth. If you don’t like it, sure, but unverifiable hyperbole isn’t contributing anything but noise. This could be your opportunity to learn what tools or practices people use or consider whether the way you want to use the language is at odds with the core developers’ view.
acdha 3y ago
Flagged for being silly flamebait. The Python projects you have personal experience with might have been poorly run but that’s not representative of the language, and it’s not going to lead to a conversation where anyone learns something.
- retrocryptid 3y ago
  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.