logic behind the assert syntax?

[Niels Diepeveen]

Greg Landrum schreef:
> so
> assert 1,'foo'
multiple expressions, separated by commas

> and
> assert (1,'foo')
single expression, because of parentheses

> do different things.
> 
> print 1,'foo'
> and
> print (1,'foo')
> do different things.
same story

> 
> but
> return 1,'foo'
> and
> return (1,'foo')
> do the same thing.

return only takes a single expression, not multiple expressions
separated by commas, so the compiler can only interpret the comma as a
tuple constructor.

> 
> also
> a = 1,'foo'
> and
> a = (1,'foo')
> are equivalent.
> 
> weird.

same for assignment.

> 
> continuing to screw around, I tried:
>  >>> (1,'foo') == 1,'foo'
>  (0, 'foo')
> which seemed odd... so I tried:
>  >>> (1,'foo') == (1,'foo')
>  1
> this made sense.  But then:
>  >>> 1,'foo' == 1,'foo'
>  (1, 0, 'foo')
> confused me again until I realized that this was:
>  1,('foo==1),'foo

Right, this is simple operator precedence.

> 
> Now my head is in a bit of a whirl...  Python normally strikes me as
> so logical and reasonable, but this has thrown me for a loop.

You forgot to mention that (a,b) == ((a,b)), but f(a,b) is different
from
f((a, b)).
> 
> Can someone clear this up a bit?

The basic problem is that ASCII just doesn't provide enough different
brackets to use for lists, dicts and tuples and still leave parentheses
available for their normal use, so tuples have to be identified just by
the commas.
This wouldn't be so bad, except that in some places (assert, print and
argument lists) the syntax calls for either a single expression, or
multiple expressions separated by commas.
In those places the comma is interpreted as an expression separator, not
as a tuple constructor.

This isn't something anyone is happy about, but nobody has been able to
come up with a really good solution.

-- 
Niels Diepeveen
Endea automatisering