2.1.1 global weirds

[Robin Becker]

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
I have

#a.py
print 'in a'
import b

#b.py
print 'in b'
import c

#c.py
print 'in c'
import a


then running a.py produces
C:\Tmp>a.py
in a
in b
in c
in a


ie a.py is executed twice, if the circularity is not involving a (change
c.py
#c.py
print 'in c'
import b

then running a.py doesn't execute any module twice
C:\Tmp>a.py
in a
in b
in c

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.
>Alex

-- 
Robin Becker