When a program clearly deviates from its spec, would you be okay with calling that a "bug"?
There's always a gray area of what's intended by the spec, but a program can absolutely and blatantly deviate from the letter of the spec, and they often do.
This distinction seems worthwhile to me, because it means that something someone already relies on does not work (anymore), even though reasonable people would agree that, according to the spec, it should.
Absolutely would. But if we can categorize 1/3 of defects as ”bugs” 1/3 as ”missing or incomplete functionality” then there is 1/3 in the middle which we can’t decide. So the dichotomy is kind of weird, and making ”rules” and processes about this categorization is probably not worthwhile.
At least not worthwile for the purpose you have in mind. Okay, now I understand better what you mean, something like: for some purposes, there's not much to be gained by distinguishing between "bug" and "feature", one major reason being that there is no clear boundary between the two.
I first read your original comment in a much more absolute way (there is no distinction at all, and it never makes any sense anyway), which is quite easy to disagree with.
> hoping to push the changes to the project. I guess I am maintaining that myself now.
Not just the changes, you'd push the responsibility, too, for supporting a whole new compilation target. I don't know how big this is, but if it's a big enough hassle to keep maintaining this yourself, then consider that this maintenance work is really what you were hoping to push. So, depeding on which, you might be fine maintaining this, or the maintainers might have rejected the change, anyway.
Your argument can be used to discredit all arguments, including itself. Because your argument is made only of the same letters as all others (let's stay in English, without losing generality), it is the same as all others, and thus it has no discernible point.
Note that it's you who introduced this reduction, not the GP.
> I had the misfortune of having to use Python with a virtual env on the weekend - it did not end well, and reminded me why I migrated away from Python.
I see this sentiment a lot, and it doesn't match my experience at all.
In my decade-old bubble of using Python professionally, I've never had an issue with virtualenvs. The few issues I might've had with dependency resolution must be so far in the past that I don't remember. But that's not strictly about virtualenvs. Likewise, pip could be clunky, but we don't have to deal with it anymore.
My niche is mostly backend. Other Python niches must be considerably worse in this regard.
I used Python for a decade (professionally), gave up on it once I started using Go (professionally) in earnest - about 8 or 9 years ago.
I never liked virtual envs, having to remember where they were, what their names were, and what was installed into each one was a pain point for me.
This weekend I was trying to learn some AWS stuffs, and I cloned the official repo of example code which was Python. I followed the directions exactly and ... boom Python versioning issues... inside the freaking venv
Who needs that?
Why do I need to spend the better part of a couple of hours debugging a versioning problem? (FTR The problem turned out to be the repo was hardcoded to 3.8 and my local Python was 3.9.. or something along those lines - you are welcome to correct me, but that's what I remember of a painful waste of my time)
With Go I have backward compatibility guarantees - usually (there have been instances in the past where the backward guarantee have been broken AND the build process got broken hard for modules, with the claim that it was external and therefore not subject to the same guarantees)
> I see this sentiment a lot, and it doesn't match my experience at all.
My old HCI professor used to tell me - if users are complaining (or producing workarounds like post-it notes on their monitors) - regardless of how clean or elegant you think the system is - it's not.
You're saying you see people complain about it a lot - therefore it's a genuine problem.
> having to remember where they were, what their names were, and what was installed into each one was a pain point for me.
It's at the project root, it's named 'venv', and its contents are described by requirements.txt.
> You're saying you see people complain about it a lot - therefore it's a genuine problem.
Debatable as a principle, but applicable enough here I suppose. Still, I'm not saying the problems aren't real, but what I (and probably most of us virtualenv users) are saying is that there's a pretty broad swathe of projects where you don't encounter them. It's just fine. You install your packages and use your packages and that's the whole story.
I guess if you have a hard dependency on a particular version of python, it's going to be harder, but... why? That's already niche in my book. If you're saying the AWS repo was pinned to a particular version of python, I'm going to blame that on Amazon frankly. That's definitely bizarre.
Edit: Were you looking at this? https://github.com/boto/boto3 Definitely more complicated than a typical greenfield virtualenv-able project, with some python version restrictions.
> what I (and probably most of us virtualenv users) are saying is that there's a pretty broad swathe of projects where you don't encounter them.
Zero. The required number of problems needs to be zero - hence my OP
> I guess if you have a hard dependency on a particular version of python, it's going to be harder, but... why?
The bigger question is - why doesn't 3.9 compile and run 3.8
Further, in what world is targeting a specific runtime version in an enterprise production environment "niche"?
When you are deploying to managed corporate infrastructure, AWS Lambda runtimes, or strict Docker base images, you don't just get to loosely target "whatever Python version happens to be on the developer's laptop." You target an exact runtime version (e.g., Python 3.10) because language syntax, standard library features, and performance characteristics change between minor releases.
The fact that Python forces the developer to manually manage isolated directory symlinks (venvs) just to prevent local environment contamination — and that minor runtime mismatches can completely derail a standard onboarding experience — is a structural UX failure.
> Zero. The required number of problems needs to be zero - hence my OP
This is unrealistic. You seem to have moved to Go as an alternative, but I know because I've seen the complaints that Go doesn't satisfy that standard either.
I was trying to be sympathetic and acknowledge virtualenv's potential flaws, actually, even though I haven't personally encountered them, but I guess that was a waste of time.
> This is unrealistic. You seem to have moved to Go as an alternative, but I know because I've seen the complaints that Go doesn't satisfy that standard either.
It's a dig - you completely ignore the valid complaints about Python to instead focus on what you think will provoke me.
The problem (for you) was, from the very start, I bought up the pain points with Go.
> Still, I'm not saying the problems aren't real, ...
> I'm going to blame that on Amazon frankly. That's definitely bizarre.
I'll grant I lost track of the context that you were trying to raise the possibility of some grand encompassing solution to all programming language package management. All I wanted was to reinforce the idea that virtualenv is Often Just Fine in practice, at least if used in sensible ways.
> There's two types of lazy, and this is the kind that creates more work, not less
Well put. Thanks for taking the time to call this out. Your two comments here are balm for the mental anguish and annoyance I went through reading the so-full-of-misplaced-confidence original comment.
From what little you're saying, you guys might be more productive now and writing better code, finally decently documented, or you just hopped onboard a speeding slop train, or something to be defined in between. Hard to tell which.
> How much of the market valuation is actually created wealth?
Technically, all of it. Determining the socially-useful component of either production or wealth, on the other hand, is a tough and subjective exercise. (Wwrong answers are all and zero.)
A useful proxy is taxable wealth. So far, NVIDIA, OpenAI and Anthropic share sales have generated tens if not hundreds of billions of dollars of taxable proceeds for the United States. Those are figures that would pay for a lot of Germany's pension problems [1].
There's always a gray area of what's intended by the spec, but a program can absolutely and blatantly deviate from the letter of the spec, and they often do.
This distinction seems worthwhile to me, because it means that something someone already relies on does not work (anymore), even though reasonable people would agree that, according to the spec, it should.
reply