The goal is to shorten deprecation periods like this, by giving the developer an easy way to update their code base.
This example would look like this:
class UnitTest:
assertRaises = codecrumbs.renamed_attribute("assert_raises")
def assert_raises(...):
...
The old and new method are both available and there are some things which should accelerate a adoption of the new method:
a deprecation warning is raised
pytest --codecrumbs-fix can be used to refactor all usages which where triggered during the test.
The barrier for the developer to use codecrumbs is really low. The pytest-plugin is part of codecrumbs and already usable. This reduces the time for refactoring N lines of code to executing pytest 1 time with --codecrumbs-fix.
I am aware that this would not allow to solve the problem in this thread now, because:
codecrumbs is still pretty new
works currently only with pytest
has currently not the goal to be used inside cpython
and still has to prove itself in the real world
But it might provide a way to solve issues like this in the future.
Are you assuming that EVERYONE IN THE WORLD is willing to use this package to update their codebase, push out a new release, and convince EVERYONE IN THE WORLD to update to the new release?
Some software is dead but still useful. Sometimes an author has moved on (or passed on) and does not update the code any more. No tool will solve this.
As an alternative, we could just not deprecate the old ones (as was done in the threading module - it wasn’t till Python 3.10 that they were even deprecated). That way, the “tool for translating to the old names” is simply the standard library.
This is called backward compatibility. It’s more important than a lot of people give it credit for. Randomly renaming things is NOT backward compatibility.
So when people ask for aliases, it is important to note that the existing names MUST be kept for a long time - meaning that the codebase and the community will have duplicate names for many years.
So are you saying that you want to reduce backward compatibility by forcing everyone to rename things, or not? Since, by definition, your tool cannot guarantee to be used on every program in the world, shortening the deprecation period will weaken backward compatibility. So if that’s a goal, then this is a fundamental problem.
shortening depercation periods might become a long term effect IF codecrumbs gets for used
for refactoring like black is used for formatting (and this is a really big if). I should not have called it a goal. I think the time saving aspect is currently much more useful.
If you make them easier, you are effectively encouraging them. But I don’t think there would be more major versions. There’d just be more backward incompatible changes in regular releases.
Also, you have it backwards: Major versions do not exist to break backward compatibility. Version numbers exist to convey information. The change first has to be justified, and then described.
My posting was deleted twice (read: censored) before, so I need to watch my step with every single word in my statement. I hope to get it right this time.
This seems like incorrect reasoning. Old code bases work with old Python versions. And they will likely stay there when they become unmaintained.
The Java-style camelCase boilerplate crap of unittest is a damn spell. It should long have been addressed and I think it’s fair that people continue to bring it up. The real hurdle is getting people used to a new syntax. People complain.
One way to getting people to update their - maintained - code bases is with introducing new rules in established linting tools and the like (e.g. Pylint, ruff). Tools like the one Frank suggests certainly help to migrate code bases that need to be “modernized”. It’s not fair to claim the opposite.
Unlike what mobile phone manufacturers seem to want to imply, software does not live forever on the exact hardware and OS stack that it was originally launched for. The entire point of backward compatibility is to allow old software to continue to work through future updates.
Part of the problem is that there are two solutions, neither of which will satisfy everyone:
Add aliases and don’t deprecate the old names. This doesn’t solve the problem, because now there’s code out there using the old names AND code out there using the new names, and people will ask “when should I use each name?”. (And the correct answer is: “Use the camelCase names, they work on all versions of Python”. So nothing is solved.)
Add aliases with a definite deprecation of the old names, preferably with a predetermined version at which they will be removed. This solves the problem once that removal version is reached, in the sense that now all unittests are written using the snake_case names, but in the meantime, you have broken literally every program that uses unittest and forced them all to update.
So which do you want? A solution that doesn’t really solve the problem, or a solution that solves the problem by causing a much much larger problem?
And that’s why people continue to bring this up. There is simply no easy fix for this. If there were, it would already have been done.
Yes, that’s fine. As long as (a) the codebase is maintained, (b) the maintainers are using these tools, (c) the maintainers have updated their tools to gain the new rules, (d) they don’t need to maintain backward compatibility themselves (“our tests all fail on Python <3.XY” is not a good look for a project), and (e) they are willing to go through useless churn for the sake of a rename, yes, this will work.
Question: Suppose your linter grows a new rule that says “docstrings must now use triple apostrophes, not triple double-quotes” - would you edit your entire codebase, or would you silence that linter warning? I suspect a lot of maintainers would silence the linter, taking you right back to square one.
Oh, and also:
That wasn’t censorship. But if you have a problem with the mods, take it up with the mods, don’t post about it here. We can’t do anything about it.
