Skip to content

Consider removing six, past, and future support #13567

Open

Description

@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

Activity

  1. self-assigned this
    on Aug 31, 2022
  2. AlexWaygood commented on Aug 31, 2022

    @AlexWaygood
    Member

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

  3. sobolevn commented on Aug 31, 2022

    @sobolevn
    MemberAuthor

    Top:
    Снимок экрана 2022-08-31 в 16 45 04

    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.

  4. AlexWaygood commented on Aug 31, 2022

    @AlexWaygood
    Member

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

  5. JukkaL commented on Sep 1, 2022

    @JukkaL
    Collaborator

    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.

  6. sobolevn commented on Sep 1, 2022

    @sobolevn
    MemberAuthor

    Ok, fair points!

  7. AlexWaygood commented on Sep 1, 2022

    @AlexWaygood
    Member

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

  8. JukkaL commented on Sep 1, 2022

    @JukkaL
    Collaborator

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions