search

pylint-bot / pylint-unofficial

UNOFFICIAL playground for pylint github migration
0 stars 0 forks source link

warn upon variable type change #674

Closed pylint-bot closed 8 years ago

pylint-bot commented 9 years ago

Originally reported by: Laura Médioni (BitBucket: lmedioni, GitHub: @lmedioni?)

Emit a warning when the type of a variable changes inside a function or a method.

Example:

foo = 2
(...)
foo = []

should trigger a warning.

pylint-bot commented 9 years ago

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

I see how this can be unintentional in some cases, but something like:

labels = input()
labels = labels.split(',')
...

is okay IMHO.

pylint-bot commented 9 years ago

Original comment by Laura Médioni (BitBucket: lmedioni, GitHub: @lmedioni?):

As I explained yesterday in the mailing list, all these new rules were ordered to us by the CNES. But not all of them may seem reasonable, and the idea is precisely to discuss with pylint community to decide which rules will be kept in pylint, and which one will only be delivered to our client.

Your counterexamples are interesting, and may also make them think about whether they really want these rules.

pylint-bot commented 9 years ago

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

Yeah, I read the mailinglist post after replying to the issues, sorry :)

I'd like to check my project and some others to see how often this is done and seems reasonable, and how often not... but this is kind of a chicken-egg problem, I don't know how I'd find those things before the check is implemented ;)

Also, thank you for contributing all this upstream instead of just keeping those checkers locally!

pylint-bot commented 9 years ago

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

This is a bit too restrictive for pylint and for Python in general. There are functional languages which enforces this at the language level, but having it in pylint will cause more nuissance in the long run.

pylint-bot commented 9 years ago

Original comment by Sylvain Thénault (BitBucket: sthenault, GitHub: @sthenault?):

It seems to me that this one deserves a try. It can be done in our client specific checker, but at a first glance it sounds like a good practice in general.

pylint-bot commented 9 years ago

Original comment by Sylvain Thénault (BitBucket: sthenault, GitHub: @sthenault?):

I agree that Florian's case sounds right, but remember pylint overall policy is to point to things which are potentially problematic, while one may perfectly disable it locally or globally if he thinks its fine.

IMO this is a case that should be handled so I reopen the issue.

pylint-bot commented 9 years ago

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

Before taking a decision though we should gather stats about how many of these errors will be emitted on a code base, because I feel there's going to be a lot of them. One of the things that pylint users hate is the amount of opinionated messages that don't bring too much value and which makes daunting the task of improving their code. That's why I still hear opinions about how great flake8 is, even though it's subpar comparing with pylint's capabilities.

pylint-bot commented 9 years ago

Original comment by Sylvain Thénault (BitBucket: sthenault, GitHub: @sthenault?):

Right. I propose that we propose an implementation so we may try it and decide whether to include it or not into pylint core.

pylint-bot commented 9 years ago

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

Agreed.

pylint-bot commented 8 years ago

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

This was merged a couple of days ago.