-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Python modules without __init__.py failed to be parsed since 2.5.0 #3528
Comments
I saw that but thought this was "normal" and the same than #352 |
I've done a git bisect on this. Seem like the culprit is a6d7ffc. I guess we don't want to revert it entirely? What do you think @PCManticore ? |
@Pierre-Sassoulas This is the exact same thing as #352. I was able to reproduce it with the following version as well, which does not have the changes in the linked commit:
@nicocti Until we have a fix for #352, you'll need to either have a |
Strange, I tested by creating a directory called
This was clearly working for 2.4.4 and until the commit which I linked, or am I missing something? |
No, you're right, for some reason my testing resulted in the same results on both versions. |
This was a regressin in 2.5. Close #3528
On second look, the fix turned out to be simpler than what I imagined. It's semantically the same with the old behaviour except |
This was a regressin in 2.5. Close #3528
Thanks a lot for this quick fix :) Will keep you updated once I switch to 2.5.1 ! |
I think this caused a regression I am seeing; I was having no issues as of 2.4.4 nor 2.5.0: layout:
qtest.py has an import statement like this: from .machine import QEMUMachine If CWD is 2.4.4:
2.5.0:
but 2.5.1:
Current setup:
If I install a dev copy of 4756b3c (origin/master as of writing) and revert this change, the explicit relative import works again. |
From what I can tell, it seems as if the fact that I have an |
@PCManticore sorry for the pester; should I port my reply here into a new issue? |
@jnsnow No worries. Yes, please open a new issue as it's more likely to get attention. Thank you! |
Note that you will get the same behavior as in the first message when you're linting some local implicit namespace package that (for whatever reason) has the same name as another regular package from
At the same time it will run perfectly fine for
|
Pylint 2.5 fails to parse modules without init.py while 2.4.4 works fine.
I found nothing in the changelog regarding this, so I guess it's a bug.
Steps to reproduce
pylint --disable=C,R ${MODULE_NAME}
Current behavior
raises:
Expected behavior
No error expected since init.py are optional since python 3.4+
pylint --version output
pylint==2.5.0
python==3.6.10
The text was updated successfully, but these errors were encountered: