Useless expressions [was Re: Undefined behaviour in C]
BartC
bc at freeuk.com
Mon Mar 28 08:18:20 EDT 2016
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
More information about the Python-list
mailing list