5 ms·

> This is "I don't like python", but phrased adversarially. But it is an incredible pain in the ass in production environments. Environment drift is something

> This is "I don't like python", but phrased adversarially. But it is an incredible pain in the ass in production environments. Environment drift is something that _always_ seems to happen, no matter how diligent people are about using venvs or dependency managers or w/e. One of favorites was when we did a dependency upgrade (something that required a change to Click) we had an upgrade of Black forced on us in order to satisfy Poetry which then reformatted all of our Python code. Recently we had mypy stop checking one of our internal packages because of a Dockerfile refactoring. The package could still be found at runtime but the type information just wasn't found by mypy. We didn't notice it until we started getting errors at runtime, which made the fix a lot more difficult to diagnose. There's always someone saying "you're using it wrong" or "you're doing something worng", even if you follow the guides and howtos to get started. For a language which states "There should be one -- and preferably only one -- obvious way to do it" as part of its guiding principles, that there is no single one way to use it right in production -- let alone an obvious one -- that makes it, simply, a "pain in the ass".

fnord123 3y ago
>we had an upgrade of Black forced on us in order to satisfy Poetry which then reformatted all of our Python code. Unlikely. If you are using pre-commit to run black then the version being used lives outside your venv and hence not subject to dependencies you are using. Poetry should also be outside your venv.
- maximilianburke 3y ago
  It's not "unlikely"; it's something that happened. And, again, if something that was configured wrong this goes back to how managing Python is a pain in the ass. I should be able to dedicate my brain power to the problems I need to solve, not what things need to be in my venv and what things need to be outside of it.
  - fnord123 3y ago
    I agree that managing python development environments is a pain in the ass. I'm completely with you there. But I'm curious what the nature of a black upgrade being forced on you. Like a manager or stakeholder had an edict stating everyone must upgrade to 23.x?
- lsaferite 3y ago
  > There's always someone saying "you're using it wrong" I feel like your reply is demonstrating this comment perfectly. You could be perfectly correct, but their point still stands that _they_ had a horrible experience that shouldn't have been so difficult. If there's a _right_ way to do things then it should be blindingly obvious and these kinds of experiences would dry up.
  - alex_lav 3y ago
    A person had a bad experience. There's a decent chance that bad experience is more that person's fault than it is any technology's. But also: > If there's a _right_ way to do things then it should be blindingly obvious and these kinds of experiences would dry up. This has never happened for any technology ever. People misconfigure things all the time. Even hardened technologies get used incorrectly very frequently. It's just the reality of our industry. Which is why I say, all of this is just a proxy for "I didn't like my experience with Python", which is fine! But also in no way condemning of the technology.
alex_lav 3y ago
> But it is an incredible pain in the ass in production environments. "I find it hard to maintain Python in production environments", but worded adversarially. > One of favorites was when we did a dependency upgrade (something that required a change to Click) we had an upgrade of Black forced on us in order to satisfy Poetry which then reformatted all of our Python code. This is literally just a misconfigured set of tools then. > There's always someone saying "you're using it wrong" or "you're doing something worng", even if you follow the guides and howtos to get started. This is true of all languages and frameworks. There are people _in this comment section_ insisting those that have had negative Rust experiences must simply be doing it wrong. This is more a comment on our industry than any individual technology. > For a language which states "There should be one -- and preferably only one -- obvious way to do it" Yes, this has always been a bold faced lie from the Python community. Marketing speak is marketing speak. > that there is no single one way to use it right in production -- let alone an obvious one -- that makes it, simply, a "pain in the ass". It's as much a pain in the ass as literally every piece of technology, as the above statement is true for every technology and framework that exists. I acknowledge that you don't like it. That's great! But again, language flamewars suck, and suggesting that something is bad because you've individually had a bad experience is pretty silly. Lots of people successfully deploy and maintain python applications of various sizes without referring to the process as "a pain in the ass".

fnord123 3y ago

>we had an upgrade of Black forced on us in order to satisfy Poetry which then reformatted all of our Python code. Unlikely. If you are using pre-commit to run black then the version being used lives outside your venv and hence not subject to dependencies you are using. Poetry should also be outside your venv.

maximilianburke 3y ago
It's not "unlikely"; it's something that happened. And, again, if something that was configured wrong this goes back to how managing Python is a pain in the ass. I should be able to dedicate my brain power to the problems I need to solve, not what things need to be in my venv and what things need to be outside of it.
- fnord123 3y ago
  I agree that managing python development environments is a pain in the ass. I'm completely with you there. But I'm curious what the nature of a black upgrade being forced on you. Like a manager or stakeholder had an edict stating everyone must upgrade to 23.x?
lsaferite 3y ago
> There's always someone saying "you're using it wrong" I feel like your reply is demonstrating this comment perfectly. You could be perfectly correct, but their point still stands that _they_ had a horrible experience that shouldn't have been so difficult. If there's a _right_ way to do things then it should be blindingly obvious and these kinds of experiences would dry up.
- alex_lav 3y ago
  A person had a bad experience. There's a decent chance that bad experience is more that person's fault than it is any technology's. But also: > If there's a _right_ way to do things then it should be blindingly obvious and these kinds of experiences would dry up. This has never happened for any technology ever. People misconfigure things all the time. Even hardened technologies get used incorrectly very frequently. It's just the reality of our industry. Which is why I say, all of this is just a proxy for "I didn't like my experience with Python", which is fine! But also in no way condemning of the technology.

alex_lav 3y ago

> But it is an incredible pain in the ass in production environments. "I find it hard to maintain Python in production environments", but worded adversarially. > One of favorites was when we did a dependency upgrade (something that required a change to Click) we had an upgrade of Black forced on us in order to satisfy Poetry which then reformatted all of our Python code. This is literally just a misconfigured set of tools then. > There's always someone saying "you're using it wrong" or "you're doing something worng", even if you follow the guides and howtos to get started. This is true of all languages and frameworks. There are people _in this comment section_ insisting those that have had negative Rust experiences must simply be doing it wrong. This is more a comment on our industry than any individual technology. > For a language which states "There should be one -- and preferably only one -- obvious way to do it" Yes, this has always been a bold faced lie from the Python community. Marketing speak is marketing speak. > that there is no single one way to use it right in production -- let alone an obvious one -- that makes it, simply, a "pain in the ass". It's as much a pain in the ass as literally every piece of technology, as the above statement is true for every technology and framework that exists. I acknowledge that you don't like it. That's great! But again, language flamewars suck, and suggesting that something is bad because you've individually had a bad experience is pretty silly. Lots of people successfully deploy and maintain python applications of various sizes without referring to the process as "a pain in the ass".