Re: v1.0.2 question

Steven D. Majewski (sdm7g@elvis.med.virginia.edu)
Thu, 5 May 1994 15:07:28 -0400

On May 5, 10:56, Guido.van.Rossum@cwi.nl wrote:
>
> One way to almost-fix it would be to store the variable '_' in the
> module __builtin__. In that way, it can still be used without
> prefixing it with a module, but typing vars() won't go into recursion.
> (vars(__builtin__) would, but that's a lot less likely to be called --
> and sys.last_value would have the same problem with vars(sys).)
>

Another vote for '__builtin__._' !

We don't need to make it impossible for trip over trying to print
a recursive object. You could always do that with the old Python.
We just don't want to leave it lying where a newbie is likely to
stumble over it!

We already have a principle that __builtin__ is a "magical" place
and you shouldn't mess with it if you don't know what you're doing -
so restricting the strange stuff to that scope is a reasonable
solution.

[ BTW: NOT that it's a place for the casual Python-er to stumble
over, but the same problem applies to func.func_globals and
various frame attributes if 'func' is defined in the __main__
scope. Moving '_' to __builtin__ should fix this, also. ]

> Beyond that, the routines that print mutable objects like lists and
> dictionaries would have to be fixed to trap recursion somehow. This
> seems like a tedious job (keep a stack of objects already being
> printed) and there's the question, WHAT to print instead of the
> recursive object?

If the problem is limited, then I don't think a general print-fix is needed.
If you were going to change print, then I might suggest a more radical
change to make it possible to override print and/or to modify the
print representation of builtin objects. ( I'm *NOT* saying it's
necessary - just that *that* option may be easier and more useful than
trying to provide a general solution to printing recursive types. )

- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics