Re: resolving module name conflicts. (pytz version 2010b)

2011-11-11 Thread Gelonida N
On 11/12/2011 01:42 AM, Steven D'Aprano wrote: > On Fri, 11 Nov 2011 23:11:38 +0100, Gelonida N wrote: > >> Pytz is only imported by one module, so I wondered if there were any >> tricks to 'change sys.path' prior to importing pytz > > sys.path is just a list of paths. You can import the sys modu

Re: resolving module name conflicts.

2011-11-11 Thread Steven D'Aprano
On Fri, 11 Nov 2011 23:11:38 +0100, Gelonida N wrote: > Pytz is only imported by one module, so I wondered if there were any > tricks to 'change sys.path' prior to importing pytz sys.path is just a list of paths. You can import the sys module and manipulate it any way you like. -- Steven --

Re: resolving module name conflicts.

2011-11-11 Thread Gelonida N
On 11/11/2011 10:51 PM, Eric Snow wrote: > On Fri, Nov 11, 2011 at 2:34 PM, Eric Snow > wrote: > > So if you run a module as a script, that empty string will be added to > sys.path and all imports will first check the directory you were in > when you ran Python... > Yes that's normal (and for

Re: resolving module name conflicts.

2011-11-11 Thread Gelonida N
On 11/11/2011 10:31 PM, Emile van Sebille wrote: > On 11/11/2011 12:27 PM Gelonida N said... >> Is there any way to tell pytz to import it's own tests package and tell >> the rest of the code to import the other? >> >> Python version is 2.6.5 >> >> >> Thanks in advance for any suggestion. > > Star

Re: resolving module name conflicts.

2011-11-11 Thread Eric Snow
On Fri, Nov 11, 2011 at 2:34 PM, Eric Snow wrote: > The problem is that the empty string is still added to the from of > sys.path.  I'm going to have to find out more about that one. Okay, don't know how I missed it but the docs for sys.path[1] spell it out: "As initialized upon program star

Re: resolving module name conflicts.

2011-11-11 Thread Eric Snow
On Fri, Nov 11, 2011 at 1:27 PM, Gelonida N wrote: > > > Hi, > > I got some code. > - This code contains a package named tests > - there are at least 100 references in different python files >        importing from above mentioned tests package. > - the code also imports pytz at one place > > I ge

Re: resolving module name conflicts.

2011-11-11 Thread Emile van Sebille
On 11/11/2011 12:27 PM Gelonida N said... Hi, I got some code. - This code contains a package named tests - there are at least 100 references in different python files importing from above mentioned tests package. - the code also imports pytz at one place I get following warning messa

resolving module name conflicts.

2011-11-11 Thread Gelonida N
Hi, I got some code. - This code contains a package named tests - there are at least 100 references in different python files importing from above mentioned tests package. - the code also imports pytz at one place I get following warning message: /usr/lib/python2.6/dist-packages/pytz/_

Re: Module Name Conflicts

2005-08-21 Thread ncf
Heh, so long as it works. Sorry for the delay, I've been away for a bit ;P Hope it's all owrking out -Wes -- http://mail.python.org/mailman/listinfo/python-list

Re: Module Name Conflicts

2005-08-19 Thread Rocco Moretti
[EMAIL PROTECTED] wrote: > I have a java program in a package called 'cmd'. This of course > conflicts with the builtin python package of the same name. The thing > is, I need to be able to import from both of these packages in the same > script. I can import either one first, but any future attemp

Re: Module Name Conflicts

2005-08-18 Thread Bengt Richter
On Thu, 18 Aug 2005 16:46:42 -0700, Robert Kern <[EMAIL PROTECTED]> wrote: >Dan Sommers wrote: > >> Assuming you can fiddle with sys.path at the right times, you can call >> an imported module anything you want: >> >> fix_sys_path_to_find_java_cmd_first() >> import cmd as java_cmd >>

Re: Module Name Conflicts

2005-08-18 Thread Robert Kern
[EMAIL PROTECTED] wrote: > Robert Kern wrote: > >>Why not copy cmd.py into your package under a different name? > > It offends my sense of modularity. For the record, I'm trying to use > pdb, the debugger, which in turn uses cmd. So it would be a matter of > taking pdb.py and hacking it to import

Re: Module Name Conflicts

2005-08-18 Thread Dan Sommers
On Thu, 18 Aug 2005 16:46:42 -0700, Robert Kern <[EMAIL PROTECTED]> wrote: > Dan Sommers wrote: [ something that obviously doesn't work ] > That doesn't work. The first module is recorded as 'cmd' in > sys.modules and gets reused on the second import. Yes, you're right. I apologize. Regards,

Re: Module Name Conflicts

2005-08-18 Thread torched_smurf
ncf wrote: > Maybe what you're looking for is __import__()? Okay, actually this does work, but only in one direction. That is, I can import the python package first, and then the java package, but not the other way around. -- Importing t

Re: Module Name Conflicts

2005-08-18 Thread ncf
I'm honestly not too sure how __import__ works, but I know you can provide a full path to it. Oh well, that was my best guess. I wish I could've been of more help. -Wes -- http://mail.python.org/mailman/listinfo/python-list

Re: Module Name Conflicts

2005-08-18 Thread Peter Hansen
[EMAIL PROTECTED] wrote: > Robert Kern wrote: >>That doesn't work. The first module is recorded as 'cmd' in sys.modules >>and gets reused on the second import. > > Exactly. And clearing sys.modules doesn't fix the problem. Once it's > imported something from the first cmd package, it can no longer

Re: Module Name Conflicts

2005-08-18 Thread torched_smurf
Robert Kern wrote: > Why not copy cmd.py into your package under a different name? > It offends my sense of modularity. For the record, I'm trying to use pdb, the debugger, which in turn uses cmd. So it would be a matter of taking pdb.py and hacking it to import a renamed version of cmd... kind of

Re: Module Name Conflicts

2005-08-18 Thread torched_smurf
ncf wrote: > Maybe what you're looking for is __import__()? > > >>> help(__import__) > Help on built-in function __import__ in module __builtin__: > > __import__(...) > __import__(name, globals, locals, fromlist) -> module > > Import a module. The globals are only used to determine the > c

Re: Module Name Conflicts

2005-08-18 Thread Robert Kern
[EMAIL PROTECTED] wrote: > I have a java program in a package called 'cmd'. This of course > conflicts with the builtin python package of the same name. The thing > is, I need to be able to import from both of these packages in the same > script. I can import either one first, but any future attemp

Re: Module Name Conflicts

2005-08-18 Thread torched_smurf
Robert Kern wrote: > Dan Sommers wrote: > > > Assuming you can fiddle with sys.path at the right times, you can call > > an imported module anything you want: > > > > fix_sys_path_to_find_java_cmd_first() > > import cmd as java_cmd > > fix_sys_path_to_find_python_cmd_first() > > imp

Re: Module Name Conflicts

2005-08-18 Thread Robert Kern
Dan Sommers wrote: > Assuming you can fiddle with sys.path at the right times, you can call > an imported module anything you want: > > fix_sys_path_to_find_java_cmd_first() > import cmd as java_cmd > fix_sys_path_to_find_python_cmd_first() > import cmd as python_cmd > > Obviousl

Re: Module Name Conflicts

2005-08-18 Thread Dan Sommers
On 18 Aug 2005 16:06:46 -0700, [EMAIL PROTECTED] wrote: > I have a java program in a package called 'cmd'. This of course > conflicts with the builtin python package of the same name. The thing > is, I need to be able to import from both of these packages in the same > script. I can import either

Re: Module Name Conflicts

2005-08-18 Thread ncf
Maybe what you're looking for is __import__()? >>> help(__import__) Help on built-in function __import__ in module __builtin__: __import__(...) __import__(name, globals, locals, fromlist) -> module Import a module. The globals are only used to determine the context; they are not mod

Module Name Conflicts

2005-08-18 Thread torched_smurf
I have a java program in a package called 'cmd'. This of course conflicts with the builtin python package of the same name. The thing is, I need to be able to import from both of these packages in the same script. I can import either one first, but any future attempt to import from cmd.* will look