New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support py3.5 style typing annotations #647

Open
pylint-bot opened this Issue Sep 25, 2015 · 19 comments

Comments

Projects
None yet
@pylint-bot
Copy link

pylint-bot commented Sep 25, 2015

Originally reported by: Anonymous


In the very least it would be nice to force type assertions on function arguments (i.e. this is definitely a string)

Would also be cool to support them in py2 via backports.typing or typing packages. The py2 version could even be nice enough to support multiple @annotations decorators for overloads as defined in https://www.python.org/dev/peps/pep-0484/#stub-files .


@pylint-bot

This comment has been minimized.

Copy link
Author

pylint-bot commented Sep 25, 2015

Original comment by Florian Bruhin (BitBucket: The-Compiler, GitHub: @The-Compiler?):


Also see https://bitbucket.org/logilab/astroid/issues/153/investigate-the-use-of-typingpy

@pylint-bot

This comment has been minimized.

Copy link
Author

pylint-bot commented Sep 26, 2015

Original comment by Claudiu Popa (BitBucket: PCManticore, GitHub: @PCManticore):


That's in our roadmap, but it will not happen very soon. There aren't many libraries (or code) which can use PEP 484 annotations, so it's not as urgent as it may seem.

@dstromberg

This comment has been minimized.

Copy link

dstromberg commented Jul 12, 2016

+1. I'd love this.

Actually, type annotations have been around since Python 3.0. It's the typing module that's new to 3.5 - but there's a backport.

@PCManticore

This comment has been minimized.

Copy link
Member

PCManticore commented Jul 14, 2016

Yes, I was referring to the typing module and its inherent types, rather than function annotations (which we do support, but we don't process them). While this would be useful, it would take some time to have it, I presume a couple of weeks worth of work, which I cannot put into right now. It's definitely on our roadmap for the future.

@WielkiZielonyMelon

This comment has been minimized.

Copy link

WielkiZielonyMelon commented Aug 19, 2016

+1

Actually, I have just moved to a new team in my company. The typing hints are used here. I would love to see this feature!

@zrneely

This comment has been minimized.

Copy link

zrneely commented Dec 2, 2016

I'm also interested in this feature! Notably, since pylint is used by default by Syntastic, vim users with that plugin installed will automatically get type checking on each file write.

@Paebbels

This comment has been minimized.

Copy link

Paebbels commented Dec 5, 2016

The evaluation of type hints might be needed to solve this issue: protected-access and @classmethod cls.

As I added a type hint in my code (see the linked issue from Landscape.io), pyCharm showed the correct behavior.

@johan-bjareholt

This comment has been minimized.

Copy link

johan-bjareholt commented May 4, 2017

This would be very nice. Currently using the typing system and doing static checking with mypy. I have landscape.io set up for a github project which currently create a lot of invalid errors due to it using pylint to find these errors and sinks our code health metric a lot due to this. It creates a invalid-sequence-index when for example using def myfunc(arg1: Optional[int], arg2: List[int]) for example.

@marius92mc

This comment has been minimized.

Copy link

marius92mc commented Oct 11, 2017

Is there any news on this issue? Any plans of introducing/releasing it?

@PCManticore

This comment has been minimized.

Copy link
Member

PCManticore commented Oct 12, 2017

Yes, we do have a plan to implement this feature, what we lack is the time, which is why the issue is still open.

@PCManticore PCManticore modified the milestones: 4.0, 5.0 Apr 25, 2018

@tiny-dancer

This comment has been minimized.

Copy link

tiny-dancer commented Dec 26, 2018

annual checkup :) - @PCManticore what's the latest?

I see it's added to milestone 5 while 3 and 4 are still in progress. Are there any rough estimates?

Thanks!

@PCManticore

This comment has been minimized.

Copy link
Member

PCManticore commented Dec 27, 2018

@tiny-dancer Thanks for the bump, unfortunately the answer is still that we're going to do this someday. I have no rough estimates on anything regarding pylint, as I mostly work on it at most a couple of hours per week.

@Paebbels

This comment has been minimized.

Copy link

Paebbels commented Dec 27, 2018

This means, pylint becomes an unusable tool because no active Python version will be supported from March 2019 on? That's the date when Python 3.4 reaches end-of-life and Python 3.5 becomes the lowest actively supported version number.

However, the expectation is that Python 3.4.10 will be released in March of 2019, and this will be the final release of Python 3.4.

Source: https://www.python.org/dev/peps/pep-0429/

I honestly dislike that a tool like pylint hinders developers to use a up-to-date programming language revision. Because of automatic checking tools relying on pylint, we are forced to use old Python code or disable checks.

@troyready

This comment has been minimized.

Copy link

troyready commented Dec 27, 2018

This means, pylint becomes an unusable tool because no active Python version will be supported from March 2019 on

While this is an important issue to solve, it's not that dire. Many (most?) python projects won't be using type annotations yet, and if it's important to have them then you can still use the comment style annotations instead.

@PCManticore

This comment has been minimized.

Copy link
Member

PCManticore commented Dec 27, 2018

@Paebbels I don't know from where you got that impression. We dont support type annotation as in we are not a type checker, this doesn't mean pylint is not usable for you know, what it's name suggests, linting. Please stop with the FUD, if you don't like the general state of things, feel free to contribute financially to the project.

@pietrodn

This comment has been minimized.

Copy link

pietrodn commented Dec 28, 2018

Actually it’s not true that you can just use the type comments syntax. If I do:

from typing import Dict
a = {}  # type: Dict[str, int]

Then pylint complains that Dict is imported but unused, since it’s only used in a comment.
Further, Dict needs to be imported for mypy to work.

And there’s no way to disable that pylint warning only for the typing module, AFAIK.
So either I disable the unused import warning globally — but it’s useful! —, or I live with the pylint warnings.

@dstromberg

This comment has been minimized.

Copy link

dstromberg commented Dec 28, 2018

@troyready

This comment has been minimized.

Copy link

troyready commented Dec 28, 2018

I think the best workaround for now is just disabling the import check for that line:

from typing import Dict  # pylint: disable=unused-import
@The-Compiler

This comment has been minimized.

Copy link
Contributor

The-Compiler commented Dec 29, 2018

On configurations where astroid uses typed-ast, this isn't an issue at all - however, typed-ast doesn't support Python 3.7 yet: python/typed_ast#60

Either way, that issue seems like something different from "pytest should interpret type annotations".

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