On Apr 26, 19:56, Guido.van.Rossum@cwi.nl wrote:
>
> Hmm, the consensus was (I think) not to have a command line option.
> The reason being that (permanently) having two versions of the
> language distinguished by a global switch would be a bad idea -- what
> if my module requires the switch to be off while your code requires it
> to be on, and then somebody else wants to use my code and yours in one
> program... (*)
>
Oops. Sorry. How *could* I have let my attention lapse during that
*FASCINATING* discussion. :-) JUST JOKING!!!! HaHa! :-) :-) :-)
[ I thought that now that we were a *newsgroup*, we were required to
adopt the usenet-standard method of arguing about something until
all of the parties are exhausted, and then just drop the subject
without closure! :-) ]
>
> Instead, expressions entered at the interactive toplevel will be
> printed and all others won't. (I still haven't figured out how to
> implement this, but a few ideas seem workable. The best idea would be
> to also introduce a magic global variable that receives the result of
> the last expression printed this way -- useful for a desk calculator-
> like use of interactive Python.)
>
[ Including the above quote is unnecessary, but I need something to
separate the *serious* section of this reply. ]
Re: syntax (a) vs. syntax (b)
(1) Is only a string constant allowed ?
(2) or any string valued expression or variable ?
I think it OUGHT to be (2) -
Which would also make (b) ambiguous, and (a) obvious and easily
parsable.
def square( a ) "%(__name__).square: returns the square of a number." % vars() :
return a * a
[ (*) assuming 'vars()' *does* return locals merged with global module
__dict__ - mainly because this would also get rid of most of
my need for "module(__name__)", - the majority of times it is probably
used in the expression "module(__name__).__dict__" .
Otherwise, insert some equivalent expression ( which probably won't
fit on a line @#$!&! ) ]