On Tue, 2018-10-16 at 09:38 +0200, Ole Streicher wrote: > ghisv...@gmail.com writes: > > Indeed. Note that NumPy has already published plans to become > > Python 3 > > only in the near future, so the deprecation of Python 2 in the > > scientific stack will happen eventually. > > > > I just don't think it should be rushed into the Buster release > > cycle. > > If we really want to then have a Python-2-numpy, why can't there be a > separate Python-2 legacy numpy source package? I do the same for > astropy.
Who is "we"? I never said that personally. > Holding back normal updates especially for science packages just > because > we don't want to use a modern numpy/scipy/matplotlib stack is not > really > friendly to our users, which (in science) rely on at least "somehow" > modern software. And astropy that is more than a 1.5 years old > already > at the release of Buster would not be accepted by the users, and > patching it to use an older sw stack is also impractical. Afaik, matplotlib v2.x is under an LTS release scheme, so I don't think we are holding anything back. Same rationales for IPython, for which we maintain packages for the v5.x LTS releases instead of tracking v6.x. > > Even when we /still/ support Python 2, our focus and preference > should > be clearly Python 3. Don't get me wrong, I am all in favour for a modern stack, including Python 3. However, upgrading NumPy et al. to their Python 3 only versions, introducing new legacy packages for Python 2, and patching the large collection of packages relying on the Python 2 versions of these sounds like a lot of work for the time we have got left in the Buster release cycle. Let me ask you this: besides Steffen's ITP, is there anything urgently calling for an upgrade of the scientific stack to something newer than the LTS versions? Where urgently implies fixing RC bugs impeding the Buster release. Maybe there are. If not, where is the rush really? Ghis
