provide type annotations about bidict HOT 18 CLOSED

Just a quick update to say that I posted this example to python/typing#548 and Guido said it was helpful.

from bidict.

@cjgibson, @itaisteinherz, @MartinThoma, @HarrySky, et al., just released v0.21.0, the first bidict release with type hints! Thanks for the testing and encouragement here. 😊 Hope the new release works well for you, and please let me know if you have any issues.

from bidict.

As you can see from screenshot - reverse working well (type was bidict[tuple, NodeId])

from bidict.

Hiya @jab - I'd been looking for an excuse to dig into Python's type hints, do you mind if I work on this over the weekend? Or are you waiting until Python 3.5 hits end-of-life in September 2020?

from bidict.

Is your interest in adding them just an excuse to learn type hints better...

To be totally honest, I had assumed bidict would already have them - I've used this library in the past as a great learning library, so I'm a little excited to get a chance to improve bidict in that regard!

That said, it may make sense to remove Python 2 support (#97) before working on this...

Totally agreed. I'll start on that over the weekend instead, and keep this in the back of my mind in the interim.

I'm pretty busy and don't know how soon I'd be able to review your PR.

Absolutely no worries - comes with the territory 😀

from bidict.

Thank you for handling that! I got started late Sunday: jab:50e87fd...cjgibson:9d76098

But only got my fork to a sane state this evening. An unexpected issue is that mypy really doesn't like mixing Generics with collections.namedtuple (see: python/mypy#685). I've temporarily side-stepped that limitation by adding some hacky __slots__'ed classes in the interim, but am hunting for a less intrusive solution. There are some linting things I need to resolve (mostly due to overly lengthy lines or unused imports), but there's finally something to look at!

from bidict.

Wow! Thanks @cjgibson, fantastic to see your progress! 😻
Left some comments in f40b1b6, but please feel free to ignore them completely at this point and just keep hacking away at whatever you're interested in.

I pulled your changes into my typehints branch and then took a first stab at some mypy integration into Travis: 1de89e2
In case it's helpful for once you're at that stage.

Thanks again for working on this! So cool! 😊

from bidict.

@jab hey, great project. I just tried the fix and it works with pip install 'git+https://github.com/jab/bidict.git', but same code fails on current 0.20.0. Can you please release this fix?

>>> from bidict import bidict
>>> a: bidict[str, int] = bidict({"a": 5})

from bidict.

Hi @cjgibson, I'd be delighted for you to work on this! I actually haven't been sure how many users were even interested in having type hints in bidict. Is your interest in adding them just an excuse to learn type hints better, or would you benefit from them as a bidict user too?

Always happy to hear from users and want to make sure users' needs are taken into account for future releases. I think I'm fine with adding this anytime, and dropping support for 3.5 before its EOL if that'd make this easier. As usual, I think dependents (especially those stuck on older versions of Python) should be pinning to known-compatible versions in production anyway.

That said, it may make sense to remove Python 2 support (#97) before working on this (which also doesn't have to wait for Python 2 EOL). That would make all future changes easier, and especially changes like this, I think.

I'm pretty busy and don't know how soon I'd be able to review your PR. (Especially since I also haven't yet had time to become an expert on Python's type hints, which I'd want to first.) But receiving a high-quality PR would be a great motivation to make time for this.

If you decide to work on this (and/or #97), please feel free to keep in touch during the process in case there's anything I can help with as time permits.

And thanks so much for your interest in contributing to bidict!

from bidict.

Hey @cjgibson, I felt bad suggesting you work on the much less interesting #97 before looking at type hints, so I made some time this morning to knock out #97. That work is currently on the dev branch UPDATE: now merged to master (cd73edd), which should give you a better foundation to base this work on. Hope this makes for some more interesting weekend hacking for you!

from bidict.

@jab @cjgibson Hi 👋🏻 It would be great to have type annotations when using bidict, and since I noticed this has been open for a while, I wanted to ask if you intend to continue working on this?
(And if you're looking for someone to help you get this landed, I'd love to chime in and help 🙃)

from bidict.

Hiya @itaisteinherz, you're welcome to take this on if you'd like! My initial work brought about some refactoring changes from @jab, so I stepped back a bit while those were ongoing and never really came back around to this task. From what I recall @jab has started adding their own typing over on the typehints branch, but I'll let them speak to that.

from bidict.

Thanks for your interest @itaisteinherz, and thanks for your update, @cjgibson! Indeed, I continued work on this on my typehints branch after the great start @cjgibson made here, but unfortunately I hit a wall with limitations in mypy and haven't gotten back to it since.

The biggest problem I hit is that I think mypy currently makes it impossible to type hint the .inverse property correctly. You want to be able to do something like:

f = frozenbidict({0: 'zero'})
reveal_type(f.inverse)

and have that reveal_type call result in frozenbidict[str, int], merely from the type hint of the inherited inverse implementation, i.e. without frozenbidict having to provide its own inverse implementation (that merely returned super().inverse) just so it could refine the return type to frozenbidict.

In other words, for any BidirectionalMapping of type B[KT, VT], its inverse should be of type B[VT, KT]. This requires composing type variables in a way that mypy apparently does not yet support, apparently due to python/typing#548. So at this point, the best way to contribute to getting type hints in bidict just might be to contribute a fix to that mypy issue – once I have that I think I can take care of this pretty quickly. Is that something either of you would be interested in working on?

Thanks again for your interest, and looking forward to getting type hints in bidict hopefully before too much longer.

from bidict.

What is the recommended type annotation for bidict right now?

from bidict.

Every time I try to pick this back up, I hit another challenge. This time it appears to be a bug in Python 3.6. Reported here: https://bugs.python.org/issue41451

Until I can drop support for Python 3.6, I think we're blocked on finding a workaround for this bug.

from bidict.

Big thanks to @oremanj for suggesting a workaround for https://bugs.python.org/issue41451. (In case of interest, I had to adapt the full-on del BidictBase.__slots__ suggestion because it broke pickling, but it was easy to replace it with BidictBase.__slots__.remove('__weakref__'), which worked just as well.)

Opening a PR momentarily that should resolve this issue when it's merged. 🎉

from bidict.

Hi all, I just merged #112 adding type hints! Could you please run pip install 'git+https://github.com/jab/bidict.git' to try it out and let me know how well everything is working for you before I make a new release?

from bidict.

Thanks for letting me know, @HarrySky! I'm currently trying to figure out whether I should be using a covariant value type (following the example from Mapping in typeshed) for the immutable bidict types. But that would mean their inverse types would have a covariant key type, which according to the comment in typeshed (see previous link), "doesn't work (see python/typing#273)". I've asked for advice in https://gitter.im/python/typing?at=5f38373da1190a2e95f4d1f1, but if anyone watching this issue can chime in please do.

UPDATE: I was pretty sure before, but now I'm convinced that as long as Mapping isn't promising a covariant key type, BidirectionalMapping can't promise a covariant value type, since it would imply the existence of a BidirectionalMapping with a covariant key type (namely, its inverse).

from bidict.