static variables?

[Chad Netzer]

On Thursday 21 November 2002 15:23, Erik Max Francis wrote:

> Well, there are certainly other behaviors that have been changed when it
> was realized that they presented problems (such as the rather
> controversial upcoming change of integer division). 

True, but orthogonal to the point we are discussing.  Put aside whether or 
not the current behavior should be changed (because it almost certainly WON'T 
be changed).  The discussion you brought up is about why things are the way 
they are.  (FWIW, it would have been just as easy to implement division to 
always coerce to float;  I think the decision may have been based on 
potential performance issues, rather than ease of implementation.  Back in 
1991, floats were still very expensive compared to ints)

> In other words, I
> don't really see any evidence that the current behavior was a conscious
> decision made anywhere beyond the point of, "This is the easiest way to
> do it."

Fair enough.  But perhaps thought Guido simply thought, "Well, this is the 
most natural and consistent way to implement them."  After all, they are 
simply expressions, and all expressions in Python are evaluated immediately 
upon their execution.  This is a fundamentally different thought process than 
"this is easiest", even if the results are often exactly the same.

If Guido had wanted delayed, on-demand evaluation of expressions, it may have 
been easy to add (we already have much of the infrastructure for such a 
thing), and such a thing would be very useful for many wish list items (such 
as more flexible default argument passing, shortcutting ternary assignments, 
flexible function currying).  But it also leads to complications in the use 
of the language,  and perhaps was rejected for those reasons, not because it 
wasn't easy to implement.

So, I guess what I'm saying is don't take lack of evidence to mean proof of 
anything.

> True it would involve more overhead, but if you have to create new
> objects manually anyway, you obviously have to incur the same overhead,
> so this doesn't really seem to be a real objection.

Yes, and I'm not objecting to the usefullness of this particular behavior, if 
it had been the standard.  That is another issue, and many are in agreement 
with you about it.  But I think saying it was solely a matter of doing the 
easiest thing to implement is not an (obviously) accurate statement.  It 
makes perfect sense, from a design issue, given python's many other design 
choices.

That said, I would LOVE to discuss adding delayed evaluation to the language. 
 It would be the answer to many a requested feature.  But it would add 
complication to the laguage itself.

-- 
Bay Area Python Interest Group - http://www.baypiggies.net/

Chad Netzer
cnetzer at mail.arc.nasa.gov