As I understand it, "from __future__ import ..." statements are actually a special type of statement that doesn't actually import a module at all - they just use similar syntax for compatibility reasons. There is an actual __future__ module, also for compatibility reasons, but importing it has no side-effects.

Future statements do import something as well, when run, but their primary purpose is changing the behaviour of the compiler for the current file. They have no behaviour outside of that file, so that is not a publicly visible side-effect.

Whether they import a module or not is - IMO - irrelevant. I was responding to this claim: In Python, side-effects are simply not acceptable at all. One should instead put the code with the side-effect in a function and call it. `__future__` imports are obviously and purposefully side-effectful, there's no `print_function()`.

That's a side effect, right? Your module after the import is not the same as it was before, or am I missing something?

Future imports are not imports at all (the fact that they use the same syntax as imports is misleading IMO). They are tags that instruct the interpreter to turn on certain features only when interpreting the given file. They must appear before any statements in the file, and they take effect before interpretation of the file starts. You could argue that this constitutes an import side effect, but that's neither here nor there, and not helpful.

It only changes the behaviour for the current file, so it's not a side-effect.

That seems too narrow a view of side effect.

Which of the following are side effects?

1. Initializing a point of sale printer, checking for errors, and raising exceptions if, say, it is out of paper? Let's say this is a cash drawer driver and the cash drawer connects through the printer, and if the printer is out of paper, the drawer won't open properly (this happens btw). I would call this a side effect as well as a separation of concerns violation btw. However it is not likely to be a visible change to other modules.

2. Check for the presence of a binary and if found, cache the path to it, perhaps instantiating another object to do so? Definitely a side effect there, but not publicly visible.

3. Initializing an external library's environment (as happened in this case)? Done wrong it crashes the system but I suspect the segfault was not intended. Again it isnt clear to me you have a publically visible side effect intended.