Intellisense: "Unable to resolve ..." for py files in subfolder?

 wlcohagan May 14 at 4:10 PM I'm running VS 12.30110.00 Update 1, PTVS 2.1203.19.03. I have organized my Python project using subfolders containing collections of *.py files. Using subfolders appears to break Intellisense. Completion doesn't work, GoTo Definition doesn't work, Find References doesn't work, etc., etc. Further, my import statements referencing these subfolder resident files show the green squiglies; however my program runs fine -- so at runtime the references are apparently resolved without problem. Note that these subfolders are not intended to represent packages, but are simply a way of imposing some structure on my systems source files. I find the PyCharm has no such problem with this structure; i.e., it's Intellisense equivalent operations work fine. I believe (but can't really confirm) that this is a "recent" problem; i.e., I don't recall seeing this with earlier versions of VS and/or PTVS. Is this a known problem? Is there a fix/workaround? It certainly makes the use of VS for Python dev less desirable. pminaev Coordinator May 14 at 4:13 PM If those folders do not represent subpackages, but are just separate parts under the global namespace, you need to add them to the Search Paths node in Solution Explorer, so that PTVS knows how to treat them. Zooba Coordinator May 14 at 4:14 PM Are you using Python 3.3 or 3.4? Maybe we have an issue with namespace packages... wlcohagan May 14 at 5:20 PM pminaev wrote: If those folders do not represent subpackages, but are just separate parts under the global namespace, you need to add them to the Search Paths node in Solution Explorer, so that PTVS knows how to treat them. Thanks for the suggestion. I added the folder to the Search Paths node, but it appears to have had no effect. The problems persist. (Yes, I did refresh the completion database. I also closed and reopened the solution.) Bill pminaev Coordinator May 14 at 5:29 PM The completion DB shouldn't really matter, since the code that's directly in your project (rather than a part of standard library or virtual env) is processed on the fly. Can you briefly sketch out the layout of your project? Say, taking one file for which you have completion issues, and another file that uses that first file, can you give the path of both files relative to project root, and what the import statement looks like? wlcohagan May 14 at 5:34 PM Zooba wrote: Are you using Python 3.3 or 3.4? Maybe we have an issue with namespace packages... 3.3 Zooba Coordinator May 14 at 5:48 PM Being 3.3 explains why your imports work even though you haven't explicitly made the folders packages - Python 3.3 will treat all folders with a matching name as a combined package unless it can find one that has an __init__.py. Apparently we don't support this correctly (a quick look at the code suggests "at all"...). I'll create an issue. Until it gets fixed, adding an __init__.py file is the easiest way to solve the issue, and it's very likely that it won't break your code unless you are deliberately making use of the namespace package functionality. Zooba Coordinator May 14 at 5:50 PM wlcohagan May 14 at 5:51 PM pminaev wrote: The completion DB shouldn't really matter, since the code that's directly in your project (rather than a part of standard library or virtual env) is processed on the fly. Can you briefly sketch out the layout of your project? Say, taking one file for which you have completion issues, and another file that uses that first file, can you give the path of both files relative to project root, and what the import statement looks like? I have a project folder, foo, containing the project file, foo.pyproj as well as the file foo_driver.py. There's a subfolder, foo\subfoo, containing bar.py and foo_driver.py imports the class bar_class from bar.py with: from subfoo.bar import bar_class The above line of code gets the green squiggly underline with the associated message "Unable to resolve subfoo.bar..."; however the import works fine at execution time. None of the expected Intellisense based operations work between foo_driver.py and subfoo\bar.py. wlcohagan May 14 at 5:52 PM Zooba wrote: Filed as https://pytools.codeplex.com/workitem/2356 Thanks! wlcohagan May 14 at 6:38 PM Zooba wrote: Being 3.3 explains why your imports work even though you haven't explicitly made the folders packages - Python 3.3 will treat all folders with a matching name as a combined package unless it can find one that has an __init__.py. Apparently we don't support this correctly (a quick look at the code suggests "at all"...). I'll create an issue. Until it gets fixed, adding an __init__.py file is the easiest way to solve the issue, and it's very likely that it won't break your code unless you are deliberately making use of the namespace package functionality. Adding init.py seems to have solved the problem for now. Thanks for the workaround! Bill