I'd be much more reluctant to get on OP’s case about it than GP, but there’s a strong argument to be made that this hurts the overall python ecosystem.
There's also a strong argument to be made that people shouldn't have to care about ecosystems that are so delicate that a proof of concept in a previous version "hurts the overall [ecosystem]."
"How dare you use a hammer! We're all using Hammer 2 now! I don't care that it was 'Only one nail," put it down and pick up Hammer 2! Your hammer is what, ten years old? That's ancient! It's not even compatible with my Hammer 2! What do you mean, 'They hit the same fucking nails!' That's not the point! I can't track how many nails you're hitting per-minute now, or even take advantage of the nails you've hit! It's barbaric!"
To make the analogy work I have to imagine that the two hammers cause horrible problems when used at the same time, and that they're both free with 5 minute shipping.
It's a sucky situation to be in, but we should probably get everyone on the same hammer.
(If we want a somewhat less nonsensical analogy, replace hammer with screwdriver. Two incompatible screw head patterns and you can only use one driver on any particular object.)
So sure don't nitpick a toy project, but if someone's writing significant code in python 2... it's not ideal.
-
But all of this is a dumb tangent, and we should just appreciate how funny it is to ask that this nonsensical pointless quasi-OS-breaking code be done in python 3 instead.
> But all of this is a dumb tangent, and we should just appreciate how funny it is to ask that this nonsensical pointless quasi-OS-breaking code be done in python 3 instead.
I'll admit that I did not expect it to start a thread.
No "horrible problems" arise from Python 2 being used on the same system that Python 3 is on. The only problems are trivial, which was highlighted in the analogy.
I wrote this reply earlier and deleted it. Part of me feels like it's too far afield, but it's also kind of not, so I'll include it. It's what's on the top of my mind right now:
---
I'm a volunteer teacher at a Girls Who Code club. We use Python. I spent the last class before the universe collapsed into Cornoavirus hell introducing the kids to the concept of functions.
After introducing the concept, I asked the kids to modify a quiz program they'd written with a different teacher to use functions to ask a question and check the answer, instead of copying and pasting the code each time. This was a pretty challenging assignment—these kids hadn't encountered functions before—but one of the girls managed to get it and I was really proud of her.
Except her code wouldn't run because—I realized with horror—the quiz program she'd written with another teacher was actually python 2 code!
I am still, weeks later, so damn frustrated that this happened. I'm trying to get the kids to wrap their heads around functions; I don't want to start explaining the political BS around python 2 and 3.
It's primarily my fault, of course, and secondarily the python foundation's fault for handling this transition so badly. But every new project that's done in python 2—whether serious or a toy—is also contributing to the issue in a very small way.
So while this isn't a conversation I would have personally brought up in this thread, I think it's all just very unfortunate. Python is a nice language and it doesn't deserve this crap.
I saw this reply earlier! It was gone by the time I tried writing a response, but I don't feel like it's too far afield at all: it's a really nice response. (And thanks for doing that! It's always nice to see people volunteering for genuinely helpful things like this.)
It doesn't seem like it was your fault, and it's understandable that you're frustrated.
I don't, however, agree that anything written in Python 2 is contributing to that problem. Just because code exists doesn't mean it has to be used by other people, and this is a proof-of-concept obviously outside of the range of the class you were teaching.
It's the Python Foundation's fault, and it doesn't seem like anyone else's. Python 2 is nicer to write from some perspectives, and, for example, the idea of somebody who didn't like Perl 6's changes being told to write Perl 6 instead of Perl 5 or else they were being harmful doesn't really make sense either.
> Python 2 is nicer to write from some perspectives, and, for example, the idea of somebody who didn't like Perl 6's changes being told to write Perl 6 instead of Perl 5 or else they were being harmful doesn't really make sense either.
Except Perl 6 (Raku) is now marketed as an entirely separate language, whereas Python 3 is the version of Python that has superseded Python 2.
Yes, this file, completely in isolation, has no problem.
But people want to different pieces of python code together. If one or the other only works with a specific version, it becomes a problem when you try to combine them.
Therefore, best practice is to get everyone on the same version. We want to stop having to ask which version everything is, and facing the disappointment when things can't go in the same program. We want to get back to the situation where it's just 'hammer', and that's good enough for 95% of people.
...use the hammer that didn't arbitrarily break compatibility, then? (Note that the original analogy pointed out that they couldn't be mixed, anyway: "or even take advantage of the nails you've hit!")
This is like complaining that the well is poisoned when you're the one who put arsenic in it.
This also isn't even an open source project, so it's not like you can mix and match anyway.
No, but you're complaining about a person using Python 2, the one that didn't arbitrarily break compatibility, while promoting the use of Python 3 because not being compatible is bad.
Again focusing on the execution of one specific project, as-is, is beside the point of "get everyone on the same hammer".
