10 ms·
Just rip the band-aid off. Some of the async stuff in Python 3 is awesome. A bit curious that 3.4 has been dropped, as that's the stock Python 3 shipped for Ce
by lykr0n 8y ago
Just rip the band-aid off. Some of the async stuff in Python 3 is awesome.
A bit curious that 3.4 has been dropped, as that's the stock Python 3 shipped for CentOS 7.
- gammateam 8y agoDebian also does not have anything above python 3.4 on the stable packages branch 3.6 has been dev and test since 2016
- lykr0n 8y agoIt's not very clear, but this release is last release supporting 2.7 & 3.4. 1.5.6 supports 3.4.
- Thorrez 8y agoI don't understand your comment. Version 1.5.6 of what? The NumPy 1.16.0 notes say > Support for Python 3.4 been dropped, the supported Python versions are 2.7 and 3.5-3.7. That definitely sounds like NumPy 1.16.0 doesn't support python 3.4.
- mehrdadn 8y agoWhy in the world is Debian like this? Their buggy latexmk is also from 2015. Somehow I feel like every system that I want to keep updated stays on an old version, and every system that I want to keep pinned to some version just force-feeds me its updates...
- geofft 8y agoBecause it's the stable branch, and it gets no major version updates for anything after release, nor any new packages, just bugfixes to the current version. There is backports, and I've thought about maintaining a newer Python interpreter in backports (when I was working for a company using Jessie and trying to use a Debian stack for everything and sort of wanting async syntax). You could introduce python3.6 or python3.7 as a new package in backports. But it would be extremely hard to update the Python modules in Debian to the newer version, too, because there's just a "python3-foo" package for each module, so you'd either have to recompile all binary modules and patch them to work on the newer Python as necessary (and patch anything using async or await as regular identifiers....), or you'd have to introduce an interpreter that intentionally wasn't compatible with modules installed as Debian packages. (Or you could introduce an interpreter that tried its best and failed randomly, which seems worse than either option.) I'm personally sympathetic to wanting to get /usr/bin/python3.6 from my OS even if the only useful thing to do is put a virtualenv on top, but I think it makes sense to just install Python yourself into /usr/local at that point. Re latexmk, it looks like the volunteer maintainer hasn't updated it since 2015, and there's a culture of not stepping on people's toes and waiting a while before assuming they're inactive or no longer care. But it's been updated in the development release. The current changelog https://metadata.ftp-master.debian.org/changelogs/main/l/latexmk/latexmk_4.61-0.1_changelog https://metadata.ftp-master.debian.org/changelogs/main/l/lat... has a bunch of "NMU" entries, non-maintainer uploads.
- mehrdadn 8y agoThanks for the explanation. Re latexmk: so am I getting the development release on Arch? I get the 2018 version with texlive-core.
- geofft 8y agoSorry, I mean that the volunteer maintainer of the latexmk package in Debian hasn't updated it since 2015. Arch probably has a newer version from the latexmk authors (and I think Arch does not have the same culture of individual package maintainers, in general).
- mehrdadn 8y ago..Oh. Wow. Do distros not care if their packages are updated for 3+ years? I'd have expected half their entire job is to make sure package maintainers are actually maintaining packages...
- dima55 8y agoI don't know who these "distros" people are. Humans care. But no humans cared-enough to update this earlier. If you want to contribute to the Debian project specifically, talk to me.
- int_19h 8y agoEventually such packages get removed (usually when they stop building for whatever reason). But if the package still works, having an old version of it is still better than not having anything.
- Svenstaro 8y agoJust to note: in Arch we almost only have individual package maintainers.
- explainplease 8y agoThe Debian LaTeX maintainer was essentially harassed out of the project by the Anti-Harassment Team.
- raxxorrax 8y agoDebian was never cutting edge. If you want that, you would either have to switch your branches or change the distribution. There are quite a number of other distributions based on Debian with more recent software. But I wouldn't want Debian to change their release behavior. And to be honest regarding different versions: Python has always been a special needs kid in this regard.
- mehrdadn 8y agoI feel like there should be a more reasonable middle ground between 3+-year-old software and cutting-edge?
- raxxorrax 8y agoTrue, there probably is, but Debian is pretty known to be conservative towards newer releases.
- mehrdadn 8y agoIs there any distribution besides Arch that isn't like this? Alpine is also pretty bad about this, and I haven't tried other distros in years.
- raxxorrax 8y agoNo idea. I use mainly Debian but I think Ubuntu has a more aggressive update policy and is based on Debian. Not sure about RH since I don't know a lot about their package managers. But CentOS and Fedora are probably also quite up to date.
- mehrdadn 8y agoOh Ubuntu is like Debian to me... in fact when I was taking about Debian this whole time I was actually talking about Ubuntu. Its latexmk is the one that's old.
- deleted 8y ago[deleted]
- gammateam 8y ago> Somehow I feel like every system that I want to keep updated stays on an old version, and every system that I want to keep pinned to some version just force-feeds me its updates... Spot on.
- geofft 8y agoDebian stable (Stretch aka Debian 9, released summer 2017, regular support through ~summer 2020) has Python 3.5. Debian oldstable (Jessie aka Debian 8, released summer 2015, regular support through summer 2018) had Python 3.4. If you're on oldstable it's time to think about upgrading.... The next stable release (Buster aka Debian 10) is just starting the freeze process now and expected to come out this summer - Debian is in practice on a ~two-year release cycle, and regular support for each release lasts one year after the next stable release comes out. Buster will have Python 3.7 as default.
- gammateam 8y agowow 3.5 I already have apps that won't install unless 3.6 is there
- geofft 8y agoSure, and those apps didn't exist in late 2016/early 2017 when Debian stable was being finalized. It's called stable for a reason. If you want a faster-moving distro with correspondingly higher risk, there are multiple excellent choices, but in general you'll have to keep up with a much faster upgrade cycle. (My personal preferences would be Ubuntu non-LTS or even Debian testing, which goes through pretty good QA these days and is a fine choice for non-production-critical machines.) Alternatively, wait a few months and the next stable release will have you covered.
- deleted 8y ago[deleted]
- mrosett 8y agoThe code I've written recently relies heavily on async and data classes, both of which are recent additions. I can't imagine choosing Python 2 at this point.
- backprojection 8y agoSame here. Dataclasses and type annotations are fantastic, not to mention f-strings.
- drej 8y agoThis is all fine for personal/proprietary purposes, but open source can't be that cutting edge. While type annotations are probably fine (3.5), f-strings (3.6) or dataclasses (3.7) won't make it to mainstream OSS anytime soon. But they are great features nonetheless.
- uryga 8y ago> open source can't be that cutting edge. what?
- mroche 8y agoI mean, RHEL 8 is shipping with Python 3.6 and Python 2.7 available. There is no standard /usr/bin/python without making the symlink manually, and the system uses its own internal python for dependent tooling, so it doesn’t conflict with user installed versions. And, based on my experience, general open source is usually much more cutting edge than the larger distros, that’s the whole point.
- simonh 8y agoMy team is moving across from Bash to Python for non-trivial scripting. I hate it, but we're adopting Python 2.x. Our old servers are on SLES 11 which has Python 2.6 and even our new boxes have RHEL 7 which has Python 2.7 only by default. Getting the base system packages updated across all our systems and environments would be monumentally painful, so we're really stuck. It's not that Python 2.x is painful to use or anything, it's still a great language but being stuck using it seems pointless. I'm really upset at the distro vendors, they should have upgraded their base system Python scripts to 3.x years ago and just included 2.7 for legacy support. RHEL 7.0 came out in 2014 for goodness sake.
- blattimwind 8y ago3.4 will reach EOL very soon.
- xtreak29 8y ago> The expectation is that Python 3.4.10 will be released in March of 2019, and this will be the final release of Python 3.4. https://www.python.org/dev/peps/pep-0429/#release-schedule https://www.python.org/dev/peps/pep-0429/#release-schedule
- emddudley 8y ago> the stock Python 3 shipped for CentOS 7. What package are you referring to? As I understand it there is no "stock" Python 3 in CentOS 7. There is just what you can get from secondary repos, like EPEL, SCL, and IUS. Those repos now have 3.6 available.
- throwaway2048 8y agoHowever system level stuff will install 3.4 by default.
- mroche 8y agoWhich system level stuff? It’s an EPEL package, only EPEL or non-RHEL repo packages will call it in. Nothing from the base/updates/extras repos will pull python34 in to my knowledge, or any package non-base/updates/extras packages for that matter. I need to reach out to the cmake3 maintainer because they just added it as a dependency and I have no idea why.
- petre 8y agoSphynx for the docs? Homebrew add that as well to stuff which requires cmake to build.
- emddudley 8y agoOn a fresh virtual machine built from the 7.6.1810 minimal ISO the system Python is 2.7.5: [root@localhost ~]# python --version Python 2.7.5 RHEL 8 is where they are making Python 3 available as the system Python. https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/ https://developers.redhat.com/blog/2018/11/14/python-in-rhel...
- kalefranz 8y agoI generally try to leave the system python alone. Use pyenv or conda to get the python interpreters for your own code and apps.
- wenc 8y agoThis. I don't use anything but Anaconda these days. I leave the system Python alone.
- jklepatch 8y agoHow does this compare with managing python with brew?
- kstrauser 8y agoI love pyenv. Brew is excellent for establishing a decent baseline, but pyenv is good for "we've tested this service to run under 3.5.7 and this one to run under 3.6.2, so I want to develop locally with those exact versions without them being upgraded from beneath me". And when upgrade, running "pyenv local 3.6.3" is almost all that's required to start working with the new one.
- beagle3 8y agoIf you need the new numpy, get a new python. Conda makes that painless, but whichever way you get numpy, python itself is easier to build/install.
- nurettin 8y agoasync stuff is a bit suspicious to me. I use an async web server to command an async websocket client and sometimes you get hard to debug problems like throwing an exception in one library causing the other to stop working. That's never happened to me in node.
- coldtea 8y ago>Just rip the band-aid off. Some of the async stuff in Python 3 is awesome. Will that awesome async stuff help us migrate several 100s of thousands of lines of 2.7 code?
- pjmlp 8y agoI guess 10 years was more than enough time, maybe 2.x series will be the Cobol of Python world.
- coldtea 8y ago10 years where the first P3K versions were unusable and the rest still didn't have tons of dependencies? Yeah, right. There's a reason even companies with tons of resources like Google still use 2.7.
- sametmax 8y ago12 years. It's all been very usable for 6 years. So you had 6 years to use the six or python-future lib, and 6 years to remove it. 100k lines, it's a 2 weeks job if your code is properly tested. It's quite ok given python is 25 years old and asked for it once. But good news, you don't have to do it. Python 2.7 will still work after 2020. We, the community, will just stop working on it for free. You can start paying us, or do the job for free like we did since 1991. You can also migrate to another tech, but they will break things as well, and they won't give you 12 years to move. Ruby and node gave 2 years. Node forked 2 times. And it's a google based tech. I'm tired of hearing complains, given how good you have it.
- sweettea 8y agoI'm a big fan of Tauthon, a backwards-compatible Python 2.7 fork with some features backported from Python 3. Personally I've yet to see a Python 3 feature that would be useful in my code.
- 8y ago