OKB (not okblacke) wrote:
Anyway, testing this just reinforced my distaste for circular
imports. Just trying to think about how it ought to work with a
importing c but then c and d importing each other makes my brain hurt.
Refactoring the files so that common code is in a separate
'module' object has no attribute 'c'
>
> I get the same if I try 'import b.c as c'.
Interesting, you're right. Note that it will work in c.py but not
in d.py
Anyway, testing this just reinforced my distaste for circular
imports. Just tr
On Mon, Feb 27, 2012 at 6:01 PM, Terry Reedy wrote:
> On 2/27/2012 1:16 AM, Frank Millman wrote:
>>>
>>>
>>> To avoid the tedious reference, follow this with
>>> read = sound.formats.wavread # choose the identifier you prefer
>
>
> I tested something like this with stdlib, but there must be some i
On 2/27/2012 1:16 AM, Frank Millman wrote:
To avoid the tedious reference, follow this with
read = sound.formats.wavread # choose the identifier you prefer
I tested something like this with stdlib, but there must be some
important difference I did not notice. It make be in the contents of
__
On Sun, Feb 26, 2012 at 3:42 AM, Frank Millman wrote:
> Hi all
>
> I seem to have a recurring battle with circular imports, and I am trying to
> nail it once and for all.
>
> Let me say at the outset that I don't think I can get rid of circular
> imports altogether. It
Frank Millman wrote:
Hi all
I seem to have a recurring battle with circular imports, and I am trying to
nail it once and for all.
Let me say at the outset that I don't think I can get rid of circular
imports altogether. It is not uncommon for me to find that a method in
Module A nee
>
> To avoid the tedious reference, follow this with
> read = sound.formats.wavread # choose the identifier you prefer
>
@Terry and OKB
I tried that, but it does not work.
a.py
/b
__init__.py
c.py
d.py
a.py -
from b import c
c.py -
import b.d
d.py -
import b.c
If I run a
On 2/26/2012 6:12 AM, Peter Otten wrote:
Frank Millman wrote:
I seem to have a recurring battle with circular imports, and I am trying
to nail it once and for all.
...
This should be
import sound.formats.wavread
To avoid the tedious reference, follow this with
read = sound.formats.wavread
Frank Millman wrote:
> The first solution is -
>
> in wavread.py -
> import formats.wavwrite
>
> in wavwrite.py -
> import formats.wavread
>
> I then have to use the full path to reference any attribute inside
> the imported module, which I find cumbersome.
This isn't really tr
"Peter Otten" <__pete...@web.de> wrote in message
news:jid424$vfp$1...@dough.gmane.org...
> Frank Millman wrote:
>
>
> To cut a long story short, why should circular imports be unavoidable?
>
> Paths into packages are recipe for desaster. You may end up wit
"Frank Millman" wrote in message
news:jid2a9$n21$1...@dough.gmane.org...
> Hi all
>
> I seem to have a recurring battle with circular imports, and I am trying
> to nail it once and for all.
>
[...]
>
> The second solution is -
>
> in formats/__init__.py
&
Frank Millman wrote:
> I seem to have a recurring battle with circular imports, and I am trying
> to nail it once and for all.
>
> Let me say at the outset that I don't think I can get rid of circular
> imports altogether. It is not uncommon for me to find that a method in
Hi all
I seem to have a recurring battle with circular imports, and I am trying to
nail it once and for all.
Let me say at the outset that I don't think I can get rid of circular
imports altogether. It is not uncommon for me to find that a method in
Module A needs to access somethi
7;import' statements in the main
module, and it worked.
Then I found the need for some modules to refer to objects in other modules,
so I needed 'import' statements within the modules. I found myself hitting
problems with circular imports from time to time, but with some help
Thank you for your answer Frank, I think I've found the problem. I was
calling modules from inside subpackages, and I need to use them from
outside, so I have package in PYTHONPATH. is that correct? But now I have
another question: Can I execute an script inside subpackage1 importig
modules from su
On February 28 2011 Rafael Durán Castañeda wrote
I'm stil totally stuck with relative imports, i' ve tried the example tree
from PEP 328 without any result:
package/
__init__.py
subpackage1/
__init__.py
moduleX.py
moduleY.py
subpackage2/
__init__.py
I'm stil totally stuck with relative imports, i' ve tried the example tree
from PEP 328 without any result:
package/
__init__.py
subpackage1/
__init__.py
moduleX.py
moduleY.py
subpackage2/
__init__.py
moduleZ.py
moduleA.py
Assuming that the
"Steven D'Aprano" wrote in message
news:4d6a56aa$0$29972$c3e8da3$54964...@news.astraweb.com...
On Sun, 27 Feb 2011 12:08:12 +0200, Frank Millman wrote:
Assume the following structure -
main.py
/pkg
__init__.py
mod1.py
mod2.py
main.py
from pkg import mod1
mod1.py
import
On Sun, 27 Feb 2011 12:08:12 +0200, Frank Millman wrote:
> Assume the following structure -
>
> main.py
> /pkg
> __init__.py
> mod1.py
> mod2.py
>
> main.py
> from pkg import mod1
>
> mod1.py
> import mod2
>
> mod2.py
> import mod1
If you change the "import mod*" lines
suggests
that you are one of those who recommend that circular imports are best
avoided altogether. In an ideal world I would agree. However, the fact is
that, no doubt due to a mental block I have, I do find myself in this
situation from time to time, and I have not seen anything in the
documenta
"Frank Millman" writes:
> Assume the following structure -
>
> main.py
> /pkg
>__init__.py
>mod1.py
>mod2.py
>
> main.py
>from pkg import mod1
>
> mod1.py
>import mod2
>
> mod2.py
> import mod1
What are you expecting the result to be?
If it's about sharing objects between t
Hi all
I thought I was getting the hang of circular imports, but after upgrading to
python 3.2 I am stumped again. I know some people think that circular
imports are always bad, but others suggest that, provided you understand the
potential problems, they can be acceptable.
Assume the
All right, thank you for helping! I'd had a little voice in the back
of my mind nagging me that it might not be logical to include a bunch
of classes and function definitions in my startup file, but I never
got around to splitting it up. The module/script distinction makes
sense, and it seems more
On Sep 6, 4:44 pm, Dave Angel wrote:
> On 2:59 PM, Carl Banks wrote:> On Sep 5, 5:07 pm, Dave Angel
> wrote:
> >> On 2:59 PM, Carl Banks wrote:
> >>> All of this gets a lot more complicated when packages are involved.
> >> Perhaps a better answer would be to import __main__ from the second modul
On 2:59 PM, Carl Banks wrote:
On Sep 5, 5:07 pm, Dave Angel wrote:
On 2:59 PM, Carl Banks wrote:
All of this gets a lot more complicated when packages are involved.
Perhaps a better answer would be to import __main__ from the second module.
Then what if the module is imported from a differ
? It'll
try to import __main__ but get a different script than expected.
> But to my way of thinking, the answer should be to avoid ever having
> circular imports. This is just the most blatant of the problems that
> circular imports can cause.
>
> I don't know of a
his gets a lot more complicated when packages are involved.
Carl Banks
Perhaps a better answer would be to import __main__ from the second module.
But to my way of thinking, the answer should be to avoid ever having
circular imports. This is just the most blatant of the problems that
circu
On Sep 5, 1:19 pm, Spencer Pearson wrote:
> Hi! I'm writing a package with several files in it, and I've found
> that "isinstance" doesn't work the way I expect under certain
> circumstances.
>
> Short example: here are two files.
> # fileone.py
> import filetwo
>
> class AClass( object ):
> pas
Spencer Pearson writes:
> Hi! I'm writing a package with several files in it, and I've found
> that "isinstance" doesn't work the way I expect under certain
> circumstances.
>
> Short example: here are two files.
> # fileone.py
> import filetwo
>
> class AClass( object ):
> pass
>
> if __name__
Hi! I'm writing a package with several files in it, and I've found
that "isinstance" doesn't work the way I expect under certain
circumstances.
Short example: here are two files.
# fileone.py
import filetwo
class AClass( object ):
pass
if __name__ == '__main__':
a = AClass()
filetwo.is_acl
"Frank Millman" wrote in message
news:i3ov9e$du...@dough.gmane.org...
Hi all
I know the problems related to circular imports, and I know some of the
techniques to get around them. However, I find that I bump my head into
them from time to time, which means, I guess, that I have
g from Module B, ditto for B and C, and ditto for C and A.
There are a number of ways to avoid circular imports, in order of my own
preference:
1. Make common stuff a new module. So if A needs something from B, and
vice versa, you must factor out the stuff and stick it in its own
module. The fact
g from Module B, ditto for B and C, and ditto for C and A.
There's a dozen reasons why circular imports can go wrong. Can you
describe the problem you're having getting them to work? If there's a
traceback when you try to do it, cut-and-paste the traceback and
relevant code he
Frank Millman wrote:
Hi all
I know the problems related to circular imports...
>
It has just happened again. I have organised my code into three modules,
each representing a fairly cohesive functional area of the overall
application. However, there really are times when Module A wants
Hi all
I know the problems related to circular imports, and I know some of the
techniques to get around them. However, I find that I bump my head into them
from time to time, which means, I guess, that I have not fully understood
how to organise my code so that I avoid them in the first place
On Tuesday 29 May 2007 00:08, Carsten Haese wrote:
> On Mon, 28 May 2007 23:46:00 -0400, Ron Provost
> wrote
>
> > [...] python is not happy about my circular
> > imports [...]
>
> A circular import is not a problem in itself.
> I'm guessing you're running
On Mon, 28 May 2007 23:46:00 -0400, Ron Provost wrote
> [...] python is not happy about my circular imports [...]
A circular import is not a problem in itself. I'm guessing you're running into
a situation like this:
Module A imports module B and then defines an important class. Mod
et it working. However, because of
all these dependancies, python is not happy about my circular imports. Is
there any way to force python to accept these imports for now? the only
solution I've come up with myself would be to combine all the files into one.
This isn't really possible
[EMAIL PROTECTED] wrote:
> I'm working with a large code base that I'm slowly trying to fix
> "unpythonic" features of.
[...]
> Insead I'd rather have PYTHONPATH already include '/general/path/'
> and then just use:
One option you might not have considered, which I find more "pythonic"
than envir
be discarded. This currently only undoes the sys.modules change.
Now, with circular imports, you get
create module aaa.z2
add aaa.z2 to sys.modules
run aaa.z2
from aaa import z1
is "aaa.z1" already in sys.modules? no - load it
create aaa.z1
add aaa.z1 to sys.modules
run aaa
All of the __init__.py files are empty and I don't know of any
overlapping of names. Like I said this is code that works fine, I'm
just trying to clean up some things as I go. Here are my working
examples:
x1.py
==
# how things work in our code now:
# called with home/dlee/test/module python
[EMAIL PROTECTED] wrote:
> So I thought I'd just add the necessary __init__.py files and then
> things would just work. Unfortunately trying this exposed a large
> number of circular imports which now cause the files to fail to load.
You didn't describe you you created the ne
I'd rather have PYTHONPATH already include '/general/path/'
and then just use:
# how I'd like them to be
from aaa.bbb import foo
So I thought I'd just add the necessary __init__.py files and then
things would just work. Unfortunately trying this exposed a large
number o
43 matches
Mail list logo
