3 ms·

It sounds like you do use Python, but when you do, you face this problem... That's fine, but I wanted to clarify - you intend to not use Python, because you ha

It sounds like you do use Python, but when you do, you face this problem... That's fine, but I wanted to clarify - you intend to not use Python, because you have tried and it's not gone well. Python didn't come out of the woodwork and attack you, so much as you stepped into a (momentarily) troubled ecosystem. I understand they were dependencies of other projects. By using those, they became your dependencies. Take some ownership of your problems, even if the ecosystem provides them -- they are chosen, and can be managed. Distributions do a decent job distributing modules... Utilities have an annoying tendency to rely on SomeStableModule==SpecificVersionForNoReason. This compounds the mess, sadly. Those should be routinely addressed as part of your auditing, along with the whole of the supply chain I can't really prescribe much... this is just generic advice. I understand the woes, it's just not as unique as this is painted

bloblaw 4y ago
> Take some ownership of your problems, even if the ecosystem provides them -- they are chosen, and can be managed. Huh? This has a strong "No, it's the children who are wrong" vibe. But to be more fair to your point, I think this is a dismissal of the OP concern's. A troubled ecosystem should be concerning to the Python community as a whole because it threatens future adoption if not addressed. User's don't want a troubled ecosystem and will find languages that avoid these problems...and Go, Nim, and to smaller extent Zig, Rust, D are strong alternatives for the different workloads currently provided by Python tooling. Python has a good moat with both ML and mind-share of developers...but at one time Perl had a similar moat...
- bravetraveler 4y ago
  It's a fair criticism, I know it's a bit harsh! I appreciate it and both the more fair take. > User's don't want a troubled ecosystem and will find languages that avoid these problems It's true, I'm very late to Python myself -- for the exact same reason. The distribution part of the ecosystem is a nightmare. People want utilities, but they learn more than they ever cared to because of dependencies. I'm only learning how to manage it now because work demands it. Prior, all of my needs had fortunately been met by my Linux distribution of choice -- the Python part was abstracted away, for the most part. Developers of these utilities could save some (shared) effort by offering package specs/finding a maintainer, but I understand why it's not common. (I may even build/maintain it for you, to sweeten the pot) I guess the fuel of this thing is, 'misery loves company' -- I'm dealing with it, and I can't just whine about it. The "I don't use it and it still affects me part" was the bait -- they do use it
tolmasky 4y ago
> Take some ownership of your problems, even if the ecosystem provides them -- they are chosen, and can be managed. Not sure where you're going with this. I didn't whine to someone else to fix it. I did take ownership. Over and over. I fixed these problems, as unrelated to my main goal as they were. I then complained about it after the fact. Seems like a totally fair ordering of events to me. Separately, I will state that Python is an environment that seems to go out of its way to make it hard to meticulously manage dependencies if you want to. There's all sorts of competing environments and package managers. I'm sure it's straightforward if that's your main environment, but it doesn't help if you're coming form the outside. > Those should be routinely addressed as part of your auditing, along with the whole of the supply chain This assumes that the only available option is "manage this dependency better". That's not the only option. There is also "consider using something different that is easier to manage." Most of these utilities exist in a competitive market. And if there are utilities that allow me to choose the cadence and separately make that auditing simpler, then I will choose that. That is the point of my statement. I am not choosing to go on a hunger strike or avoiding some no-other-choice tool. Quite the contrary, a lot of these tools were chosen by other members of the team at some point, either because it's what they were familiar with or some other unimportant reason, and now they have, to their own detriment, made themselves the squeaky wheel, and opened up the range of possibilities to everything from "put in the work to maintain this tool that has currently demonstrated itself to be brittle" to "maybe I should use something else". Generally speaking, it's a bad thing to only draw attention to yourself when you are doing something bad. > can't really prescribe much... this is just generic advice. And yet this is a specific problem. > I understand the woes, it's just not as unique as this is painted It very much is unique. I'm literally not experiencing this with any other language that I don't directly use. Do I experience this with the libraries I directly use in my language? Of course. I signed up for that. I know the risks I take using beta builds and have a keen sense of the current internal transitions, etc. But I absolutely do not become aware of the latest argument in the C++ language spec, or a contentious Swift proposal, or end up becoming vaguely aware of the string implementation choices of a language I don't use. That is a unique Python thing. The fact of the matter is, Python has (recently? momentarily perhaps?) proven itself to require more maintenance than other tools I use. The community can decide who's at fault for this (language devs, library devs, end users, whatever), and even whether or not it matters, but if the message to the people outside the community is to deny that this is unique or troubling, then don't be surprised if the way they choose to take ownership is to count Python as a point against a project they are considering to use.

bloblaw 4y ago

> Take some ownership of your problems, even if the ecosystem provides them -- they are chosen, and can be managed. Huh? This has a strong "No, it's the children who are wrong" vibe. But to be more fair to your point, I think this is a dismissal of the OP concern's. A troubled ecosystem should be concerning to the Python community as a whole because it threatens future adoption if not addressed. User's don't want a troubled ecosystem and will find languages that avoid these problems...and Go, Nim, and to smaller extent Zig, Rust, D are strong alternatives for the different workloads currently provided by Python tooling. Python has a good moat with both ML and mind-share of developers...but at one time Perl had a similar moat...

bravetraveler 4y ago
It's a fair criticism, I know it's a bit harsh! I appreciate it and both the more fair take. > User's don't want a troubled ecosystem and will find languages that avoid these problems It's true, I'm very late to Python myself -- for the exact same reason. The distribution part of the ecosystem is a nightmare. People want utilities, but they learn more than they ever cared to because of dependencies. I'm only learning how to manage it now because work demands it. Prior, all of my needs had fortunately been met by my Linux distribution of choice -- the Python part was abstracted away, for the most part. Developers of these utilities could save some (shared) effort by offering package specs/finding a maintainer, but I understand why it's not common. (I may even build/maintain it for you, to sweeten the pot) I guess the fuel of this thing is, 'misery loves company' -- I'm dealing with it, and I can't just whine about it. The "I don't use it and it still affects me part" was the bait -- they do use it

tolmasky 4y ago

> Take some ownership of your problems, even if the ecosystem provides them -- they are chosen, and can be managed. Not sure where you're going with this. I didn't whine to someone else to fix it. I did take ownership. Over and over. I fixed these problems, as unrelated to my main goal as they were. I then complained about it after the fact. Seems like a totally fair ordering of events to me. Separately, I will state that Python is an environment that seems to go out of its way to make it hard to meticulously manage dependencies if you want to. There's all sorts of competing environments and package managers. I'm sure it's straightforward if that's your main environment, but it doesn't help if you're coming form the outside. > Those should be routinely addressed as part of your auditing, along with the whole of the supply chain This assumes that the only available option is "manage this dependency better". That's not the only option. There is also "consider using something different that is easier to manage." Most of these utilities exist in a competitive market. And if there are utilities that allow me to choose the cadence and separately make that auditing simpler, then I will choose that. That is the point of my statement. I am not choosing to go on a hunger strike or avoiding some no-other-choice tool. Quite the contrary, a lot of these tools were chosen by other members of the team at some point, either because it's what they were familiar with or some other unimportant reason, and now they have, to their own detriment, made themselves the squeaky wheel, and opened up the range of possibilities to everything from "put in the work to maintain this tool that has currently demonstrated itself to be brittle" to "maybe I should use something else". Generally speaking, it's a bad thing to only draw attention to yourself when you are doing something bad. > can't really prescribe much... this is just generic advice. And yet this is a specific problem. > I understand the woes, it's just not as unique as this is painted It very much is unique. I'm literally not experiencing this with any other language that I don't directly use. Do I experience this with the libraries I directly use in my language? Of course. I signed up for that. I know the risks I take using beta builds and have a keen sense of the current internal transitions, etc. But I absolutely do not become aware of the latest argument in the C++ language spec, or a contentious Swift proposal, or end up becoming vaguely aware of the string implementation choices of a language I don't use. That is a unique Python thing. The fact of the matter is, Python has (recently? momentarily perhaps?) proven itself to require more maintenance than other tools I use. The community can decide who's at fault for this (language devs, library devs, end users, whatever), and even whether or not it matters, but if the message to the people outside the community is to deny that this is unique or troubling, then don't be surprised if the way they choose to take ownership is to count Python as a point against a project they are considering to use.