I'm just curious if there is any chance it's going to be implemented in 14.3 or so. I guess I can always do python3, but that's annoying. I would be content to just delete python 2 from Slackware altogether, but a few odd things depend on it.

Arch has gone through great lengths to make python3 default. The result is now you can not run arch without python2 and python3, look at the required by list for their python2 pkgbuild.

https://www.archlinux.org/packages/extra/i686/python2/

Python 2 has 4 years before it's EOL. So I suspect that it will be default for at least a couple more Slackware versions.

Doesn't Xorg need Python-2?

Yes and so does Mesa last I remember.

To be fair, I'm pretty sure hedron just meant the /usr/bin/python executable being Python 3.

Not necessarily Python 2 being removed from Slackware.

1 members found this post helpful.

If Arch couldn't re-write enough code to chase python2 off the nodes, I don't know of anybody who's going to be able to do it.
You've got "six" for compatibility between 2.5 and 3.0, so you could write it in 3, deploy it in a virtual 2.7 environment and require the six module. That's basically how ansible handles the problem of portability vs the unforgivable sin of writing in the only programming language, besides c and perl, you can guarantee is on the node.

It reads differently to me...

Arch didn't rewrite anything. They just made decisions about what to package.

Same as what Fedora's doing.

What you package isn't the problem, I have 2.7 and 3.4 side by side, It's the "python pointer" in /usr/bin that determines the default python version for most scripts
I'm not sure how arch finally got it resolved, probably ran a sed through their software stack replacing "#!/usr/bin/python" && "#!/usr/bin/env python" with " /usr/bin/python2"
This works, for example
Then you could turn the pointer without downing the node. (it's not just 2 subsystem that rely on it, run a recursive strings from the root dir and grep the output for those two references, you'll realize it's almost everywhere.)
But it's not much use to us, mountains of python2 script is still being produced, and if arch and fedora are the only distros who'll turn the thing, there always will be mountains of commercial script referencing the python pointer as python2 since you'd have every expectation that's how it's set up on a commercial node.

Most python programmers working in automation don't care what version of python is on the node, as long as the "virtualenv" module is in site-packages or we can pip it down. With that, you can write in whatever python version you prefer (assuming it's in an accessible pip repo), just remember to erase the virtualenv when you're done.
Perhaps that's part of why the python community isn't really that wound up about it and therefor why the migration to python3 as the standard has been so gradual.

1 members found this post helpful.

That is indeed done during packaging, by the standard build system used by Python's packages:

That sets the script shebangs.

I wouldn't be averse if our BDFL & Team chose that route, I think the python3 guys did an outstanding job and I feel a little sorry for them that their work isn't being fully leveraged. Our Slackbuild scripts could be modified to accommodate the issues surrounding package installation, I notice Arch has a bash hack to handle the problem. Unsurprisingly, we're well positioned to handle something like that since we use build scripts instead of a more comprehensive solution (which would no doubt bite us in the hind parts if we tried this).

Of course, we'd all have to swear a solemn oath to answer 100 desktop support questions on this board every week until the fires burned out, but I'm game.

Arch, Fedora, Slackware ... we could be in worse company. They might even stop calling us luddites...

EDIT: We'd have to make "/usr/bin/python2" a pointer to the default installed python2 version (2.7) or you couldn't safely run python2.7 and python2.11 in /usr/bin. (which is sometimes...needful)

I'm of the opinion that installing python3 as /usr/bin/python is a mistake. If/when they ever get around to another incompatible python version such as python4, or 5 or 6, we'll just end up in the same ambiguous situation. IMO, when python2 is retired, /usr/bin/python should go with it, and python3 should remain /usr/bin/python3 in perpetuity. That way everyone knows exactly what they're getting when they invoke it.

4 members found this post helpful.

I'd be fine with this.

I haven't had any trouble with it GAZL, however I haven't converted a Slackware node to run on python3 as a default, though it's getting mighty tempting....

EDIT: Sorry, misunderstood your intent here.
What if we didn't have a default python version? We modified the build scripts and packages to explicitly point to the appropriate python framework? Would that address your concerns?

Python 2 has been around a decade and nobodies found a way to kill it. I'd suspect python3 will have the same lifespan since python rides directly on C++ libraries, so you don't normally see a major revision in python unless you see a major revision in C.
I don't think the main distro would have an issue handling it, I think the repos (slackbuilds/alienBobs/rworkman/et al) would have to sign on to the effort.

In my experience the world splits cleanly into two groups. Those that don't know they're using python and those that have to code the python. The latter cares, the former doesn't. If you don't fit into that mold then that's certainly a reason NOT to make it required. It's Slackware, so it's all about choices.
We could maintain two parallel build systems but it's going to make maintenance more problematic. Maybe some of these young zealots could volunteer their skills and time to assist in the process, help build the community instead of sitting on the outside wondering why we don't listen to them (because seriously, they have a valid point, tomorrows coming, you can be prepared for it or a victim of it, there is no third option I'm aware of other than death and honestly, I think I'd rather get ready for it than hope for that).

Once upon a time, when big iron ruled the digital world, I can distinctly remember thinking... what's wrong with these ancient turds? Don't they realize technology is rocketing forward? Look at the improvements we've made in the mainframe job queue!!! I don't think I'm ready to be an ancient turd (though the calendar tells me otherwise)

1 members found this post helpful.