views:

257

answers:

4

Hi,

Update: This is, as I was told, no principle Python related problem, but seems to be more specific. See below for more explanations to my problem.

I have a custom exception (let's call it CustomException), that lives in a file named exceptions.py. Now imagine, that I can import this file via two paths:

import application.exceptions

or

import some.application.exceptions

with the same result. Furthermore I have no control over which way the module is imported in other modules.

Now to show my problem: Assume that the function do_something comes from another module that imports exceptions.py in a way I don't know. If I do this:

import application.exceptions
try:
  do_something ()
except application.exceptions.CustomException:
  catch_me ()

it might work or not, depending on how the sub-module imported exceptions.py (which I do not know).

Question: Is there a way to circumvent this problem, i.e., a name for the exception that will always be understood regardless of inclusion path? If not, what would be best practices to avoid these name clashes?

Cheers,

Update

It is a Django app. some would be the name of the Django 'project', application the name of one Django app. My code with the try..except clause sits in another app, frontend, and lives there as a view in a file some/frontend/views.py.

The PYTHONPATH is clean, that is, from my project only /path/to/project is in the path. In the frontend/views.py I import the exceptions.py via import application.exceptions, which seems to work. (Now, in retrospective, I don't know exactly, why it works...)

The exception is raised in the exceptions.py file itself.

+1  A: 

Why that would be a problem? exception would me matched based on class type and it would be same however it is imported e.g.

import exceptions
l=[]
try:
    l[1]
except exceptions.IndexError,e:
    print e

try:
    l[1]
except IndexError,e:
    print e

both catch the same exception

you can even assign it to a new name, though not recommended usually

import os
os.myerror = exceptions.IndexError
try:
    l[1]
except os.myerror,e:
    print e
Anurag Uniyal
Hmm. In my specific setup (which is a Django app, but that should not matter) exactly that didn't work. The module raised some.application.exceptions.CustomException and I was not able to catch it with application.exceptions.CustomException.
Boldewyn
can you tell us more details? e.g. django model Exception are associated directly with model class so that can be tricky if not done right
Anurag Uniyal
This is a very important detail which should go into the question!
Aaron Digulla
A: 

Even if the same module is imported several times and in different ways, the CustomException class is still the same object, so it doesn't matter how you refer to it.

balpha
A: 

I don't know if there is a way to handle this inclusion path issue. My suggestion would be to use the 'as' keyword in your import

Something like:

import some.application.exceptions as my_exceptions

or

import application.exceptions as my_exceptions

luc
Python doesn't match on the name of the exception, so this will make no difference.
Lennart Regebro
+1  A: 

"If not, what would be best practices to avoid these name clashes?"

That depends entirely on why they happen. In a normal installation, you can not import from both application.exceptions and somepath.application.exceptions, unless the first case is a relative path from within the module somepath. And in that case Python will understand that the modules are the same, and you won't have a problem.

You are unclear on if you really have a problem or if it's theory. If you do have a problem, I'd guess that there is something fishy with your PYTHONPATH. Maybe both a directory and it's subdirectory is in the PATH?

Lennart Regebro
The dir and subdir are not both in PYTHONPATH, but my code, where I try to catch the exception, lives in the 'some' folder and imports via the relative path 'application.exception'. Could that be eth error cause?
Boldewyn
s/eth/the/ in the above
Boldewyn
No, that is unlikely to be an error cause. Your code should catch that exception no matter how it was imported. The error is most likely somewhere else.
Lennart Regebro