al*****@yahoo.com (Alex Martelli) wrote in message news:<1gjx9y3.85025t5mpy3hN%al*****@yahoo.com>...
George P <ge********@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