[Python-Dev] Re: rethinking import-related syntax errors

[Thomas Wouters]

On Wed, Jan 31, 2001 at 07:36:11PM -0500, Jeremy Hylton wrote:

> I believe Guido's recommendation about these two rules are:
>     1. Allow it, even though it dodgy style.  A two-stager would be
>        clearer:

>        def foo():
>            global string
>            import string as string_mod
>            string = string_mod

I don't think it's dodgy style, and I don't think a two-stager would be
clearer, since the docs always claim 'importing is just another assignment
statement'. The whole 'import-as' was added to *avoid* these two-stagers!

Furthermore, since 'global string;import string' worked correctly at least
since Python 1.5 and probably much longer, I suspect it'll break some code
and confuse some more programmers out there. To handle this 'portably'
(between Python versions, because lets be honest: Python 2.0 is far from
common right now, and I can't blame people for not upgrading with the
licence issues and all), the programmer would have to do

    def assign_global_string(name):
        global string
        string = name
    def foo():
        import string
        assign_global_string(name)

or even

    def foo():
        def assign_global_string(name):
            global string
            string = name
        import string
        assign_global_string(name)

(Keeping in mind nested scopes, what would *you* expect the last one to
do ?) I honestly think

    def foo():
        global string
        import string

is infinitely clearer.

>     2. Keep the restriction, because it's really bad style.  It can
>        also cause subtle problems with nested scopes.  Example:
>        def f():
>            from string import *
>            def g():
>                return strip
>            ....
>        It might be reasonable to expect that strip would refer to the
>        binding introduced by "from string import *"  but there is no
>        reasonable way to support this.

I'm still not entirely comfortable with disallowing this (rewriting code
that uses it would be a pain, especially large functions) but I have good
hopes that this won't be necessary because nothing large uses this :) Still,
it would be nice if the compiler would only barf if someone uses 'from
... import *' in a local scope *and* references unbound names in a nested
scope. I can see how that would be a lot of trouble for a little bit of
gain, though.

> The related question is whether I should worry about backwards
> compatibility at the C level.  PyFrame_New(), PyFunction_New(), and
> PyCode_New() all have different signatures.  Should I do anything
> about this?

Well, it could be done, maybe renaming the functions and doing something
like

#ifdef OLD_CODE_CREATION
#define PyFrame_New PyFrame_OldNew
...

etc, to allow quick porting to Python 2.1. I have never seen C code create
code/function/frame objects by itself, though, so I'm not sure if it's worth
it. The Python bit is, since it's a lot less trouble to fix it and a lot
more common to use the 'new' object.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!