We're rebuilding many popular projects with Python 3.11 alpha, and I see
many failures like:
AttributeError: module 'configparser' has no attribute
'SafeConfigParser'. Did you mean: 'RawConfigParser'?
(bpo-45173)
ImportError: cannot import name 'formatargspec' from 'inspect'
(bpo-45320)
AttributeError: '[...]Tests' object has no attribute 'failUnless'
(bpo-45162)
Are these changes necessary?
Does it really cost us that much in maintainer effort to keep a
well-tested backwards compatibility alias name, or a function that has a
better alternative?
I think that rather than helping our users, changes like these are
making Python projects painful to maintain.
If we remove them to make Python easier for us to develop, is it now
actually that much easier to maitain?
The current backwards compatibility policy (PEP 387) sets a *minimum*
timeline for deprecations and removals -- "deprecation period must last
at least two years."
But it seems like it's not treated as a minimum: if any contributor
sends an issue/PR to remove deprecated functionality, it's merged
without much discussion. And it's very easy to "solve" these "issues",
since everything is already marked for deletion; I fear we get the same
kind of bikeshed/powerplant problem https://bikeshed.com/ for changes
that explains for discussion. It's just so much easier to do "spring
cleaning" than solve other problems.
Note that I am criticizing the *process*; the examples I gave have some
people's names attached, and I have no doubt the people acted with best
intentions.
I'm also not talking about code that's buggy, insecure, or genuinely
hard to maintain.
If deprecation now means "we've come up with a new way to do things, and
you have two years to switch", can we have something else that means
"there's now a better way to do things; the old way is a bit worse but
continues to work as before"?
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AYJOQL36SK3EK5VMEKT5L5BVH25HVY4G/
Code of Conduct: http://python.org/psf/codeofconduct/
many failures like:
AttributeError: module 'configparser' has no attribute
'SafeConfigParser'. Did you mean: 'RawConfigParser'?
(bpo-45173)
ImportError: cannot import name 'formatargspec' from 'inspect'
(bpo-45320)
AttributeError: '[...]Tests' object has no attribute 'failUnless'
(bpo-45162)
Are these changes necessary?
Does it really cost us that much in maintainer effort to keep a
well-tested backwards compatibility alias name, or a function that has a
better alternative?
I think that rather than helping our users, changes like these are
making Python projects painful to maintain.
If we remove them to make Python easier for us to develop, is it now
actually that much easier to maitain?
The current backwards compatibility policy (PEP 387) sets a *minimum*
timeline for deprecations and removals -- "deprecation period must last
at least two years."
But it seems like it's not treated as a minimum: if any contributor
sends an issue/PR to remove deprecated functionality, it's merged
without much discussion. And it's very easy to "solve" these "issues",
since everything is already marked for deletion; I fear we get the same
kind of bikeshed/powerplant problem https://bikeshed.com/ for changes
that explains for discussion. It's just so much easier to do "spring
cleaning" than solve other problems.
Note that I am criticizing the *process*; the examples I gave have some
people's names attached, and I have no doubt the people acted with best
intentions.
I'm also not talking about code that's buggy, insecure, or genuinely
hard to maintain.
If deprecation now means "we've come up with a new way to do things, and
you have two years to switch", can we have something else that means
"there's now a better way to do things; the old way is a bit worse but
continues to work as before"?
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AYJOQL36SK3EK5VMEKT5L5BVH25HVY4G/
Code of Conduct: http://python.org/psf/codeofconduct/