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!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4