package module import name clash with global package

[George P]

aleaxit at yahoo.com (Alex Martelli) wrote in message news:<1gjx9y3.85025t5mpy3hN%aleaxit at yahoo.com>...
> George P <georgeplex at yahoo.com> wrote:
>    ...
> >    a) Not use os as my submodule name
> 
> Best.
> 
> > a) is not a perfect solution because, well, in my example I've used
> > "os" to illustrate the problem, but really, who's to predict what
> > global modules might be installed on a system? And besides, isn't this
> 
> As long as your package does not use global modulenames coinciding with
> the ones it contains, you're fine.  You don't need to predict anything:
> if your package needs global modules os, sys, and re, don't have modules
> named that way in your package.  Simple, innit?
> 
> 
> Alex

Not all that simple. Let's say I give my submodule some fairly generic
name like utils. I would think that was fine because my module is
really mypkg.utils. But then someone out in the rest of the python
universe creates a package called utils and that eventually becomes
standard and gets installed on all systems. Then if I wanted to access
it within my module, I would have a problem.

The problem is easily overcome in my code - all I'd have to do is to
rename my module to myutils or something, but if any other code has
been written that relied on my package and imported mypkg.util, they'd
suddenly stop working with the new release that has the module renamed
to mypkg.myutil.

I'm not saying that these aren't insurmountable problems, I'm just
looking for a better solution. In C++, I would be able to refer to the
global utils in my code as ::utils, and there would be no more
problems. Does anyone know of a similar workaround in python?

    George