Question

Please consider the following Python modules excerpts:

foo.py:

class Foo:
  (...)

bar.py:

import foo

foo = foo.Foo()

The variable foo, which was a module object, is overwritten with a Foo object.

I know that I can use other names for the object, e.g.:

foobar = foo.Foo()

but semantically it makes more sense in my code to have it called foo, since it will be the only instance.

(I tried to workaround this by dropping classes and using modules only, but I went back to using classes because using modules only had "robustness" problems.)

This is kind of a philosophical question, but what is the "right" way of handling this potential object/module names clash?

Was it helpful?

Solution

In my opinion there is nothing wrong with what you are currently doing, but to make it more clear for everyone reading the code I would suggest changing your code to something like the following:

import foo as foo_mod

foo = foo_mod.Foo()

Or alternatively:

from foo import Foo

foo = Foo()

This prevents the name clash so it will be more obvious that the variable foo in your module is not going to refer to the module of the same name.

OTHER TIPS

I've also been favoring the following style nowadays:

import foo

my_foo = foo.Foo()

I prefer this because it keeps module names untouched, and those are are more global and sacred than local variables.

This pattern doesn't seem to bother peeps who use Flask + Celery,

from celery import Celery

def make_celery(app):
    celery = Celery(
        app.import_name,
        backend=app.config['CELERY_RESULT_BACKEND'],
        broker=app.config['CELERY_BROKER_URL']
    )
    ...

Obviously, the correct way to create an instance of this class is stalk = Celery() (hehe)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top