buggy python interpretter or am I missing something here?

[Chris Angelico]

On Tue, Jan 28, 2014 at 2:33 AM, Rick Johnson
<rantingrickjohnson at gmail.com> wrote:
> You can kindly ignore Chris, he is just one of our well
> known *resident* "lonely individuals", seeking attention yet
> again! And his constant blabbing about and idol worship of REXX is
> more annoying than all of xah lee post combined, however, i
> do just enjoy watching him "casually" weaving in those
> examples as though he does not have an agenda to push.
>
> @Chris: Two can play at this game!

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.
Actually, REXX as a language has been majorly left behind. Back in the
early 1990s it was blessed with support for non-English text in the
form of DBCS (at least, the OS/2 REXX implementation was - don't know
how standard that was), but then nobody ever went in and made it all
Unicode instead, so now we have a bytes-only language. Has its
coolnesses, but far too much of it is done with language magic (eg the
PARSE statement - there's no way to interact with that, no way to make
anything dynamic, so even though it is, in many ways, much cleaner
than C's sscanf or Perl's regular expressions, it's just plain
impossible to extend). Still, it was my first taste of
arbitrary-precision arithmetic, and for that (and plenty more) I am
well appreciative.

Frankly, I don't "idol worship" *any* language. There is not a single
language that I've ever used which has no flaws. And I can't think of
any language with which I have no fundamental disagreements on major
design points. (Note that there's a difference between those two.
Flaws are objective (and I'm not talking about bugs, I'm talking about
stuff where the author agrees that it's wrong but it's too late to
change now), design disagreements are personal. 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),
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), but there are still a few
oddities that can't easily be fixed. They don't stop the language from
being useful and awesome.

ChrisA