by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Ivan Levkivskyi
    @ilevkivskyi
    @LiraNuna yes, please.
    Liran Nuna
    @LiraNuna
    @ilevkivskyi python/mypy#3645 Please feel free to add more information to it
    it's interesting to note that error_with_mypy gets flagged but not get. In fact, if I change get to return an int in that example, I get a correct error, however the error on line 25 persists
    PyCharm also correctly flags it as an error (and does not suffer from mypy's bug)
    Roy Williams
    @rowillia
    @JelleZijlstra if you're around I updated python/typeshed#1431
    Jelle Zijlstra
    @JelleZijlstra
    looks good now, I'll merge once Travis passes
    Roy Williams
    @rowillia
    @JelleZijlstra ty
    Ivan Levkivskyi
    @ilevkivskyi
    Just a small comment for anyone who has an open PR to mypy: --strict-optional has been enabled in CI self-test (except for few files) so that your PRs might fail. Don't be surprised :-)
    Ethan Smith
    @ethanhs
    Another note to anyone. The process count for tests on travis was just reduced to 16, so your CI time will likely increase approximately 5 minutes per build (total)
    Ethan Smith
    @ethanhs
    Also, if you see behavior like python/mypy#3543 add a comment and/or @ me
    Roy Williams
    @rowillia
    If anyone is around I'd love some feedback on python/mypy#3666 . I tried skipping visiting the right branch all together but that caused other tests to explode. Suppressing errors has the same net effect for the end user but feels wrong
    Roy Williams
    @rowillia

    Also: if someone can help me debug the fixtures used that'd be awesome! For whatever reason

    x = None
    x is not None and x.foobar()

    works fine when I type check it but fails in the unit tests

    Ethan Smith
    @ethanhs
    Hm, how are you checking it?
    Roy Williams
    @rowillia
    @ethanhs Fixed the fixture issue on that PR
    Ethan Smith
    @ethanhs
    @rowillia Great! I can take a look at the PR a bit later if you want.
    Roy Williams
    @rowillia
    @ethanhs ty
    Teemu R.
    @rytilahti
    hi, I have the following init.py inside a module, and mypy can't find those classes but gives me 'error: Module 'mirobo' has no attribute 'VacuumStatus''
    what'd be the proper way to have this done?
    Ethan Smith
    @ethanhs
    @rytilahti what is in the __init__.py? Also how are you calling mypy?
    Teemu R.
    @rytilahti
    oh, sorry, the link didn't got pasted... here's the init: https://github.com/rytilahti/python-mirobo/blob/master/mirobo/__init__.py
    and I'm calling mypy with 'mypy mirobo'
    Teemu R.
    @rytilahti
    hm. so the problem is actually that those errors are coming from the using class, where 'from . import VacuumStatus' is used for example
    so a cyclical dep :)
    Michael Lee
    @Michael0x2a

    In Python 3.6+, there are two new ways of annotating fields for complex objects: using class attributes, like so:

    class Foo:
        field1: int
        field2: List[str]
    
        def __init__(self, arg: Bar) -> None:
            # Complex setup logic here

    ...or by annotating instance variables inside __init__, like so:

    class Foo:
        def __init__(self, arg: Bar) -> None:
            self.field1: int
            self.field2: List[str]
    
            # Complex setup logic here

    Is there any sort of official ruling on which version is considered more Pythonic? I know I prefer the second version because it seems conceptually cleaner, but the first version does look more aesthetically pleasing.

    Ethan Smith
    @ethanhs
    @Michael0x2a These are different things.Consider:
    >>> class A:
    ...     attr = 1
    ...
    >>> a = A()
    >>> a.attr
    1
    >>> A.attr = 5
    >>> a.attr
    5
    >>> class B:
    ...     def __init__(self):
    ...         self.attr = 1
    ...
    >>> b = B()
    >>> b.attr
    1
    >>> B.attr = 5
    >>> b.attr
    1 
    But in general, I find class variables much more Pythonic, as they are in the definition of the class, which is where I think most people look for attributes.
    Michael Lee
    @Michael0x2a
    I'm fully aware of that. This is in reference to PEP 526 -- see https://www.python.org/dev/peps/pep-0526/#class-and-instance-variable-annotations
    Ethan Smith
    @ethanhs
    they are less explicit if they are are instance attributes
    Michael Lee
    @Michael0x2a
    (By "conceptually cleaner", I was referring to the exact thing you pointed out)
    Ethan Smith
    @ethanhs
    ah, I see. there is a section on Function Annotations in PEP 8, but perhaps a section on class variables related to PEP 526 would be useful.
    Michael Lee
    @Michael0x2a
    Once a ruling is established, probably, yeah. (The section of PEP 526 I linked you to actually includes both variants, but spends a lot of time covering the first variation but concludes by implying the second variation is the convention, which is a little ambiguous imo)
    Ethan Smith
    @ethanhs
    Well, both are supported so it makes sense to have both
    Ivan Levkivskyi
    @ilevkivskyi
    We considered this question while writing PEP 526. We decided to allow both (class body and __init__). There is a short section about this in Rejected ideas.
    Michael Lee
    @Michael0x2a
    I guess I was wondering if one of the approaches was recommended over the other, from a stylistic point of view
    I know both are allowed, just not definitively which one is recommended
    Ivan Levkivskyi
    @ilevkivskyi
    I don't have preferences here. IIRC Guido prefers in class body.
    This is also the style mostly used in mypy
    (but in 3.5 version x = None # type: int)
    Michael Lee
    @Michael0x2a
    And I guess an implicit second question I have is if that style guideline ought to be formally written down somewhere (e.g. in PEP 8) or if we should leave things as is, though perhaps that's more a question for Guido
    Guido van Rossum
    @gvanrossum
    There seem to be strong opinions either way. I do indeed prefer putting attribute annotations in the class body rather than sprinkling them throughout __init__ and other methods. I also think that with PEP 526 this will be the future (also with things like class-based NamedTuple declarations and possibly https://github.com/ericvsmith/dataclasses).
    Michael Lee
    @Michael0x2a
    @gvanrossum thanks!
    Guido van Rossum
    @gvanrossum
    Everyone, I've pushed a new version of mypy_extensions to PyPI: https://pypi.python.org/pypi/mypy_extensions/0.3.0 -- please test.
    Max
    @pkch
    I noticed a perfectly correct but, I feel, a slightly unfortunate behavior of the type system:
    class Point(NamedTuple('Point', [('x', float), ('y', float)])):
        def __add__(self, other: Point) -> Point:  # E:  error: Argument 1 of "__add__" incompatible with supertype "tuple"
            return Point(self.x + other.x, self.y + other.y)
    Of course, it's correct because NamedTuple is a subclass of tuple, and (1, 2) + (3, 4) is a pre-defined operation in python. I think it's unfortunate because deriving things like Point or Vector from namedtuple is a perfect idiom in non-typed python code; so it's sad to lose that idiom in typed python.
    Max
    @pkch
    I don't see any solution to this (apart from the option of allowing programmers to derive implementation from a class X without subtyping class X, which was rejected IIRC?)
    Ivan Levkivskyi
    @ilevkivskyi

    use other: object and:

    class Point(tuple):
        def __init__(self, x):
            self.x = x
        def __add__(self, other: object) -> Point:
            if isinstance(other, Point):
                return Point(self.x + other.x)
            return NotImplemented

    this should typecheck and also will help Python behave better.

    Max
    @pkch
    :clap: I now remember I had literally the same problem a few months back. I need some memory enhancing things.
    Ivan Levkivskyi
    @ilevkivskyi
    Unfortunately, there is a bug in this pattern with named tuples: they interact strangely with isinstance (IIRC there is already an issue for this)
    Max
    @pkch
    yup python/mypy#3419
    Of course, other than the bug, there's nothing wrong with deriving from NamedTuple right? Maybe it's worth including in the tutorial at some point? It's kinda a nice pattern.