namespace collisions

[Jeremy Bowers]

I'm accumulating a number of small functions, which I have sensibly put
in a single file called 'util.py'. But it occurs to me that with such a
generic name it could cause problems with other modules not written by
myself. Whats the best way of handling this? If I put it in a common
location in my Python path, should I call it willsutil.py?

Yes, something like that would be best. Two modules with the same name can
cause problems because once one is imported, the other will never be;
'import' just returns the first out of the cache.

Looking on my system, I see 6 "utils.py" files; one in the xmlproc parser,
two in twisted, one in docutils, one in a program called "sgmltools", and
one in the xblproc parser in Jython, which I didn't even know I had
installed(!). While I don't think you should have a problem because those
are submodules (that is, you can't 'import utils', you have to 'import
docutils.utils' and that doesn't create a 'utils' module), I'd say that
in general, that's a scary enough name that you are likely to encounter
trouble later.

 

[Will McGugan]

Hi,

I'm accumulating a number of small functions, which I have sensibly put
in a single file called 'util.py'. But it occurs to me that with such a
generic name it could cause problems with other modules not written by
myself. Whats the best way of handling this? If I put it in a common
location in my Python path, should I call it willsutil.py?

TIA,

Will McGugan

 

[John Lenton]

Hi,

I'm accumulating a number of small functions, which I have sensibly put
in a single file called 'util.py'. But it occurs to me that with such a
generic name it could cause problems with other modules not written by
myself. Whats the best way of handling this? If I put it in a common
location in my Python path, should I call it willsutil.py?

local.util

is probably a convention worth starting

or you could go with

WilMcGugan.util

but ThatGetsOldFast.


--
John Lenton ([email protected]) -- Random fortune:
All my friends are getting married,
Yes, they're all growing old,
They're all staying home on the weekend,
They're all doing what they're told.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCFONYgPqu395ykGsRAvqbAJ4wiEJWQOaxBE0dLPvTgEK6vATJ6wCeOjSL
yBk5ZhTXd3RV4KP+8WghmV8=
=6DVB
-----END PGP SIGNATURE-----

 

[wes weston]

Hi,

I'm accumulating a number of small functions, which I have sensibly put
in a single file called 'util.py'. But it occurs to me that with such a
generic name it could cause problems with other modules not written by
myself. Whats the best way of handling this? If I put it in a common
location in my Python path, should I call it willsutil.py?

TIA,

Will McGugan

Will,
See http://www.boost.org/libs/python/doc/tutorial/doc/html/python/techniques.html

'about page 30 of google search. It gives an example
that should help.
wes

 

[Dave Benjamin]

I'm accumulating a number of small functions, which I have sensibly put
in a single file called 'util.py'. But it occurs to me that with such a
generic name it could cause problems with other modules not written by
myself. Whats the best way of handling this? If I put it in a common
location in my Python path, should I call it willsutil.py?

I find that it's beneficial in the long run to create a package for your
project. This will insure you against name collisions in general, should
you later need to combine projects::

import myproject.util
myproject.util.myhandyfunction()
etc.

The potential downside is that if you really need to reuse util.py in
multiple projects, you'll have to copy the file to each package, or
create a central package that the other projects' packages link to. But
it's been my experience that the type of stuff that goes in "util"
modules is pretty miscellaneous in nature, and not as reusable as it
seems. Not worth creating additional dependencies, anyway.

There's really no one right answer to your question, but I've been
(mildly) bitten by naming collisions, and as a result I use packages for
every project now.

Dave

 

[elbertlev]

local.util

is probably a convention worth starting

or you could go with

WilMcGugan.util

but ThatGetsOldFast.


--
John Lenton ([email protected]) -- Random fortune:
All my friends are getting married,
Yes, they're all growing old,
They're all staying home on the weekend,
They're all doing what they're told.

I call modules like x_utils.py, where prefix x is assigned to a
particular pakage. In this case import statements look like:

import Company.repotrtools.e_excel as e_excel

or

from Company.repotrtools.e_excel import e_writer, e_reader

generally this are classes, not functions.

Newer had namespace collisions (yet