This one's "fundamental" in the sense that it would take fundamental
changes to the language to make it work. E.g., if f(1+2) doesn't
evaluate its argument, what does f "see"? Python simply doesn't support
an easily-manipulable code-object type.
You can often fake the effect via passing strings and eval/exec'ing them,
or passing code objects (e.g., as created via "compile"), though.
It may be some consolation to hear that everyone thinks Python is missing
_something_ -- but it's rare to hear three people agree on what that may
be <wink>.
> (2) a way to do an assignment and also return a value, in a single
> expression.
>
> If item (2) were possible, instead of doing:
>
> curr = GetNext(aStream)
> while curr != '':
> DoStuffWith(curr)
> curr = GetNext(aStream)
>
> you could do:
>
> while (curr = GetNext(aStream)) != '':
> DoStuffWith(curr)
>
> 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.)
There's no need for those now, which is why it's awful hard to make a
compelling case that this one is "fundamental"; e.g., idiomatic Python
for the loop-and-a-half avoids duplication and artificial functions via:
while 1:
curr = GetNext(aStream)
if curr == '':
break
DoStuffWith(curr)
Until recently, Python always printed the result of any expression-
statement (it still does, but only for top-level interactive
expressions), so that if assignment had returned a value (= if assignment
had been an expression rather than a statement),
curr = GetNext(aStream)
would have tried its darnedest to print "curr"'s value. In interactive
mode, it would still be a pain if, e.g.,
>>> x = range(5000)
printed [0, 1, 2, 3, ..., 4999]. I'm not clear on whether Guido objects
to assignments-as-expressions for other reasons, although this reason is
irritating enough.
> ...
> Item (1) seems more crucial to me.
What do you want to accomplish with it? Few people have expressed a
desire for it, and since I'm not one of the ones who has, there's really
nothing for me to say here other than that I've lived fine without it.
BTW, a really _good_ macro system is a major piece of work (even a crappy
one like C's takes a good bite out of an implementer's life!), so if it
doesn't strike Guido as a cool thing to do with _his_ spare time, the
only way it will get done is if fans do it themselves.
> ...
> 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?
Believe Guido's primary hopes in distinguishing builtins from globals are
to continue the existing trend toward static scoping, and to get some
speedup. Restricting visibility is probably a separate (albeit related)
issue, and the interpreter already reserves the keyword "access" for that
(not yet implemented) purpose.
The intent of "access" is to let you declare such restrictions as you
deem appropriate, then have the interpreter enforce them. I think that's
more trouble than it's worth, but then I live in my own twisted little
world <0.9 grin> ...
> ...
> 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...
No problem!
flogging-a-live-horse-is-more-disgusting-by-far-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp