Consider removing `six`, `past`, and `future` support

[sobolevn]

Since python2 is now no longer supported, I think it might be a good time to remove special casing of these libraries.

Why?

1. None of them are required for python3+ code
2. All their features are now (long) supported by python3+
3. Their support is clearly a hack
4. Code to support them is quite complex:

   mypy/mypy/semanal.py

   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()

5. 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

[AlexWaygood]

Removing six special-casing might be quite disruptive, given that it's still the 12th-most downloaded package on PyPI: https://pypistats.org/top

[sobolevn]

Top:

I think that mypy_primer will help us here.

Offtop: Wow, I never knew that boto3 is so popular. I have a gut feeling that there's something wrong with its numbers.

[AlexWaygood]

I think that mypy_primer will help us here.

Agreed (though there may also be closed-source repos that still use six a lot, and mypy_primer won't be able to see those).

[JukkaL]

I think that mypy_primer covers only a small fraction of all code type checked by mypy. I expect that six will 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 using six heavily, at least, even though we've dropped Python 2 support some time ago.

As far as I know, removing usages of six has to be done mostly manually. Good tool support for this could accelerate the removal of six dependencies.

[sobolevn]

Ok, fair points!

[AlexWaygood]

As far as I know, removing usages of six has to be done mostly manually.

I think pyupgrade will automatically remove a lot of six usage, actually. That might help :)

[JukkaL]

I think pyupgrade will automatically remove a lot of six usage, actually.

Nice, I didn't know about this! There are some trickier use cases such as six.ensure_binary that it can't replace yet -- likely because there is no simple replacement in the stdlib, as far as I know.