4 ms·
Including Python 3.6, even as a non-default Python, would have required to rebuild all Python packages and handle the non-working ones (either fix the problem o
by vbernat 9y ago
Including Python 3.6, even as a non-default Python, would have required to rebuild all Python packages and handle the non-working ones (either fix the problem or explicitely exclude Python 3.6 support for this package). There was not enough time to do all that.
- voltagex_ 9y agoAny bugs I should look at in particular? Does this mean we're stuck with Python 3.5 for the lifetime of Debian 9?
- warbiscuit 9y agoWould love to know this myself. I'm in process of moving my company's main web app to python 3, and standardized on 3.5 to match Debian 9. But python 3.6 has so many cpu & memory improvements (not to mention things like f'' strings), seriously considering installing custom copy of 3.6... though not sure if I want the burden of maintaining my own copy of everything that will affect. Then again... "Debian stable" being rock solid stable is why I stick with it for production; if their caution in this is the price I pay, it's worth it.
- voltagex_ 9y agoI'm not sure how tricky it'd be to maintain your own repo just for Python 3.6. It may be worth it.
- louiz 9y ago> Does this mean we're stuck with Python 3.5 for the lifetime of Debian 9 As always, with debian, you’re stuck with older softwares for the lifetime of their latest release. For example, I can’t use any C++17 feature for the next 2-3 years in my projects, just because I want to support debian…
- vbernat 9y agoBasically, yes. While for a lot of software, you can use backports to get a more recent version, this doesn't apply to software being part of the toolchain (gcc, python, ...) because it would affect the rest of the archive. o You are left with third-party repositories until we come with another solution, like Ubuntu PPA.