On 28/03/2016 02:24, Steven D'Aprano wrote:
On Sun, 27 Mar 2016 10:31 pm, BartC wrote:
Whether there are side-effects is not quite as important as picking up
things that are likely to be errors:
f() # Probably OK
g() # Probably OK
f()+g() # Probably not OK
You don't and can't know what's "probably not" okay unless you know what
type of object both f and g return.
Don't think about floats and ints and strings. Think of complex objects with
operator overloading. You're probably thinking of `x + y`. Instead, think
of things like:
graph + node
database + table
There's theory, and there's practice.
Most types of statements start with a keyword.
The ones that don't need a keyword are assignments (including augmented
assignment), and standalone expressions (I'm sure someone will correct
me if I'm wrong).
And of standalone expressions, the vast majority that I can see are
function calls (that is, an expression, of any complexity, ending with
(...)).
So no matter how many potentially useful counter-examples you can dig
up, non-function-call expressions are still going to be highly unusual.
And suspect.
That's why it's not going to be much loss to disallow them /in that form/.
(There are also docstrings, but until yesterday I didn't even know they
were also expressions. Wikipedia says this:
"Python docstrings appear as a string literal (not an expression) as the
first statement following the definition of functions..."
so their status is a little unclear. Whatever it is, they don't lead to
the same head-scratching when they appear as arbitrary expressions that
are not function calls.)
in a procedural style instead of a functional style. With operator
overloading, we have the ability to write domain-specific little languages.
Sure. But give the reader a warning!
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
