python and macros (again) [Was: python3: 'where' keyword]

[Antoon Pardon]

Whereas an expression used within a statement is not a statement, and that
is the difference.

And of course, statements, in general, are not expressions and are not used
within statements (except within compound statements).

Here you are stating the opposite of what Guido is supposed to have
said.

IMO we have a: dogs are mamals kind of relationship in Python.

Every expression can be used where a statement is expected.
(And this can be worded as: every expression is a statement.)

Not every statement can be used where an expression is expected.

 

[Fredrik Lundh]

Come on, that is vacuous. The claim was "expressions are not
statements". But it turns out that expressions ARE statements.

no, expressions CAN BE USED as statements. that doesn't mean
that they ARE statements, unless you're applying belgian logic.

(if you have a problem figuring this out, try substituting other things for
"expressions" and "statements", and see if you still think that "can be
used as" and "are" are always the same thing. try "fish" and "pillow",
for example).

It's just an artifact. Whether the artifact is a desirable one is a matter
of discussion.

no, it's Python, and it's designed this way on purpose. go read the
language reference.

</F>

 

[Antoon Pardon]

no, expressions CAN BE USED as statements. that doesn't mean
that they ARE statements, unless you're applying belgian logic.

No I am applying set logic. Any string that is in the set of
valid expressions is also in the set of valid statements.

Like any animal that is in the set of dogs is also in the
set of mamals.

 

[Skip Montanaro]

Fredrik> no, expressions CAN BE USED as statements. that doesn't mean
Fredrik> that they ARE statements, unless you're applying belgian logic.

Hmmm... I'd never heard the term "belgian logic" before. Googling provided
a few uses, but no formal definition (maybe it's a European phrase so
searching for it in English is futile). The closest thing I found was

Or is it another case of Belgian logic, where you believe it because
theres no evidence or motive whatsoever?

Fredrik> no, it's Python, and it's designed this way on purpose. go
Fredrik> read the language reference.

What he said... While Python borrows stuff from other languages where they
fit, it has a few core syntactic features that taken together distinguish it
from other languages. Not allowing any statements to be used as expressions
is one of them. Note that both "expression" and "statement" are
context-sensitive terms. Fredrik applied them in their Python sense ("go
read the language reference"), while Paul (perhaps naively, perhaps
provocatively) seems bent on forcing a more general definition of the two
words on the thread.

Skip

 

[Nick Coghlan]

No I am applying set logic. Any string that is in the set of
valid expressions is also in the set of valid statements.

According to Python's grammar, this is not the case. It requires a NEWLINE or
";" token on the end to turn the expression into a statement. Actually appending
either of those tokens means the string is no longer an expression.

Cheers,
Nick.

 

[Fredrik Lundh]

No I am applying set logic. Any string that is in the set of
valid expressions is also in the set of valid statements.

since you're arguing that one concept is identical to another concept, that
operation has to work in both directions.

Like any animal that is in the set of dogs is also in the
set of mamals.

and all mammals are dogs?

it this a language problem? do you have problems parsing the statements
you reply to? even when someone explictly says "Given that we are having
this discussion in the context of", you chose to ignore that context. what's
wrong with you?

</F>

 

[Antoon Pardon]

According to Python's grammar, this is not the case. It requires a NEWLINE or
";" token on the end to turn the expression into a statement. Actually appending
either of those tokens means the string is no longer an expression.

Well you are correct, but by the same logic an expression_stmt isn't a
statement either. In point of fact none of the <specifics>_stmt is a
statement including an assignment.

But changing "statements" to "simple statements" seems to make
the assertion correct.

 

[Antoon Pardon]

since you're arguing that one concept is identical to another concept, that
operation has to work in both directions.

No I'm not. "is" doesn't mean the concepts are the same.

and all mammals are dogs?

No but every dog is a mammal, and saying that doesn't imply dog and
mammal are identical concepts

it this a language problem? do you have problems parsing the statements
you reply to? even when someone explictly says "Given that we are having
this discussion in the context of", you chose to ignore that context. what's
wrong with you?

Well IMO I have explained clearly that I understood this in a set
logical sense in my first response. It seems you chose to ignore
that context. So what's wrong with you?

 

[Carl Banks]

Fredrik> no, expressions CAN BE USED as statements. that doesn't mean
Fredrik> that they ARE statements, unless you're applying belgian logic.

Hmmm... I'd never heard the term "belgian logic" before. Googling provided
a few uses, but no formal definition (maybe it's a European phrase so
searching for it in English is futile). The closest thing I found was

Or is it another case of Belgian logic, where you believe it because
theres no evidence or motive whatsoever?

Maybe it's Belgain logic, as opposed to Dutch logic.

 

[Peter Maas]

And then we have iteration ....

(generator expressions, list comprehensions, for loops, ...?) over
(sequences, iterators, generators)

Just sequences and iterators. Generators are functions which return
iterators. Sequences and iterators provide two ways to build
containers.

My use cases:

finite, can be defined by enumeration: use sequence
infinite, must be defined algorithmically: use iterator

generator: neat way to produce an iterator, can also be viewed as
a persistent function call (better than static local variables).

Once defined, sequences and iterators have nearly the same interface.
To have list comprehensions but no equivalent for iterators would
be strange.

I happen to be extremely fond of the flexibility this provides, but one
obvious way to do it there is not.

Development of the language, backward compatibility and obviousness
are diverging goals. You can't satisfy them all at the same time.

And goals provide a direction but are rarely reached.

 

[Tim Jarman]

Fredrik> no, expressions CAN BE USED as statements. that doesn't mean
Fredrik> that they ARE statements, unless you're applying belgian
logic.

Hmmm... I'd never heard the term "belgian logic" before. Googling
provided a few uses, but no formal definition (maybe it's a European
phrase so
searching for it in English is futile). The closest thing I found was

Or is it another case of Belgian logic, where you believe it because
theres no evidence or motive whatsoever?

Fredrik> no, it's Python, and it's designed this way on purpose. go
Fredrik> read the language reference.

<snip>

IANA French person, but I believe that Belgians are traditionally
regarded as stupid in French culture, so "Belgian logic" would be
similar to "Irish logic" for an English person. (Feel free to insert
your own cultural stereotypes as required.

 

[Carl Banks]

IANA French person, but I believe that Belgians are traditionally
regarded as stupid in French culture, so "Belgian logic" would be
similar to "Irish logic" for an English person. (Feel free to insert
your own cultural stereotypes as required.

Ok.

http://www.urbandictionary.com/define.php?term=belgian&r=f

 

[Roel Schroeven]

Fredrik> no, expressions CAN BE USED as statements. that doesn't mean
Fredrik> that they ARE statements, unless you're applying belgian logic.

Hmmm... I'd never heard the term "belgian logic" before. Googling provided
a few uses, but no formal definition (maybe it's a European phrase so
searching for it in English is futile).

I'm from Belgium, and I've never heard it before either. Probably a
public secret, very carefully being kept hidden from us Belgians

 

[Roel Schroeven]

IMO we have a: dogs are mamals kind of relationship in Python.

I see what you mean, but I don't think it's true.

Every expression can be used where a statement is expected.
(And this can be worded as: every expression is a statement.)

Not really. An expression statement is a statement that looks like an
expression, but actually it's more than that: not only does it calculate
the value of the expression, it also prints the value.

Note that it would be perfectly possible to modify the syntax into

expression_stmt ::= "exprstmt" expression_list

so that you would have to write

exprstmt 6*9

instead of just

6*9

That makes it clearer to see the distinction: 6*9 is an expression,

exprstmt 6*9

is a statement. An expression statement, more precisely.

Not every statement can be used where an expression is expected.

AFAIK *no* statement can be used where an expression is expected.

 

[Antoon Pardon]

I see what you mean, but I don't think it's true.


Not really. An expression statement is a statement that looks like an
expression, but actually it's more than that: not only does it calculate
the value of the expression, it also prints the value.

1) Only in an interactive environment.

2) That the semantics differ according to where the expression is
used doesn't make a difference. That an expression decides which
branch of an if statement is executed or what object is pass
as an argument in a call are also semantic difference, yet
we still have an expression in both cases.

Note that it would be perfectly possible to modify the syntax into

expression_stmt ::= "exprstmt" expression_list

so that you would have to write

exprstmt 6*9

instead of just

6*9

That makes it clearer to see the distinction: 6*9 is an expression,

exprstmt 6*9

is a statement. An expression statement, more precisely.

If you change the syntax, of course you will change the strings
that will be accepted. I could change the syntax to:

if_stmt ::= "if" "ifexpr" expression ...

Have I now proved that expressions after an if are not normal
expressions?

AFAIK *no* statement can be used where an expression is expected.

But that was not the implication of what Guido supposedly had said.
So that this is not the case doesn't counter what I said.

 

[Fredrik Lundh]

Well IMO I have explained clearly that I understood this in a set
logical sense in my first response.

what does "first" mean on your planet?

</F>

 

[Roel Schroeven]

1) Only in an interactive environment.

True, I wanted to add that but forgot it. Doesn't change what I'm saying
though.

2) That the semantics differ according to where the expression is
used doesn't make a difference. That an expression decides which
branch of an if statement is executed or what object is pass
as an argument in a call are also semantic difference, yet
we still have an expression in both cases.

In both cases we have an expression, in both cases we have a statement,
in both cases the expression is a part of the statement. In one case the
expression is the only statement, in the other case the statement has
other parts too.

If you change the syntax, of course you will change the strings
that will be accepted. I could change the syntax to:

if_stmt ::= "if" "ifexpr" expression ...

Have I now proved that expressions after an if are not normal
expressions?

No, you still have a statement with one or more parts, one of which is
an expression.

In OOP terms: I think that an expression statement 'has an' expression
(I agree that is a very thin wrapper though), not that an expression
statement 'is an' expression.

But that was not the implication of what Guido supposedly had said.
So that this is not the case doesn't counter what I said.

Whether statements can be used in the place of expressions is indeed not
relevant to the discussion.

Regarding what Guido apparently said:

> Well, it seems that Guido is wrong then. The documentation clearly
> states that an expression is a statement.

I don't think it says that at all.

> More specifically, everywhere you can use a statement, you can
> simply use an expression according to the python syntax.

If you use an expression where a statement is expected, you really
write an expression statement that contains the expression (and nothing
else, but that doesn't matter).

 

[Steve Holden]

Come on, that is vacuous. The claim was "expressions are not
statements". But it turns out that expressions ARE statements. The
explanation is "well, that's because they're expression statements".
And there is no obvious case of an expression that can't be used as a
statement. So it's not inherently obvious that there needs to be any
kind of statement that can't be used as an expression. It's just an
artifact. Whether the artifact is a desirable one is a matter of
discussion.

Excuse me, coould we get back to discussing how many angels can dance on
the head of a pin?

or-something-interesting-like-that-sly y'rs - steve