buggy python interpretter or am I missing something here?

[Rick Johnson]

On Monday, January 27, 2014 9:53:37 AM UTC-6, Chris Angelico wrote:
> Heh. If you'd said Pike instead of REXX, I might have
> believed you :) I've said more about Pike than is perhaps
> appropriate, but of late, I've actually not been the one
> to most often quote REXX code.

Yes in my haste to inject a jab at you i pulled the
trigger before fully retracting the gun from my holster...
OUCH!

It was indeed "Pike" that i meant. But, although you
*do* mention it quite a lot, i don't think mentioning any
language should be off topic because heck, someone could
learn something new.

> [snip]
> For instance, I personally believe that disallowing
> assignment-as-expression cuts out more value than it gains
> by preventing bugs (as we've seen lately, people can just
> get it wrong the other way, comparing as a statement),

I myself wish for such a Python feature -- but alas, we are but
slaves to whims of the dutch!

> but I respect Guido's decision on that and don't see it as
> a problem to be fought. A lot of Python's worst flaws were
> fixed in 3.x (input() -> eval(), print as a statement,
> etc),

I agree that those are flaws, but not enough of a flaw to
break code. "input" is only used by neophytes, so who cares
about breaking that one, but "print" is almost everywhere!

But let's go back to "input" for a bit...

Why do we even need an "input" function anyway if all
it is going to do is read from stdin? Would not $stdin.read
have been better choice? Or simply "read" if you're a global
namespace pollution fanboy!

Heck, if you're going to have a function for writing
strings to $stdout, and also, you're going to have a
function for reading strings from $stdin, then you need to
recognize the diametric relation between these functions,
and as such, your first design consideration should be to
maintain a consistency between them

    input (reads a string from stdin)
    print (writes a string to stdout)

It is my strong believe that defining an "input" method that
"magically" evals the input string is just plain evil. Why
you ask? Because doing so injects superfluous magic whist
simultaneously blinding the noob to the fact that strings
are the mutually inclusive love interest of both "Mrs.Input"
and "Mr.Output".