Why '==' ??

[Josiah Carlson]

> Not at all...but there you go... you need to reread what I said :-)

I've read what you said a few times.  You say that using '=' instead of 
'==' in boolean tests is unambiguous.  You also say that removing ':' 
is unambiguous.

I attempted to show you an example where such modifications /are/ ambiguous.


> Not at all.
> No need for a special case. Leave '==' with the same meaning as it
> currently has... but give '=' a dual meaning (as it has in reality)
> with the meaning obvious from context. In 'multi statements' (or
> whatever the correct phrase is to pre-empt any more otiose comments)
> require '==' so the syntax is clear.
> 
> Ie. If the meaning is obvious.... '=' can replace '=='... if it's
> not.. it can't...

The problem is that having multiple ways (syntactically) to do the exact 
same thing causes people to ask questions like "which one is better". 
There is an entire thread about this with regards to tabs vs. spaces in 
this newsgroup, and thousands of threads available as to where {} in 
C/C++ or Java should be located across the internet.

By saying "use it this way when it is unambiguous" and "use it this way 
when it is ambiguous", you are attempting to complicate the syntax of 
Python.  Why?  To save a few keystrokes.

"There should be one-- and preferably only one --obvious way to do it."
  - The Zen of Python, by Tim Peters


> The reason some people stated it was necessary was to allow another
> statement on the same line... which is what I said ';' was for.

I'm pretty sure the choice of ';' to end statements was to mirror 
various languages that people trying Python would likely be familliar 
with.  Considering these same languages have little to no use for the 
':' character (except for C++), its use in Python would be unambiguous.

Considering that in C, the following is a no-op, regardless of what a 
actually is...
if (a);

But in Python, different things /would/ actually happen based on the 
contents of a, so would introduce ambiguity for those people coming from 
a C/C++ background, needlessly.


> Sorry if you enjoy flaming newbies....... but in this case you'r a bit
> off beam Josian old bean.............

It wasn't a flame, it was an unkind post saying that your proposed 
syntax options were crap.  I'm fairly certain that Guido looked at quite 
a few options when trying to decide on proper syntaxes early on, so that 
he didn't make any major mistakes.  I am also fairly certain that the 
reason that your proposed syntax isn't what is currently done, is due to 
its ambiguity from the point of view of a C/C++ programmer.

  - Josiah