On Sun, Nov 14, 2021 at 8:19 AM Stephen J. Turnbull < stephenjturnbull@gmail.com> wrote:
But do we need to support running the same code on 3.5 to 3.10?
Need? No. Want to not raise a big middle finger to our users?
Note that I said 3.5, not 3.6 -- 3.5 is no longer supported. If we feel the need to be backward compatible with unsupported versions that we can't ever remove anything. I wouldn't mind if the tool gently suggests, ''' hey, folks, you can't
really support both 3.5 AND 3.10 without a lot of "if hasattr(foo, 'frob')", so maybe you can drop support for 3.5? ''', though.
now I'm confused -- if you need the hasattr() calls, then you aren't supporting it.I guess I meant: runinng the same code without special case code to handle the differences. Which is why I said "like 2to3" rather than "like six". I always hated six, even though it was a necessary evil.
I’m confused — did you mean “sometimes cause dangerous behavior”? That’s
pretty rare isn’t it?
FVO of "often" == "yeah, I've heard enough stories that I worry about it", I mean "often".
hmm -- is there any way to know which deprecations might actually be dangerous? -- for instance, it's hard to imagine a name change alone would be that, but I have a failure of imagination. Eric V. Smith wrote:
I write systems that support old versions of python. We just moved to 3.7, for example.
But do you need to support non longer supported versions of Python -- 3.7 is still supported, for just these reasons. Can we remove stuff that's only needed by unsupported versions of Python? So you have an application running on 3.5. You really should upgrade Python anyway. When you do, you will need to run an "update_deprecated_stuff" script, and test and you're good. Is that too much a burden? Frankly, even the 2to3 transition was less painful than I thought it would be -- I had a substantial codebase written for py2 -- we couldn't go to three for quite some time, as we have a LOT of dependencies, and it was a while before they were all supported. When we finally made the transition it was less painful than I thought it would be and it would have been even less painful if we hadn't had a both-2-and-3 stage. And we've got a bunch of Cython code that bridges strings between Python and C++, too. For all of the testing and signoffs we do for a single release,
I've calculated that it costs us $5k just to release code to prod, even if there are no actual code changes.
But that's a fixed cost -- any maintained codebase is going to need updates and re-releases. I don't think anyone's suggesting that you do a release only to remove deprecations. For the example above -- if ALL you are doing is moving from running on Python 3.5 to running on a newer version, wouldn't that $5k cost have to be absorbed anyway? -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython