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 librar
Frank Millman wrote:
>>
>> 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
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 is not uncommon for me to fi
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 needs to ac
>
> 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 with multiple
> instances of the same modul
"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
>import sys
>sys.path.insert(0, _
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
> Module A needs to acc
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 something in Module
13 matches
Mail list logo
