2.1.1 global weirds

[Alex Martelli]

"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
news:XhJ0PWAkCVd7Ewsg at jessikat.fsnet.co.uk...
    ...
> The real wart I feel is that the module a has two names, one when run as
> a script and the other when imported.

Since importing the main-script is such an oddity, I don't agree
that this qualifies as 'a wart'.  Still, warts are in the eye of the
beholder, so you're welcome to your own opinion:-).

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

> me that in the file a.py
>
> __file__ and __name__ ought always to be defined and given the
> appropriate 'right' values.

The point is, that when the main script a.py imports b.py at the
start, and the latter in turn imports a.py, under your desired
scheme there is absolutely nothing b can do with a's stuff right
after the import.  Under Python's present scheme, a's "normal"
module-level code has executed when b has finished importing
it in this way -- the unit-testing code that's presumably what
I'm exercising by running a.py (normally designed to be
imported) as a main script, being presumably guarded by
the usual "if __name__=='__main__'" and therefore skipped.

Seems reasonable to me (given circular imports, which are
not reasonable per se:-) -- either module circularly importing
each other may be unit-tested by running it as a main script.
The unit-test code of a, of course, will "import a" itself (that's
after the 'normal' imports have been done, normally) if it
needs to tweak or examine *a*'s globals (as opposed to its
own).  I fail to see any offsetting benefit in your preference.


> Since magic variables/names seem to be natural in python I would just
> make __main__ true in the main script and false everywhere else. It's
> truth value could be the module that corresponds to the main script.
>
> That would break all the if __name__=='__main__' scripts so it could
> never be done.

Of course.  But we're discussing whether it SHOULD be done, and
I opine it shouldn't.


Alex