Annotate and make attrs-strict PEP 561 compatible

[keiclone]

Is your feature request related to a problem? Please describe.
attrs-strict is great because it adds runtime type validation to my attrs classes, but it'd be great if it could play nice with my static type checkers as well.

Describe the solution you'd like
Annotate all the functions and add py.typed to setup.py per PEP 561

Describe alternatives you've considered
A quick way to incorporate attrs-strict in my projects would be to add some stubs for it to MYPYPATH. Might as well contribute the effort back.

[erikseulean]

This looks like a good idea; if you'd like to implement it yourself @keiclone I can assign this to you.

[keiclone]

Sure thing, I can take this.

[erikseulean]

Great, I assigned this to you.

[erikseulean]

@keiclone any updates on this ?

[keiclone]

Sorry for the delay, I should be able to find some time after the holidays.

…

On Fri, Dec 27, 2019, 5:37 PM Erik-Cristian S. ***@***.***> wrote: @keiclone <https://github.com/keiclone> any updates on this ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#24?email_source=notifications&email_token=AASBK3PEPMK23MJNT6IEXOTQ2Z7SPA5CNFSM4JOXJCP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHX3NAY#issuecomment-569357955>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASBK3NX6Y3BKDBUZWY3EWLQ2Z7SPANCNFSM4JOXJCPQ> .

[keiclone]

working on this right now. looking at the README and tox.ini, it seems up to this point, we have been supporting python 2.7. Note that afaik, proceeding with this may break backwards compatibility with 2.7, since the annotations will affect function signatures.

One alternative would be to proceed in the same fashion as attrs and create a .pyi stub file for every module we have. There are some drawbacks with this approach:

• it will be an extra bit of mental load to make sure each change keeps the stub files up to date and in sync with the code
• I think it will also require some duplicate efforts in order to have CI enforce that each function is annotated moving forward (involving python2 compliant annotations, but feel free to correct me here)
• doing things the way attrs does can be a very involved process

On the other hand, breaking backwards compatibility means we would no longer be completely in sync with the version support of the original attrs library. Maybe that's not a priority for us? Maybe we can say the last release that supports Python 2.7 is version 0.0.4?

We could also do some middle ground solution like only annotating some functions to mitigate the drawbacks of keeping 2.7 compatibility.

Since the current year is now 2020 and python 2.7 is officially deprecated, are we okay with dropping support for it now? Or do we wish to support it as long as attrs does?

[gaborbernat]

Since the current year is now 2020 and python 2.7 is officially deprecated

CPython 2.7 might be no longer maintained, but PyPy 2.7 is still supported (that website is a bit lying as it really should be https://cpythonclock.org/ 🤷‍♂ ). So the real question is do we want to drop that platform? I'm not 100% sure on that.

[alexchamberlain]

Personally, for a library like this, I'd vote against removing 2.7 support unless absolutely necessary or because the upstream package (attrs) removes it.

[erikseulean]

I'd prefer to keep the 2.7 support longer, that being said I'd say this should be parked until we drop the 2.7 support ?

[erikseulean]

Done!