I am running Windows 7 and Python 3.6.2 trying to import module A from withing module B where both Module A and B are located in the same directory. I get the ModuleNotFoundError. I try the exact same setup with Python 3.5.2 and get no errors and I get the expected behavior.

For more details about the exact process I went through and everything I tried, see the StackOverflow post I made about it here: https://stackoverflow.com/questions/45336678/python-3-import-module-not-working-according-to-docs?noredirect=1#comment77637921_45336678

I've tested this on Python 3.6.1 and Python 3.6.2 on Windows 7, 64-bit, and it works as expected. I don't see the problem here - do you have any unusual environment settings or config?

I also can't reproduce on Python 3.6 on Windows 10, so I'm closing this.

Looking at your SO question I noticed you didn't specify `python3` but `python` which suggests a venv, so I'm wondering if that's mucking with things? You also don't need to add __init__.py as long as you're executing within the directory (which it seems you are based on how you explained things). Basically you should be able to print out sys.path and see if the directory containing your code is listed there. If it isn't then something wonky is going on with your environment.

But if you are executing the code from outside the directory then do realize that Python 3 no longer supports implicit relative imports so module_a won't be picked up in a package context (that would require `from . import module_a`).

I will mark the question appropriately as python3. I don't fully understand your comment about venv. If you mean virtual environment or something, that is not the case.

I am running an a standard Windows 7 install with Python3 as the only Python install on my path (I used the embedded zip package).

I did print sys.path and got the value of "WorkingDir" which is what I expected. I am running Python 3 from within "WorkingDir" and only trying to import a module that is within "WorkingDir".

OK, so the problem is that no-one here (or as far as I can see on the SO discussion, either) can reproduce your issue. So we have to assume that it's something wrong with your environment, and not a Python issue.

If you can produce an example that allows us to reproduce the issue, then we'll be able to comment further, but as things stand there's no evidence that it's a Python problem.

I understand your comments. I will be at computer that has not ever had Python installed in about an hour and will try it there to see if I can produce an example showing the issue. I just found it weird that Python 3.5.2 worked just fine in the same environment using exactly the same steps with only the system path environment variable changed. That is why I filed this issue.

I will report back.

The embeddable ZIP is not an "install" - it's a tool for including in your own application.

Run the actual installer and try again, or use the package on nuget.org if you need to achieve zero system impact (which it sounds like you don't if you're modifying PATH).

I have tried from 3 computers now and have been able to reproduce the issue with the same set of files described in my stackoverflow post. Here is a .zip package with all of the files I used in all 3 tests. The python package is the Windows 32bit embedded zip package downloaded from the Python site.

https://drive.google.com/file/d/0B0tT3_X-iMNzY2VMTkQ4X04zNWM/view?usp=sharing

I run the test.bat file and get the import error.

OK, so this is the first time (I believe) you have mentioned that you are using the embedded distribution - which is not designed for general scripting use, but very specifically for embedding Python in a custom application.

Can you reproduce with the standard installer?

I don't see any obvious reason why the embedded distribution would be different in this regard, but I'll give it a try when I can. BTW, please can you upload your testcase here? I don't have access to Google Drive on this PC (firewall limitations) so I'll need you to do that before I can access it.

Hmm, never mind. This is expected behaviour because the embedded distribution includes a ".pth" file which overrides the standard sys.path. For details, see https://docs.python.org/3.6/using/windows.html#finding-modules and https://docs.python.org/3.6/using/windows.html#embedded-distribution

Once again, please understand that the embedded distribution is *not* intended as a "portable version" of Python. It's a specialised distribution for a particular purpose.

If you want a "copy and use" version of Python, I believe there's one available via nuget, but it's not supported by the Python core devs, and I don't have any details for you, other than this.

So to confirm, Python is working as documented and there's no bug here.

Steve Dower, I understand the purpose of the embedded package. The test was also tried by calling the python executable without modifying the path and the same thing happens.

i.e. %~dp0\Python_Embedded_Windows_32bit_v3.6.2\python main.py

in the zip package I provided.

I'm not Steve, but thanks for the compliment :-)

You're still running an embedded Python. There's a _python36.pth file next to the executable, that's causing the behaviour you're seeing (and it's there by design - it's what makes the embedded distribution behave the way it does).

Unless you can reproduce with the standard distribution, this isn't a bug.

Ok I have downloaded an installed via the Windows installer and the test I run works as expected. I also tried the embedded package without the ._pth and it also works according to the embedded documentation. Sorry for the confusion as I did not specify the embedded package from what I can tell. Thank you all for working with me on resolving this.

No problem - glad it's all clear now.