Not really a concern, just an observation, but yes that's what I was suggesting.

I'm all for tomorrow; I'd just prefer that it be better, or at least as good, as yesterday.


JES2 forever baby! You can keep your silly JES3.

Looks like we need to clarify some things in this thread:
So far that's true, but it won't last much longer. From PEP 373:
---
From blog post by Nick Coghlan, one of CPython core developers:
I also want to add that while CPython is indeed written in C (not C++), the move to Python 3 wasn't related to C or C++ "major revision" in any way. The intention was to clean up Python language, which required some backwards incompatible changes.

And currently there's no simple way for Slackware to switch from Python 2 to 3 completely, because there are still projects that haven't transitioned to Python 3 yet, e.g. Mercurial (although they're working on it).

1 members found this post helpful.

Then clearly it should be called 3.10. Just saying....

Nice to see the python guys continuing to make a right pig's breakfast out of the versioning. But, if they do indeed go down this route, my suggestion of leaving the executable as 'python3' clearly doesn't make sense going forward.

You should say that to OpenBSD developers as well.

CPython doesn't follow semantic versioning -- I guess that's how developers prefer it.

perl 6 anyone ?.

... sorry, couldn't resist.
It's bad enough we get a new language every other week, but incompatible versions are just a burr under everyones saddle.

And Linus, and a whole heap of other projects, sadly.

From what I'd read I thought the Perl guys has already stated that Perl6 is not intended as a new version of Perl5 but a completely new language and should be treated as such. They seem to have their heads on a little better than the python camp in that regard.

The Tcl devs must be having a good laugh among themselves, seeing how the headlong rush to "Something Better than Tcl" turned out.

If it ever gets to be just Mercurial holding things up, then I'd recommend moving it and its dependencies to /extra.

Mercurial isn't exactly a core component.

With all respect, my expectation is based on the behavior of the inventor and lead developer of Python, Guido von Rossum, who has never done what this guy is suggesting. Guido runs the git at Python.org, I think Nick is expressing a pure development perspective, driven more by a strong belief in CI/CD conceptualizations than real world requirements. This is a programming language, the structure of its naming convention is key for implementation purposes. Consider this, if Guido followed Nicks advice and at some point did have to break backwards compatibility again to keep the language competitive with node, ruby, groovy, go (etc. etc. etc.) how would they do that?

Observe: This is why Slackware even has a default version of python.
Fortunately, that unruly child has two better behaved little brothers...
We could very easily become a python agnostic distro and we even have a significant advantage over other Linux implementations because... we don't even have python3 in the core package set. That means at the distro level every one of these
#!/usr/bin/python || #!/usr/bin/env python
References python2 which means if you append a "2", you'll use the better behaved python2 -> python2.7 pointer in /usr/bin.
We don't have to look at the code, if it's anything other than python2, it hasn't been running on these nodes.

Then, the new stuff (When we get around to adding it... looking at you BDFL) and the old stuff would run side by side and we'd be ready for whatever tomorrow brings. It seems like a very "Slackware" type solution to the problem, nobody would be "forced" to do anything and the argument about "default" python disappears cause we aint go no damn default python, we just run the python you ask for.

Detail
Python3 developers specify the python version in their code, either with a "require" or that shell line (#!/usr/bin/python3). Python2 code assumes python2 as the default, they don't normally instantiate with #!/usr/bin/python2. and only use "require" when their code has backward compatibility issues.
Getting the pointer in the bash hack fixed is trivial, the only issue I wondering about is how do we identify the "requires" references in the OO code and do we even need to? (i.e Does the framework find it's libraries at install or does it reference that evil pointer). I need to construct a bulletproof test to confirm it doesn't before I can go to the next step
I'm working on verifying that now, btw so any suggestions would be most welcome.

1 members found this post helpful.

Type annotations and async IO are the recent developments keeping it competitive with Node (with Typescript) and Go. Not sure why Groovy and Ruby (excuse me, Ruby?) are on the list?

They're common automation dev/ops languages. Groovy is what happens when you don't put a leash on your Jenkins devs and Ruby is native in Chef and Puppet.
Don't be a hater, I'll code in it if you put a pistol to my head, I just prefer python
Also Ruby is in the distro, unlike python3 ...

gradle currently uses groovy as its implementation language. (Moving towards kotlin, however.)

Grails also uses groovy, but nobody in their right mind should care about that.

At install.

@Dugan Mmmm ... that was my thought too, and the frameworks can certainly find their libs but checks from OO code are commonly made with a 'requires' directive or the old school equivalent sys.get_version, both of which reference the pointer /usr/bin/python so, no mercy there. Sorry I wasn't clearer in my initial question, you are exactly right, but it does us no good... .

Effectively, we'd end up doing what arch did so we'd end up with what arch got (a default version of python rather than context driven matching aka pygnosticism). When you consider the impact that would have on the Slackware user base I imagine the fires are gonna have to burn pretty high before the BDFL considers flipping the pointer to python3.

I've been working on the idea of replacing the softlink (/usr/bin/python) with a tdb object so effectively registering the calling process to a python context and returning the inode reference for /usr/bin/python2 or /usr/bin/python3 based on that context. It's got lot's of delightful possibilities, including keeping user-space consistent with current expectations while allowing P2 and P3 code to find their respective frameworks.
Registering the context wouldn't give anybody heartburn, initial prog_start -> if it works associate context -> if it fails auto-restart in second context -> if it works associate context -> if it fails... Somethings wrong with your python dude, we only got two and we tried 'em both.

Tdb is about the worst documented module I've ever seen ( I say that way too often for it to actually be true though...) so progress is not shockingly good. Anybody know of a good reference or tutorial (I aint proud). I'd use redis but it's ex-distro. Also, it runs a server which would cause some angst among the users, demons are not popular among the Slackware faithful. The tdb object would register on a ps but I'll call it dbus-caught-you-looking and it will likely slide by unnoticed.

@ Richard Well apparently they got bored on the multi-threaded maven infrastructure. You can pick them out of the crowd by their intense desire to slather Jenkins on everything (Apparently Jenkins has no ssh functionality which makes it an odd choice for managing virtual environments) also... Isn't that why we chased Chef off these nodes? Jenkins comes with the added bonus of distributing the build process across every node with an agent, you can imagine the impact that has on scaling algorithms...
Still, some are clever and quick to learn, most don't think it's worth the time. The smart ones will hang around and contribute, the dumb ones will get MBAs and become our bosses... It's the circle of life...