On Sat, Aug 21, 2021 at 3:35 PM Dan Stromberg wrote:
> On Tue, Aug 17, 2021 at 11:20 AM Chris Angelico wrote:
>
>> The main advantage of ast.parse() is that it no longer cares about
>> code layout, and it won't be fooled by an import statement inside a
>> docstring, or anything like that. It's a
On Tue, Aug 17, 2021 at 11:20 AM Chris Angelico wrote:
> The main advantage of ast.parse() is that it no longer cares about
> code layout, and it won't be fooled by an import statement inside a
> docstring, or anything like that. It's also pretty easy to handle
> multiple variants (note how "impo
On Wed, Aug 18, 2021 at 4:10 AM Barry Scott wrote:
>
> def allImports( self, module_name ):
> for line in f:
> words = line.strip().split()
> if words[0:1] == ['import']:
> all_imports.append( words[1] )
>
This will work for a lo
On Monday, 16 August 2021 16:13:47 BST Dan Stromberg wrote:
> Hi folks.
>
> I'm working on a large codebase that has at least one cyclic import.
>
> In case I end up needing to eliminate the cyclic imports, is there any sort
> of tool that will generate an import graph and
Hi folks.
I'm working on a large codebase that has at least one cyclic import.
In case I end up needing to eliminate the cyclic imports, is there any sort
of tool that will generate an import graph and output Just the cycles?
I tried pyreverse, but it produced too big a graph to be very u
On 05Jul2013 10:36, Oscar Benjamin wrote:
| On 5 July 2013 02:24, Cameron Simpson wrote:
| > On 04Jul2013 16:03, Oscar Benjamin wrote:
| > | Is there some reason you're responding to a post from 5 years ago?
| >
| > Is there some reason not to, if no newer solutions are available?
|
| No, I was
On 5 July 2013 02:24, Cameron Simpson wrote:
> On 04Jul2013 16:03, Oscar Benjamin wrote:
> |
> | Is there some reason you're responding to a post from 5 years ago?
>
> Is there some reason not to, if no newer solutions are available?
No, I was genuinely curious. My way of accessing this
forum/ne
On 04Jul2013 16:03, Oscar Benjamin wrote:
| On 4 July 2013 13:48, wrote:
| > On Tuesday, April 8, 2008 10:06:46 PM UTC+2, Torsten Bronger wrote:
| >
http://stackoverflow.com/questions/744373/circular-or-cyclic-imports-in-python
|
| Is there some reason you're responding to a post f
requires the other module to already be compiled (so that the
name we are importing exists) before it can be compiled.
from
http://stackoverflow.com/questions/744373/circular-or-cyclic-imports-in-python
Is there some reason you're responding to a post from 5 years ago?
Or is it ju
gt; import xyz". Because now each module requires the other module to already
> > be compiled (so that the name we are importing exists) before it can be
> > compiled.
>
> >
>
> > from
>
> > http://stackoverflow.com/questions/744373/circular-or-cycli
e it can be compiled.
>
> from
> http://stackoverflow.com/questions/744373/circular-or-cyclic-imports-in-python
Is there some reason you're responding to a post from 5 years ago?
Or is it just a joke that you've created a cyclic import advice link
by referring to a SO question w
make everything more manageable.
But at the moment I don't see how to avoid cyclic imports: A
document element A, which is represented my module parser.A, may
contain the element B, as defined in parser.B. And vice versa. So
both modules must import each other, as far as I can see.
I know
>
> But at the moment I don't see how to avoid cyclic imports: A
> document element A, which is represented my module parser.A, may
> contain the element B, as defined in parser.B. And vice versa. So
> both modules must import each other, as far as I can see.
>
> I know
> In code that runs after the module has been imported (basically
> anything defined in a function that isn't called by code that runs at
> module time), you can expect the variables defined in the imported
> module to be available.
>
> If you have circular imports involved, making sure the modules
On Jun 27, 12:58 am, James <[EMAIL PROTECTED]> wrote:
> > # a.py
> > import b
> > # refer to b.b
>
> > # b.py
> > import a
> > # refer to a.a
>
> Thanks Dan, but that still doesn't work for me I'm afraid...
>
> I renamed the modules avoid name overloading -- a.py is now:
> import b
>
> class A():
>
Hallöchen!
James writes:
>> # a.py
>> import b
>> # refer to b.b
>>
>> # b.py
>> import a
>> # refer to a.a
>
> Thanks Dan, but that still doesn't work for me I'm afraid...
>
> I renamed the modules avoid name overloading -- a.py is now:
> import b
>
> class A():
> print('b.b_mod:', b.b_mod)
> # a.py
> import b
> # refer to b.b
>
> # b.py
> import a
> # refer to a.a
Thanks Dan, but that still doesn't work for me I'm afraid...
I renamed the modules avoid name overloading -- a.py is now:
import b
class A():
print('b.b_mod:', b.b_mod)
b is now defined, but b.b_mod isn't:
File "m
On Jun 26, 10:40 pm, James <[EMAIL PROTECTED]> wrote:
> Hi all,
> I'm looking for some advice dealing with cyclic, cross-package
> imports.
>
> I've created the following demo file structure:
> ./a/__init__.py
> ./a/a.py
> ./b/__init__.py
> ./b/b.py
> ./main.py
>
> a.py imports a class from b.py an
Hi all,
I'm looking for some advice dealing with cyclic, cross-package
imports.
I've created the following demo file structure:
./a/__init__.py
./a/a.py
./b/__init__.py
./b/b.py
./main.py
a.py imports a class from b.py and vice versa, and main.py imports
them both.
However, because a.py has not
ode in the module. It does not
return control to the calling module until the execution has completed.
If a module does exist in sys.modules then an import simply returns that
module whether or not it has completed executing. That is the reason why
cyclic imports may return modules which appear
Hallöchen!
Jeffrey Froman writes:
> [...]
>
> Cyclic imports are not a problem by themselves, but cyclic
> definitions are. Thus:
>
> # a.py
> import b
> x = 1
>
> # b.py
> import a
> x = 2
>
> works fine
Torsten Bronger wrote:
> I know that cyclic imports work in Python under certain
> circumstances. Can anyone refer me to a page which explains when
> this works?
I don't know of a specific URL offhand.
Cyclic imports are not a problem by themselves, but cyclic definit
Hallöchen!
I have a rather fat module that represents a document parser --
inline elements, block elements, and the like. Now I want to split
it into many modules to make everything more manageable.
But at the moment I don't see how to avoid cyclic imports: A
document element A, whi
b1/one.py
web2/two.py
there doesn't seem to be any way to make one.py and two.py reference
each other via (non-delayed) imports.
It's interesting, though, that cyclic imports work when using the plain
"import foo" import, but not with the "from package import foo" sty
Matthias Kramm wrote:
> I'm having a little bit of trouble using the "imp" module to
> dynamically import modules. It seems that somehow cyclic
> references of modules don't work.
the problem you're seeing appears also if you use "import web.one"
or "from web import one" or "__import__('web.one')
Hi All,
I'm having a little bit of trouble using the "imp" module to
dynamically import modules. It seems that somehow cyclic references of
modules don't work.
I'm unable to get the following to work:
I've got the following files:
web/__init__.py
web/one.py
web/two.py
testimport.py
>From which
26 matches
Mail list logo
