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

[michele.simionato]

Paul Rubin wrote:

How about macros? Some pretty horrible things have been done in C
programs with the C preprocessor. But there's a movememnt afloat to
add hygienic macros to Python. Got any thoughts about that?
"Movement" seems quite an exaggeration. Maybe 2-3 people made some
experiments, but nobody within the core Python developers seems
to be willing to advocate the introduction of macros.
Why should you care whether the output of a macro is ugly or not,
if no human is ever going to look at it?

But at least some human eye have to look at it!
<rethorical-question>
Did you ever debug a macro?
</rethorical-question>

More seriuosly, I have given some thought to the issue, and I am very
much against the introduction of macros in Python.

Here are a few reasons:

1. I like defmacro in Lisp. Problem is, Lisp is an s-expression based
language, Python is not. We cannot implement defmacro in Python and
even if we could, if would be too ugly to be used (at least, IMHO).

2. One could proposed hygienic pattern-matching macros in Python,
similar to
Scheme syntax-rules macros. Again, it is not obvious how to
implement pattern-matching in Python in a non-butt-ugly way. Plus,
I feel hygienic macros quite limited and not worth the effort.

3. We would add to Python the learning curve of macros and their
subtilities and we do not want it.

4. Macros would complicate a lot Python module system.

5. We have Guido providing a good syntax for us all, why we should be
fiddling with it? More seriously, if some verbosity is recognized
in the language (think to the "raison d'etre" of decorators, for
instance) I very much prefer to wait for Guido to take care of
that, once and for all, than having 100 different custom made
solutions based on macros.

I am sure I could find other reasons if I think a bit more, but these
should suffice for the moment ;)

What I would be interested in is a Lisp/Scheme implementation
compiling to Python bytecode, but I am not aware of any project
in that direction.
Michele Simionato

P.S. some pointers for people interested on the topic:

http://logix.livelogix.com/ (a Python-like language with macros)
https://sourceforge.net/projects/pymac/ (an experimental
Dylan-inspired macro system for Python)

[Paul Rubin]

mi***************@gmail.com writes:

2. One could proposed hygienic pattern-matching macros in Python,
similar to
Scheme syntax-rules macros. Again, it is not obvious how to
implement pattern-matching in Python in a non-butt-ugly way. Plus,
I feel hygienic macros quite limited and not worth the effort.
It wasn't obvious how to do it in Scheme either. There was quite
a bit of head scratching and experimental implementation before
there was consensus.
3. We would add to Python the learning curve of macros and their
subtilities and we do not want it.
I can't imagine how it could be worse than the learning curve of
__metaclass__, which we already have. If it was done in a way that
most of us would just rely on a few standard ones, that would be fine.
4. Macros would complicate a lot Python module system.
I don't see how, but maybe I'm missing something.
5. We have Guido providing a good syntax for us all, why we should be
fiddling with it? More seriously, if some verbosity is recognized
in the language (think to the "raison d'etre" of decorators, for
instance) I very much prefer to wait for Guido to take care of
that, once and for all, than having 100 different custom made
solutions based on macros.
Every time some newbie asks an innocent "how do I ..." question, we
see unbelievably horrid answers from gurus. Just check the FAQ about
conditional expressions, etc. I just don't see Python syntax changes
as forthcoming.
What I would be interested in is a Lisp/Scheme implementation
compiling to Python bytecode, but I am not aware of any project
in that direction.

But that sounds like a bizarre idea. Python bytecode is just a
CPython artifact, not part of the language. And it's not even that
good an artifact. Good Lisp/Scheme implementations compile to native
code that beats the pants off of CPython bytecode. It would make much
more sense to have a Python implementation that compiles Python to
S-expressions and then lets a high performance Lisp or Scheme system
take care of the rest.

[michele.simionato]

Paul Rubin:

[e-mail] writes:

<about Scheme macros> It wasn't obvious how to do it in Scheme either. There was quite
a bit of head scratching and experimental implementation before
there was consensus.
Actually I am not convinced there is consensus yet, i.e. there is a
non-negligible minority of schemers convinced that original Lisp
macros where better, not to talk of common lispers ;)
3. We would add to Python the learning curve of macros and their
subtilities and we do not want it. I can't imagine how it could be worse than the learning curve of
__metaclass__, which we already have.
To me, learning macros *and their subtilities* was much more difficult
than learning metaclasses.
4. Macros would complicate a lot Python module system. I don't see how, but maybe I'm missing something.
Go to comp.lang.scheme and google for "macros and module system";
you will get everything you want to know and much more!
5. We have Guido providing a good syntax for us all, why we should be fiddling with it? More seriously, if some verbosity is recognized
in the language (think to the "raison d'etre" of decorators, for
instance) I very much prefer to wait for Guido to take care of
that, once and for all, than having 100 different custom made
solutions based on macros. Every time some newbie asks an innocent "how do I ..." question, we
see unbelievably horrid answers from gurus. Just check the FAQ about
conditional expressions, etc. I just don't see Python syntax changes
as forthcoming.
Well, I see this as a positive fact. If a syntax is contrived (such as
a ternary
operator, for instance) it is better *not* to have it than to have one
hundred custom
made syntaxes. At the end, we are just talking about syntax sugar here,
not about
lack of functionality.
What I would be interested in is a Lisp/Scheme implementation
compiling to Python bytecode, but I am not aware of any project
in that direction.

But that sounds like a bizarre idea. Python bytecode is just a
CPython artifact, not part of the language. And it's not even that
good an artifact. Good Lisp/Scheme implementations compile to native
code that beats the pants off of CPython bytecode. It would make much
more sense to have a Python implementation that compiles Python to
S-expressions and then lets a high performance Lisp or Scheme system
take care of the rest.

This is a bizarre idea if you want to make Python run faster. It is not
so bizarre
if what you want is to have access to Python from Lisp/Scheme in the
same sense
Jython has access to Java.
Michele Simionato

[Simo Melenius]

mi***************@gmail.com writes:

This is a bizarre idea if you want to make Python run faster. It is
not so bizarre if what you want is to have access to Python from
Lisp/Scheme in the same sense Jython has access to Java.

And it sounds very nice if you prefer writing Lisp code (or resort to
it if needed) and run it on a cross-platform environment that's
available almost everywhere, and access a large standard library of
modern utilities.
br,
S

[Paul Rubin]

mi***************@gmail.com writes:

I can't imagine how it could be worse than the learning curve of
__metaclass__, which we already have.
To me, learning macros *and their subtilities* was much more difficult
than learning metaclasses.

I guess I've only used Lisp macros in pretty straightforward ways,
that weren't hard to understand. That's enough for anything I've
needed. But we don't hear much about __metaclass__ because almost
nobody understands it.
Go to comp.lang.scheme and google for "macros and module system";
you will get everything you want to know and much more!
OK, I might do this.
Well, I see this as a positive fact. If a syntax is contrived (such
as a ternary operator, for instance) it is better *not* to have it
than to have one hundred custom made syntaxes. At the end, we are
just talking about syntax sugar here, not about lack of
functionality.

I think the idea is there would be some experimentation and then one of
the versions would make it into the standard library.

[compiling Lisp to Python bytecode]

This is a bizarre idea if you want to make Python run faster. It is
not so bizarre if what you want is to have access to Python from
Lisp/Scheme in the same sense Jython has access to Java.

Why not just use a foreign function interface?

[Steve Holden]

Paul Rubin wrote:

mi***************@gmail.com writes:

2. One could proposed hygienic pattern-matching macros in Python,
similar to
Scheme syntax-rules macros. Again, it is not obvious how to
implement pattern-matching in Python in a non-butt-ugly way. Plus,
I feel hygienic macros quite limited and not worth the effort.

It wasn't obvious how to do it in Scheme either. There was quite
a bit of head scratching and experimental implementation before
there was consensus.

3. We would add to Python the learning curve of macros and their
subtilities and we do not want it.

I can't imagine how it could be worse than the learning curve of
__metaclass__, which we already have. If it was done in a way that
most of us would just rely on a few standard ones, that would be fine.

Well the necessity to understand metaclasses could in some ways be
regarded as the push for the summit, and therefore isn't something that
would trouble newbies. Given that we are having this discussion in the
context of a posited "where" clause intended to allow "multi-statement
expressions" (whatever they turn out to be) I would still argue you are
discussing the totally unnecessary.

Given that Guido is on record as saying that expressions aren't
statements because he wants those things to be separate, I don't really
see why there's this consistent pressure to reverse that decision.

4. Macros would complicate a lot Python module system.

I don't see how, but maybe I'm missing something.

5. We have Guido providing a good syntax for us all, why we should be
fiddling with it? More seriously, if some verbosity is recognized
in the language (think to the "raison d'etre" of decorators, for
instance) I very much prefer to wait for Guido to take care of
that, once and for all, than having 100 different custom made
solutions based on macros.

Every time some newbie asks an innocent "how do I ..." question, we
see unbelievably horrid answers from gurus. Just check the FAQ about
conditional expressions, etc. I just don't see Python syntax changes
as forthcoming.

There's a reason for this ...

What I would be interested in is a Lisp/Scheme implementation
compiling to Python bytecode, but I am not aware of any project
in that direction.

But that sounds like a bizarre idea. Python bytecode is just a
CPython artifact, not part of the language. And it's not even that
good an artifact. Good Lisp/Scheme implementations compile to native
code that beats the pants off of CPython bytecode. It would make much
more sense to have a Python implementation that compiles Python to
S-expressions and then lets a high performance Lisp or Scheme system
take care of the rest.

Which would be a worthier goal than trying to graft macros on to Python.
You responded that macros would be difficult to implement in m4 because
(in essence) of the indented structure of Python. I'm not convinced
they'd be any easier in Python, and I'm *certainly* not convinced that
their addition would improve Python's readability.

At best it would offer new paradigms for existing constructs (violating
the "there should be one obvious way to do it" zen); at worst it would
obfuscate the whole language.

If you really see the need for Python macros then a preprocessor would
surely be the best way to prove the validity of such ideas?

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC [phone] [phone]

[Steve Holden]

Paul Rubin wrote:

mi***************@gmail.com writes:

I can't imagine how it could be worse than the learning curve of
__metaclass__, which we already have.
To me, learning macros *and their subtilities* was much more difficult
than learning metaclasses.

I guess I've only used Lisp macros in pretty straightforward ways,
that weren't hard to understand. That's enough for anything I've
needed. But we don't hear much about __metaclass__ because almost
nobody understands it.

Paraphrasing Tim Peters, "if you don't definitely know that you need
metaclasses then you almost certainly don't". The primary reason for the
existence of metaclasses is as an implementation detail that allows
basic Python types to be base classes for inheritance. Python could have
hidden this mechanism, but the generally introspective nature of the
language makes it sensible to expose the mechanism for (ab)use by
knowledgeable users.

Go to comp.lang.scheme and google for "macros and module system";
you will get everything you want to know and much more!

OK, I might do this.

Well I'd be interested to know what you find out, not being a Lisper myself.

Well, I see this as a positive fact. If a syntax is contrived (such
as a ternary operator, for instance) it is better *not* to have it
than to have one hundred custom made syntaxes. At the end, we are
just talking about syntax sugar here, not about lack of
functionality.

I think the idea is there would be some experimentation and then one of
the versions would make it into the standard library.

Erm, you'd put syntax into a library module? That would be in
__future__, I take it?

[compiling Lisp to Python bytecode]

This is a bizarre idea if you want to make Python run faster. It is
not so bizarre if what you want is to have access to Python from
Lisp/Scheme in the same sense Jython has access to Java.

Why not just use a foreign function interface?

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC [phone] [phone]

[Antoon Pardon]

Op 2005-01-12, Steve Holden schreef <st***@holdenweb.com>:

Given that Guido is on record as saying that expressions aren't
statements because he wants those things to be separate, I don't really
see why there's this consistent pressure to reverse that decision.
Well, it seems that Guido is wrong then. The documentation clearly
states that an expression is a statement.

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

That makes the set of expressions a subset of the set of
statements and thus makes an expression a statement.
Which would be a worthier goal than trying to graft macros on to Python.
You responded that macros would be difficult to implement in m4 because
(in essence) of the indented structure of Python. I'm not convinced
they'd be any easier in Python, and I'm *certainly* not convinced that
their addition would improve Python's readability.

At best it would offer new paradigms for existing constructs (violating
the "there should be one obvious way to do it" zen); at worst it would
obfuscate the whole language.

That zen is already broken. Look at the number of answers one gets
if a newbee askes for a ternary operator. I think that a simple
ternary operator or macro's with an official supported macro that
implemented the ternary operator would have been far closer to
the spirit of only having one obvious way than what we have now.

--
Antoon Pardon

[Fredrik Lundh]

Antoon Pardon wrote:

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

no, it says that an expression statement is a statement. if you don't
understand the difference, please *plonk* yourself.

</F>

[Antoon Pardon]

Op 2005-01-13, Fredrik Lundh schreef <fr*****@pythonware.com>:

Antoon Pardon wrote:

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

no, it says that an expression statement is a statement. if you don't
understand the difference, please *plonk* yourself.

And what else is an expression statement but an expression (list) used
as a statement.

--
Antoon Pardon

[Steve Holden]

Fredrik Lundh wrote:

Antoon Pardon wrote:

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

no, it says that an expression statement is a statement. if you don't
understand the difference, please *plonk* yourself.

OK then, "The documentation clearly states that not all statements can
be expressions". Specifically Guido has justified the fact that an
assignment does not return any value, and therefore cannot be used as a
component of an expression.

Mea culpa, but I'm not going to *plonk* myself - then *nobody* would be
listening to me :-)

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC [phone] [phone]

[Craig Ringer]

On Thu, 2005-01-13 at 08:39 +0000, Antoon Pardon wrote:

At best it would offer new paradigms for existing constructs (violating
the "there should be one obvious way to do it" zen); at worst it would
obfuscate the whole language.

That zen is already broken. Look at the number of answers one gets
if a newbee askes for a ternary operator. I think that a simple
ternary operator or macro's with an official supported macro that
implemented the ternary operator would have been far closer to
the spirit of only having one obvious way than what we have now.

And then we have iteration ....

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

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

--
Craig Ringer

[Terry Reedy]

"Antoon Pardon" <ap*****@forel.vub.ac.be> wrote in message
news:sl********************@rcpc42.vub.ac.be...

Op 2005-01-13, Fredrik Lundh schreef <fr*****@pythonware.com>:

Antoon Pardon wrote:

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

no, it says that an expression statement is a statement. if you don't
understand the difference, please *plonk* yourself.

And what else is an expression statement but an expression (list) used
as a statement.

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).

Terry J. Reedy

[Paul Rubin]

"Terry Reedy" <tj*****@udel.edu> writes:

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

no, it says that an expression statement is a statement. if you don't
understand the difference, please *plonk* yourself.

And what else is an expression statement but an expression (list) used
as a statement.

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

Huh? Expressions are not statements except when they're "expression
statements"? What kind of expression is not an expression statement?
And logic would indicate that if we can separate statements from
expressions and still have "expression statements", nothing stops
us from also being able to have "statement expressions".

[Bengt Richter]

On Thu, 13 Jan 2005 09:29:49 -0500, Steve Holden <st***@holdenweb.com> wrote:

Fredrik Lundh wrote:

Antoon Pardon wrote:

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

no, it says that an expression statement is a statement. if you don't
understand the difference, please *plonk* yourself.

OK then, "The documentation clearly states that not all statements can
be expressions". Specifically Guido has justified the fact that an
assignment does not return any value, and therefore cannot be used as a
component of an expression.

Hm, that makes me wonder, is there an intermediate "returning of value" in
x = y = z = 123
?
Mea culpa, but I'm not going to *plonk* myself - then *nobody* would be
listening to me :-)

Regards,
Bengt Richter

[Fredrik Lundh]

Paul Rubin wrote:

Huh? Expressions are not statements except when they're "expression
statements"? What kind of expression is not an expression statement?

any expression that is used in a content that is not an expression statement,
of course.

reading the python language reference should help you sort this one out.

</F>

[Fredrik Lundh]

Bengt Richter wrote:

Hm, that makes me wonder, is there an intermediate "returning of value" in
x = y = z = 123
?

no. that statement evaluates the expression (123 in this case), and assigns
the result (the integer object 123) to each target (x, y, z), in order. or to
quote the language reference:

An assignment statement evaluates the expression list (remember
that this can be a single expression or a comma-separated list, the
latter yielding a tuple) and assigns the single resulting object to each
of the target lists, from left to right.

</F>

[Paul Rubin]

"Fredrik Lundh" <fr*****@pythonware.com> writes:

Huh? Expressions are not statements except when they're "expression
statements"? What kind of expression is not an expression statement?

any expression that is used in a content that is not an expression statement,
of course.

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.

[Nick Coghlan]

Paul Rubin wrote:

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.

No, it's entirely to do with building a readable language that uses significant
whitespace to delineate scope.

Simple statements are not allowed to contain other statements, but they are
allowed to contain expressions. In their most degenerate form, ALL they contain
is a *single* expression (e.g. a function call). That expression itself is still
not a statement, though. Think of it as the difference between value and [value].

Suites are sequences of statements.

Compound statements are statements which incorporate a suite as part of their
syntax.

Python allows statements inside suites and suites inside compound statements. It
also allows expressions inside statements and expressions inside expressions.
The one thing it never ever does is allow a suite or a statement inside an
expression, because doing so would utterly destroy the handling of significant
white space.

And that's why expressions are special in Python - they demarcate the boundary
of the significance of whitespace. Within an expression, whitespace is
insignificant. At the level of statements and suites, whitespace is extremely
significant.

So, precisely how should one go about cleanly embedding something that cares
about whitespace into a context which doesn't care in the slightest?

Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Paul Rubin]

Nick Coghlan <nc******@iinet.net.au> writes:

So, precisely how should one go about cleanly embedding something that
cares about whitespace into a context which doesn't care in the
slightest?

Treat the macro like a function call whose arguments are thunks made
from the macro arguments, or something like that. There's been some
discussions about it on clpy in the past, by people more into this
stuff than I am.

[Fredrik Lundh]

Paul Rubin wrote:

> Huh? Expressions are not statements except when they're "expression
> statements"? What kind of expression is not an expression statement?
any expression that is used in a content that is not an expression statement,
of course.

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]

Op 2005-01-13, Terry Reedy schreef <tj*****@udel.edu>:

"Antoon Pardon" <ap*****@forel.vub.ac.be> wrote in message
news:sl********************@rcpc42.vub.ac.be...

Op 2005-01-13, Fredrik Lundh schreef <fr*****@pythonware.com>:

Antoon Pardon wrote:

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

no, it says that an expression statement is a statement. if you don't
understand the difference, please *plonk* yourself.

And what else is an expression statement but an expression (list) used
as a statement.

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.

--
Antoon Pardon

[Antoon Pardon]

Op 2005-01-14, Fredrik Lundh schreef <fr*****@pythonware.com>:

Paul Rubin wrote:

> Huh? Expressions are not statements except when they're "expression
> statements"? What kind of expression is not an expression statement?

any expression that is used in a content that is not an expression statement,
of course.

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.

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.

--
Antoon Pardon

[Nick Coghlan]

Antoon Pardon wrote:

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.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Fredrik Lundh]

Antoon Pardon wrote:

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.

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]

Op 2005-01-14, Nick Coghlan schreef <nc******@iinet.net.au>:

Antoon Pardon wrote:

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.

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

[Antoon Pardon]

Op 2005-01-14, Fredrik Lundh schreef <fr*****@pythonware.com>:

Antoon Pardon wrote:

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.

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.

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

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?

--
Antoon Pardon

[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

[Carl Banks]

Skip Montanaro wrote:

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.
--
CARL BANKS

[Peter Maas]

Craig Ringer schrieb:

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. :)

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel [phone]
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
-------------------------------------------------------------------

[Tim Jarman]

Skip Montanaro wrote:

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. :)

--
Website: www DOT jarmania FULLSTOP com

[Carl Banks]

Tim Jarman wrote:

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/defin...rm=belgian&r=f
--
CARL BANKS

[Roel Schroeven]

Skip Montanaro wrote:

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 ;)

--
"Codito ergo sum"
Roel Schroeven

[Roel Schroeven]

Antoon Pardon wrote:

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.

--
"Codito ergo sum"
Roel Schroeven

[Antoon Pardon]

Op 2005-01-14, Roel Schroeven schreef <rs****************@fastmail.fm>:

Antoon Pardon wrote:

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.

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?

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

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.

--
Antoon Pardon

[Fredrik Lundh]

Antoon Pardon wrote:

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]

Antoon Pardon wrote:

Op 2005-01-14, Roel Schroeven schreef <rs****************@fastmail.fm>:

Antoon Pardon wrote:

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.

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.

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

expression_stmt ::= "exprstmt" expression_list
...
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.

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

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.

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

Regarding what Guido apparently said:

Op 2005-01-12, Steve Holden schreef <st***@holdenweb.com>:

Given that Guido is on record as saying that expressions aren't
statements because he wants those things to be separate

Antoon Pardon wrote: 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).

--
"Codito ergo sum"
Roel Schroeven

[Steve Holden]

Paul Rubin wrote:

"Fredrik Lundh" <fr*****@pythonware.com> writes:

Huh? Expressions are not statements except when they're "expression
statements"? What kind of expression is not an expression statement?

any expression that is used in a content that is not an expression statement,
of course.

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
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC [phone] [phone]