> > [guido]
> > ...
> > I am thinking about optimizing the distinction between globals and
> > built-ins in the same manner as that between locals and globals -- scan
> > the entire module for assignments, including global statements in its
> > functions and methods; anything that isn't obviously global must be
> > built-in. This may stop some code from working but that would've been
> > walking on thin ice anyway.
> I can think of very little real code this would break, assuming that
> "from ModuleName import *" at module level turned off the optimization.
> Am I correct in believing that these cover the other broken cases?:
> [several - 6? cases described]
I've been wondering, and meaning to ask about, a few things that may
be entirely contrary to this approach.
There are two fundamental capabilities that i have expected to find,
but which i have not found, in python:
(1) function/method parameters for which the actual arguments are *not*
evaluated, or pseudo-functions, akin to lisp (gasp:-) macros, and
(2) a way to do an assignment and also return a value, in a single
If item (2) were possible, instead of doing:
curr = GetNext(aStream)
while curr != '':
curr = GetNext(aStream)
you could do:
while (curr = GetNext(aStream)) != '':
Though really just a convenience, it might make for cleaner, less
error prone code. (No need to duplicate the same statement in two
places, or define a separate function for a one-shot action.)
Have i missed the way to do that? I gather that, since assignment is
a statement, it doesn't return a value. So i either do the assignment
or produce a value for the condition, not both at once.
(You can't even use the kludge of a function which accepts the
variable name, as a string, and the value. The function wouldn't know
the module and local name spaces of the caller, without resorting to
unholy manipulations of the stack.)
Item (1) seems more crucial to me.
I can see how unevalled args would be tricky - like with the kludge
mentioned above, the function getting the unevalled args wouldn't know
the context. Perhaps the local and global name spaces could be passed
in with the arg, as a tuple...
Reader macros could be nicer, with the bodies evaluated in the context
of the caller. (And i thought reader macros are supposed to be much
better behaved than those naughty #define-style text macros?)
Reader macros would, however interfere terribly with the kind of
optimization that guido is proposing. In fact, i suppose it would
also be complicated by expressions-that-do-assignments. That makes me
wonder whether this is a deliberate design decision, to head away from
unruly cross-name-space interference - a language environment where
you could trust that "foreign" functions could not mess with your
> package does fiddle the NS of the module from which it's called via #6,
> but haven't seen that form of abuse <wink> elsewhere.
> BTW, as recently as March 7th _you_ wrote, about #2:
> > The same kind of optimization cannot be performed for modules, since
> > a module can have global variables added dynamically from other
> > modules -- e.g.
> > import foo
> > foo.bar = 12
> > adds the variable 'bar' to module 'foo'. This is a feature.
> But since I never saw that as "a feature", I won't muddy the issues by
> pointing that out <grin>.
There seems to be a trend here. Is there any aim to restrict access
to name-space objects, like class instances and modules, to the
functional interfaces that their implementers provide? If not, i have
some apprehension about the proposed change. (And i'm not sure what i
think, if the functional-interface restrictions are an aim. Might be
good, might be difficult - don't know.)
I know i've missed lots of python history, and know that these issues
may have been covered. Sorry if i'm flogging a dead horse...
firstname.lastname@example.org, 301 975-3539