2.1.1 global weirds
robin at jessikat.fsnet.co.uk
Sun Aug 12 12:17:05 CEST 2001
In article <9l40tk01pfn at enews4.newsguy.com>, Alex Martelli
<aleaxit at yahoo.com> writes
>"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
>news:XhJ0PWAkCVd7Ewsg at jessikat.fsnet.co.uk...
>> I suppose there is some overriding implementation issue, but it seems to
>Not really, more of a logical issue. When I "import floop", I expect
>floop's module-level code to have executed fully by the time I get
>to execute the next statement after the import, so I can use (e.g.)
>all functions defined in floop by def statements, etc. When imports
>are circular, this just can't be -- call it an "overriding implementation
>issue" if you will, but you just can't meet the expected "module-level
>code of imported module has fully executed by the time the statement
>right after import executes" for BOTH modules that import each other.
>Circular imports (and circular dependencies in general) are a horror
>and there's little any language can do to make things rosy and peachy.
>Maybe they should be forbidden (i.e., I'm neutral on the thesis "any
>allowance for circularity is a wart", as I said), but as long as they're
>allowed I find Python's behavior in the matter quite reasonable.
Since circularity is already a potential danger (whether or not the main
script is involved) I don't think it really adds to the clarity of the
language that the 'main' script gets treated differently. For example if
print 'in a'
print 'in b'
print 'in c'
then running a.py produces
ie a.py is executed twice, if the circularity is not involving a (change
print 'in c'
then running a.py doesn't execute any module twice
I consider that a bit strange since it seems that the special case of
main script circularity is harder to detect/avoid; I believe that's
onlyc caused by the special module name.
More information about the Python-list