Repository navigation
Consider removing six, past, and future support #13567
Copy link
Copy link
Open
Labels
Description
Since python2 is now no longer supported, I think it might be a good time to remove special casing of these libraries.
Why?
- None of them are required for python3+ code
- All their features are now (long) supported by python3+
- Their support is clearly a hack
- Code to support them is quite complex:
Lines 1971 to 2018 in 840a310
def update_metaclass(self, defn: ClassDef) -> None: """Lookup for special metaclass declarations, and update defn fields accordingly. * six.with_metaclass(M, B1, B2, ...) * @six.add_metaclass(M) * future.utils.with_metaclass(M, B1, B2, ...) * past.utils.with_metaclass(M, B1, B2, ...) """ # Look for six.with_metaclass(M, B1, B2, ...) with_meta_expr: Expression | None = None if len(defn.base_type_exprs) == 1: base_expr = defn.base_type_exprs[0] if isinstance(base_expr, CallExpr) and isinstance(base_expr.callee, RefExpr): base_expr.accept(self) if ( base_expr.callee.fullname in { "six.with_metaclass", "future.utils.with_metaclass", "past.utils.with_metaclass", } and len(base_expr.args) >= 1 and all(kind == ARG_POS for kind in base_expr.arg_kinds) ): with_meta_expr = base_expr.args[0] defn.base_type_exprs = base_expr.args[1:] # Look for @six.add_metaclass(M) add_meta_expr: Expression | None = None for dec_expr in defn.decorators: if isinstance(dec_expr, CallExpr) and isinstance(dec_expr.callee, RefExpr): dec_expr.callee.accept(self) if ( dec_expr.callee.fullname == "six.add_metaclass" and len(dec_expr.args) == 1 and dec_expr.arg_kinds[0] == ARG_POS ): add_meta_expr = dec_expr.args[0] break metas = {defn.metaclass, with_meta_expr, add_meta_expr} - {None} if len(metas) == 0: return if len(metas) > 1: self.fail("Multiple metaclass definitions", defn) return defn.metaclass = metas.pop() - There are multiple places where
six./ etc special cases are used:mypy/stubgen.py,mypy/semanal.py,mypyc/irbuild/for_helpers.py
I don't see much benefit in keeping them.
Related #12237
Reactions are currently unavailable
Activity
AlexWaygood commentedon Aug 31, 2022
Removing
sixspecial-casing might be quite disruptive, given that it's still the 12th-most downloaded package on PyPI: https://pypistats.org/topsobolevn commentedon Aug 31, 2022
Top:

I think that
mypy_primerwill help us here.Offtop: Wow, I never knew that
boto3is so popular. I have a gut feeling that there's something wrong with its numbers.AlexWaygood commentedon Aug 31, 2022
Agreed (though there may also be closed-source repos that still use
sixa lot, and mypy_primer won't be able to see those).JukkaL commentedon Sep 1, 2022
I think that
mypy_primercovers only a small fraction of all code type checked by mypy. I expect thatsixwill continue to be used widely for several years at least, since many projects are very slow to upgrade their codebases to not rely on legacy features. In the main closed source repo I use at work we are still usingsixheavily, at least, even though we've dropped Python 2 support some time ago.As far as I know, removing usages of
sixhas to be done mostly manually. Good tool support for this could accelerate the removal ofsixdependencies.sobolevn commentedon Sep 1, 2022
Ok, fair points!
AlexWaygood commentedon Sep 1, 2022
I think pyupgrade will automatically remove a lot of
sixusage, actually. That might help :)JukkaL commentedon Sep 1, 2022
Nice, I didn't know about this! There are some trickier use cases such as
six.ensure_binarythat it can't replace yet -- likely because there is no simple replacement in the stdlib, as far as I know.