Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'importing': 0.05; 'represents': 0.05; '(so': 0.07; 'element': 0.07; 'parser': 0.07; 'practice,': 0.07; 'see.': 0.07; 'tries': 0.07; 'imported': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'python': 0.11; '"from': 0.16; 'cyclic': 0.16; 'elements,': 0.16; 'exists)': 0.16; 'fine.': 0.16; 'foo"': 0.16; 'foo,': 0.16; 'imports': 0.16; 'other,': 0.16; 'received:80.91.229.3': 0.16; 'received:plane.gmane.org': 0.16; 'runs,': 0.16; 'symbols': 0.16; 'top-level': 0.16; 'weird': 0.16; 'wrote:': 0.18; 'module': 0.19; 'split': 0.19; 'import': 0.22; 'header:User-Agent:1': 0.23; 'script': 0.25; 'compiled': 0.26; 'references': 0.26; 'second': 0.26; 'least': 0.26; 'certain': 0.27; 'defined': 0.27; 'header:X -Complaints-To:1': 0.27; 'header:In-Reply-To:1': 0.27; 'am,': 0.29; 'thus': 0.29; 'code': 0.31; 'once,': 0.31; 'anyone': 0.31; 'bugs': 0.33; 'moment': 0.34; 'problem': 0.35; 'subject:with': 0.35; 'but': 0.35; 'explains': 0.36; 'largely': 0.36; 'module.': 0.36; 'vice': 0.36; 'being': 0.38; 'thank': 0.38; '2008': 0.38; 'to:addr:python-list': 0.38; 'files': 0.38; 'rather': 0.38; 'anything': 0.39; 'bad': 0.39; 'to:addr:python.org': 0.39; 'either': 0.39; 'received:org': 0.40; 'how': 0.40; 'first': 0.61; 'email addr:gmail.com': 0.63; 'name': 0.63; 'refer': 0.63; 'more': 0.64; 'inline': 0.74; 'other.': 0.75; 'fat': 0.84 X-Injected-Via-Gmane: http://gmane.org/ To: python-list@python.org From: Dave Angel Subject: Re: Coping with cyclic imports Date: Thu, 04 Jul 2013 09:33:27 -0400 References: <87bq4knmax.fsf@physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Gmane-NNTP-Posting-Host: 174.32.174.34 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 In-Reply-To: X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 42 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1372944826 news.xs4all.nl 15946 [2001:888:2000:d::a6]:58366 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:49860 On 07/04/2013 08:48 AM, kanchan.n.mahajan@gmail.com wrote: > On Tuesday, April 8, 2008 10:06:46 PM UTC+2, Torsten Bronger wrote: >> 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, 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 that cyclic imports work in Python under certain >> circumstances. Can anyone refer me to a page which explains *when* >> this works? Because at least once, the imported module was not >> "finished" and thus largely unusual. >> >> Thank you! >> >> Tschö, >> Torsten. >> > > > If you do "import foo" inside bar and "import bar" inside foo, it will work fine. By the time anything actually runs, both modules will be fully loaded and will have references to each other. > > The problem is when instead you do "from foo import abc" and "from bar 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-cyclic-imports-in-python > That's a nice looking oversimplification. But it's not true if top-level code in the second module to be imported tries to use symbols defined in the first module. And it's definitely bad practice, with weird bugs if either one of these files is the main script being loaded. -- DaveA