Say “no” to import side‐effects in Python
chrismorgan.info
Say “no” to import side‐effects in Python
1–10 of 86 posts
Re: Say “no” to import side‐effects in Python
#2Agreed. Twisted's behaviour of installing a reactor on import has caused me problems which could be worked around by importing conditionally or at a later time, but in cases like this, where one is importing modules dynamically, one doesn't know ahead of time which workarounds one needs.
Re: Say “no” to import side‐effects in Python
#3Of course you should do this in any language. I once used a Ruby library that, when loaded, would try to connect to a database on a remote machine. Programs which required this library would take several seconds to display their --help output.
Because of that and similar incidents, I've learned to import argparse up front but nothing else unless necessary. Once argument parsing is done, then importing other modules begins.
Re: Say “no” to import side‐effects in Python
#4Agreed. Twisted's behaviour of installing a reactor on import has caused me problems which could be worked around by importing conditionally or at a later time, but in cases like this, where one is importing modules dynamically, one doesn't know ahead of time which workarounds one needs.
Twisted's problem is the good old singleton (anti-)pattern. There can only be one reactor ever, and most galling of all, it can never be restarted once stopped.
Re: Say “no” to import side‐effects in Python
#5This in no way invalidates the point of the post, but I can't imagine going back to installing everything globally instead of using virtualenv. If you do that, at least you won't have every package you every looked at in your path.
Re: Say “no” to import side‐effects in Python
#6It's also worth stressing that even if import side-effects are always going to be fast and not kill the interpreter, they are still a terrible idea.
Even spawning objects that are referenced in modules can have some rather unpleasant properties. The __del__ method will likely never get reliably called and other behaviours that work great in scripts break in subtle ways, especially with a KeyboardInterrupt. Threading and multiprocessing will leave processes running using 100% cpu. Trying to debug these things gets insane, as you can often only find them as the interpreter is dying.
I think import side-effects can be tempting because Python is often introduced using a scripting-oriented approach. Combined with Python following the principle of least surprise, most people doing this won't even realise that it's wrong. This does seem to be a rather common anti-pattern.
Re: Say “no” to import side‐effects in Python
#7Can anyone suggest best practice alternatives to import side-effects?
Re: Say “no” to import side‐effects in Python
#8Can anyone suggest best practice alternatives to import side-effects?
Just don't run code in the root of your modules except in the entry point(s) of your program. In the modules, only declare.
Re: Say “no” to import side‐effects in Python
#9Qt and Gtk seem to be the problem here, and they won't change. They aren't python modules as much as they are application frameworks and assume to be in full control. Gtk calls sys.setdefaultencoding("utf-8") when imported, changing the way your strings behave in the whole process.
Re: Say “no” to import side‐effects in Python
#10Of course you should do this in any language. I once used a Ruby library that, when loaded, would try to connect to a database on a remote machine. Programs which required this library would take several seconds to display their --help output. Because of that and similar incidents, I've learned to import argparse up front but nothing else unless necessary. Once argument parsing is done, then importing other modules b…
> I once used a Ruby library that, when loaded, would try to connect to a database on a remote machine.
How is that at all acceptable? I can't believe that a library that phones home would gain any sort of popularity.
I can't say I know much of anything about the Ruby community, but if they've conditioned you to jump through hoops like importing modules at specific times to avoid delays, that is a serious problem. Conditional/delayed imports have their place, but they should be relatively rare.