Should the "test/packA/," in "2. Use absolute imports rooted at the test/ directory (i.e., middle column in the table above). This guarantees that running start.py directly will always work. In order to run a2.py directly, we can modify sys.path in a2.py to include test/packA/, before sa2 is imported." of https://chrisyeh96.github.io/2017/08/08/definitive-guide-python-imports.html#case-2-syspath-could-change be "test/" instead? Thank you.

First of all, this is a great take on the Cayman theme, thanks so much! I was wondering about spacing in the navbar -- I checked developer tools and there seems to be an empty element propagated between About and Projects. Alone, this is fine, but I'd like to add more sections (a coursework tab, etc.), but this puts emphasis on the empty element causing additional spacing. I think this stems from _includes/navbar.html. However, I've read through it a few times and can't figure out where its coming from. Any suggestions on removing this? Thanks!

Great guide! I enjoyed it and learned a lot. I have a question regarding relative imports. You mentioned that modules in parent directories couldn't be imported without messing with sys.path. I was wondering about unittest and if it's different? For example say I have a directory mod/ with module.py and a unit-test for that module, test_module.py, in mod/tests/, I should be able to import module in mod/tests/test_module.py and run python -m unittest tests/test_module.py even though it's importing from the parent directory, correct?

Hello,

First of all excuse me if this isn't the right place to post this, i didn't really know how to get in touch so I figured a Github issue would be the best way to do it.

I was reading your post regarding imports (https://chrisyeh96.github.io/2017/08/08/definitive-guide-python-imports.html), which I found instructive & well written, but there's a small point I think is wrong.

Here's the excerpt:

The Python documentation goes on to mention the following:

The directory containing the script being run is placed at the beginning of the search path, ahead of the standard library path. This means that scripts in that directory will be loaded instead of modules of the same name in the library directory.

This seems to be a mistake. For example, calling import math in start.py will import the standard math module, NOT my own math.py file in the same directory.

The documentation is correct: the described behavior applies to modules in the standard library directory. The math module is a builtin module (like the sys module), guaranteed to be always available, and thus not implemented as a separate Python file in the standard library.

If you name your own module argparse for example, it will indeed have precedence over the argparse module in the standard library.

Hope I was clear, and thanks again for your excellent post. Cheers !

https://chrisyeh96.github.io/2017/08/08/definitive-guide-python-imports.html#case-3-syspath-could-change-take-2

Folder structure:

.
├── packA
│   ├── a1.py
│   ├── a2.py
│   └── subA
│       └── sa2.py
└── start.py

start.py:

import packA.a2
print('start.py')

a1.py:

import packA.a2
print('a1.py')

a2.py:

import packA.subA.sa2
print('a2.py')

sa2.py:

print('sa2.py')

Result in the parent directory of packA and start.py:

> python start.py
sa2.py
a2.py
start.py

> python -m packA.a1
sa2.py
a2.py
a1.py

Python 3.7.7

Hi,

I was reading carefully your great post https://chrisyeh96.github.io/2017/08/08/definitive-guide-python-imports.html because I discovered in it insights that I was for long wanted to clarify.

I think that once the built-in modules are mention above in the post, the recap paragraph:

Let’s recap the order in which Python searches for modules to import:

1. modules in the Python Standard Library (e.g. math, os)
2. modules or packages in a directory specified by sys.path:
     1. If the Python interpreter is run interactively:
           - sys.path[0] is the empty string ''. This tells Python to search the current working directory from which you launched the interpreter, i.e. the output of pwd on Unix systems.

        If we run a script with python <script>.py:
          - sys.path[0] is the path to <script>.py
     2. directories in the PYTHONPATH environment variable
     3. default sys.path locations

could be expressed something like:

Let’s recap the order in which Python searches for modules to import:

1. modules built-in in the Python Standard Library (e.g. math, os)

2. modules or packages in a directory specified by sys.path:
     1. If the Python interpreter is run interactively:
           - sys.path[0] is the empty string ''. This tells Python to search the current working directory from which you launched the interpreter, i.e. the output of pwd on Unix systems.

        If we run a script with python <script>.py:
          - sys.path[0] is the path to <script>.py
     2. directories in the PYTHONPATH environment variable
     3. default sys.path locations.
        That is, rest of the modules in the Python Standard Library that are not built-in (e.g. random).
          - sys.path[1:], or sys.path[2:] on case PYTHONPATH environment variable exists.

Hope you find it helpful and thanks a lot for your clear and tidy post.

search_path should have been set to a list for the example to work. The current case gives the following error: ValueError: path must be None or list of paths to look for modules in.

Correct syntax should be:

search_path = ['.'] # set to None to see all modules importable from sys.path
all_modules = [x[1] for x in pkgutil.iter_modules(path=search_path)]

Hi Chris,
Sorry to message you in this way; I could not find another way.
I was trying to set up my own math blog via GitHub pages, however, the Math does not seem to render as easily as in your page. Thus, I copied your page about LQR to my blog, and tried to make it render the same way as your blog. It can be found here. I was wondering if you knew what was going wrong.
I do realize you probably have better things to do than to help me debug, but it was worth a shot.