This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ADataGman
Recipients ADataGman, brett.cannon, docs@python, eric.snow, ncoghlan, terry.reedy
Date 2019-02-14.00:38:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAJnDJ=b48kAJT9aQ7viRokq1xA7quR7kajtwdzYNWXuaHTb4xg@mail.gmail.com>
In-reply-to <1550032536.55.0.41841593392.issue35927@roundup.psfhosted.org>
Content
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 <report@bugs.python.org>
wrote:

>
> Terry J. Reedy <tjreedy@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 <report@bugs.python.org>
> <https://bugs.python.org/issue35927>
> _______________________________________
>
History
Date User Action Args
2019-02-14 00:38:19ADataGmansetrecipients: + ADataGman, brett.cannon, terry.reedy, ncoghlan, docs@python, eric.snow
2019-02-14 00:38:19ADataGmanlinkissue35927 messages
2019-02-14 00:38:19ADataGmancreate