ADataGman <aarongross...@gmail.com> added the comment:
Terry, thank you for the detailed list of alternatives on how to approach this, that's helpful in how to tackle this issue in my current development. Nick, for the relative imports of relative imports I think the error message is fine. It makes sense. It doesn't necessarily give you a lot of hints on where to go next unfortunately, but it does explain why it doesn't work. For the absolute imports, a hint like, the module must be discoverable in sys.path or the like if you wanted to make this clearer. My biggest concern was just that the way the documentation is written for https://docs.python.org/3.6/tutorial/modules.html#intra-package-references . It implies that the code will run without any hint of needing to be either run from a higher level, or a work around used like Terry suggested. Now that I've spent a few days researching and reading more on my own, and with help from you and Terry, I understand what's happening and have options. But for others just reading the docs and not already familiar, it's not clear why the current example wouldn't work when run from the sibling level. I'd like to see the documentation for intra-package references updated to clearly state that the code is being run from a level above. "For example, if the module sound.filters.vocoder needs to use the echo module in the sound.effects package, it can use from sound.effects import echo." only works if you run it from the sound module. Which is fine! It's just not clear to a newb that it's being executed from the sound package rather than the filters package. Perhaps modify https://docs.python.org/3.6/tutorial/modules.html#packages to include a "sound.py" at the top level folder, and in the explanation for the intra-package reference, just mention that the example quoted above runs from that new file. If there is a optimal way to modify the path for adding in a sibling level package, please include that. Otherwise just clarify that the example relies on the code being run from something from another level up. On Tue, Feb 12, 2019 at 11:35 PM Terry J. Reedy <rep...@bugs.python.org> wrote: > > Terry J. Reedy <tjre...@udel.edu> added the comment: > > AData> You log and output show that you problem is as described: package > 'sound' is in directory "C:/" and "C:/" is not is sys.path. Possible > remedies: > 1. Add "C:/" to sys.path at the top of each module that imports sound. > This is a nuisance. > 2. Move the sound package to > 'C:\\Users\\user\\AppData\\Local\\Programs\\Python\\Python37\\lib\\site-packages'. > This can also a nuisance. > 3. Add a file named 'C.pth' and containing "C:/" to the site-packages. > ('pth' abbreviates 'path'.) This makes C:/ an extension of site-packages. > But all the non-python stuff in C: likely makes this a bad idea. > 4 (3 improved). Add a directory such as "C:/pyprojects", make the contents > of the .pth file "C:/pyprojects", and move sound to pyprojects. > This is what I have done. When I install a new version of Python, I copy > the .pth file to the new site-packeges directory. Works great. > > ---------- > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue35927> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35927> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
