Skip to content

Unions that include Any should probably not just become Any #1642

Closed

Description

@ddfisher

Currently, UnionType.make_simplified_union will return an Any if any of the types passed in are Any. This probably doesn't make sense.

As a simple example, if we have:

def f(x: Union[str, Any]) -> int:
    return x + 1

(This example looks a little silly, but this Any might not be explicit -- it could e.g. be a class from a --silent-imports module.)
This is clearly unsafe. I think we should still require an isinstance check.

Activity

  1. gvanrossum commented on Jun 4, 2016

    @gvanrossum
    Member

    What's the real example where you got this? ISTM that if a value can be Any then mypy should shut up about it, not try to be picky. If we consider a type to be a set of values, then Any is the set of all values, so adding strings to it doesn't do anything.

  2. ddfisher commented on Jun 4, 2016

    @ddfisher
    CollaboratorAuthor

    I think Any is the one type that can't be thought of as a set of values. (For example, if we think of Any as the set of all values, then you should only be able to do things to it that can be done to all values... but that's not the case.)

    I wasn't directly bitten by this, but I realized this was a bit fishy while I was reviewing #1639.

  3. gvanrossum commented on Jun 4, 2016

    @gvanrossum
    Member

    Hm... The situation in #1639 is a little different. The expression in the except clause must be either an exception or a tuple of exceptions, but it cannot be a tuple of tuples of exceptions. So it is incorrect to treat it as a union, and the code is right to insist that each individual value in the tuple is compatible with BaseException -- not that the tuple as a whole (or the tuple turned into a union) is compatible with BaseException.

    I still don't think that from your original example above it follows that Union[X, Any] should be treated differently than Any.

    You can still use isinstance(x, X) if you want uses of x to be checked more precisely as an X.

  4. JukkaL commented on Jun 9, 2016

    @JukkaL
    Collaborator

    Preserving Any inside a union would potentially let us catch some more errors, but figuring out all the implications of this could be a little tricky. I'd rather not worry about this right now as the current behavior is quite reasonable and it conforms to the spirit of how Any works in general. If we see unions like these in user code with non-trivial frequency then we might want to reconsider.

  5. gvanrossum commented on Jun 9, 2016

    @gvanrossum
    Member

    Let's close this issue then.

  6. ddfisher commented on Aug 31, 2016

    @ddfisher
    CollaboratorAuthor

    I've since seen this issue in user code, and we're more agreed on this being a good idea. Reopening so we don't forget about this.

  7. gvanrossum commented on Sep 1, 2016

    @gvanrossum
    Member

    Should probably also be brought up in the python/typing tracker.

  8. added this to the milestone on Sep 1, 2016
  9. removed this from the milestone on Mar 29, 2017
  10. JukkaL commented on Jun 13, 2017

    @JukkaL
    Collaborator

    This was implemented a while ago.

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

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions