In code, list.clear is just ignored.
At the terminal, list.clear shows
<built-in method clear of list object at 0x000001C9CFEC4240>

in code:
x = [1,2,3]
x.clear
print(len(x))
3

at terminal:
x = [1,2,3]
x.clear
<built-in method clear of list object at 0x000001C9CFEC4240>
print(len(x))
3

Caused me an hour of frustration before I noticed list.clear() was what
I needed.

x = [1,2,3]
x.clear()
print(len(x))
0

On 2022-11-13, DFS <nospam@dfs.com> wrote:
> In code, list.clear is just ignored.
> At the terminal, list.clear shows
><built-in method clear of list object at 0x000001C9CFEC4240>
>
>
> in code:
> x = [1,2,3]
> x.clear
> print(len(x))
> 3
>
> at terminal:
> x = [1,2,3]
> x.clear
><built-in method clear of list object at 0x000001C9CFEC4240>
> print(len(x))
> 3
>
>
> Caused me an hour of frustration before I noticed list.clear() was what
> I needed.
>
> x = [1,2,3]
> x.clear()
> print(len(x))
> 0

If you want to catch this sort of mistake automatically then you need
a linter such as pylint:

$ cat test.py
"""Create an array and print its length"""

array = [1, 2, 3]
array.clear
print(len(array))
$ pylint -s n test.py
************* Module test
test.py:4:0: W0104: Statement seems to have no effect (pointless-statement)

On 11/13/2022 5:20 PM, Jon Ribbens wrote:
> On 2022-11-13, DFS <nospam@dfs.com> wrote:
>> In code, list.clear is just ignored.
>> At the terminal, list.clear shows
>> <built-in method clear of list object at 0x000001C9CFEC4240>
>>
>>
>> in code:
>> x = [1,2,3]
>> x.clear
>> print(len(x))
>> 3
>>
>> at terminal:
>> x = [1,2,3]
>> x.clear
>> <built-in method clear of list object at 0x000001C9CFEC4240>
>> print(len(x))
>> 3
>>
>>
>> Caused me an hour of frustration before I noticed list.clear() was what
>> I needed.
>>
>> x = [1,2,3]
>> x.clear()
>> print(len(x))
>> 0
>
> If you want to catch this sort of mistake automatically then you need
> a linter such as pylint:
>
> $ cat test.py
> """Create an array and print its length"""
>
> array = [1, 2, 3]
> array.clear
> print(len(array))
> $ pylint -s n test.py
> ************* Module test
> test.py:4:0: W0104: Statement seems to have no effect (pointless-statement)

Thanks, I should use linters more often.

But why is it allowed in the first place?

I stared at list.clear and surrounding code a dozen times and said
"Looks right! Why isn't it clearing the list?!?!"

2 parens later and I'm golden!

On 2022-11-13, DFS <nospam@dfs.com> wrote:
> On 11/13/2022 5:20 PM, Jon Ribbens wrote:
>> On 2022-11-13, DFS <nospam@dfs.com> wrote:
>>> In code, list.clear is just ignored.
>>> At the terminal, list.clear shows
>>> <built-in method clear of list object at 0x000001C9CFEC4240>
>>>
>>>
>>> in code:
>>> x = [1,2,3]
>>> x.clear
>>> print(len(x))
>>> 3
>>>
>>> at terminal:
>>> x = [1,2,3]
>>> x.clear
>>> <built-in method clear of list object at 0x000001C9CFEC4240>
>>> print(len(x))
>>> 3
>>>
>>>
>>> Caused me an hour of frustration before I noticed list.clear() was what
>>> I needed.
>>>
>>> x = [1,2,3]
>>> x.clear()
>>> print(len(x))
>>> 0
>>
>> If you want to catch this sort of mistake automatically then you need
>> a linter such as pylint:
>>
>> $ cat test.py
>> """Create an array and print its length"""
>>
>> array = [1, 2, 3]
>> array.clear
>> print(len(array))
>> $ pylint -s n test.py
>> ************* Module test
>> test.py:4:0: W0104: Statement seems to have no effect (pointless-statement)
>
>
> Thanks, I should use linters more often.
>
> But why is it allowed in the first place?

Because it's an expression, and you're allowed to execute expressions.

On 14/11/22 1:31 pm, Jon Ribbens wrote:
> On 2022-11-13, DFS <nospam@dfs.com> wrote:
>> But why is it allowed in the first place?
>
> Because it's an expression, and you're allowed to execute expressions.

To put it a bit more clearly, you're allowed to evaluate
an expression and ignore the result.

--
Greg

On 2022-11-14, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
> On 14/11/22 1:31 pm, Jon Ribbens wrote:
>> On 2022-11-13, DFS <nospam@dfs.com> wrote:
>>> But why is it allowed in the first place?
>>
>> Because it's an expression, and you're allowed to execute expressions.
>
> To put it a bit more clearly, you're allowed to evaluate
> an expression and ignore the result.

.... because it may have side effects, and it's not possible to determine
whether it will or not in advance.

On Mon, 14 Nov 2022 at 11:53, DFS <nospam@dfs.com> wrote:
>
> On 11/13/2022 5:20 PM, Jon Ribbens wrote:
> > On 2022-11-13, DFS <nospam@dfs.com> wrote:
> >> In code, list.clear is just ignored.
> >> At the terminal, list.clear shows
> >> <built-in method clear of list object at 0x000001C9CFEC4240>
> >>
> >>
> >> in code:
> >> x = [1,2,3]
> >> x.clear
> >> print(len(x))
> >> 3
> >>
> >> at terminal:
> >> x = [1,2,3]
> >> x.clear
> >> <built-in method clear of list object at 0x000001C9CFEC4240>
> >> print(len(x))
> >> 3
> >>
> >>
> >> Caused me an hour of frustration before I noticed list.clear() was what
> >> I needed.
> >>
> >> x = [1,2,3]
> >> x.clear()
> >> print(len(x))
> >> 0
> >
> > If you want to catch this sort of mistake automatically then you need
> > a linter such as pylint:
> >
> > $ cat test.py
> > """Create an array and print its length"""
> >
> > array = [1, 2, 3]
> > array.clear
> > print(len(array))
> > $ pylint -s n test.py
> > ************* Module test
> > test.py:4:0: W0104: Statement seems to have no effect (pointless-statement)
>
>
> Thanks, I should use linters more often.
>
> But why is it allowed in the first place?
>
> I stared at list.clear and surrounding code a dozen times and said
> "Looks right! Why isn't it clearing the list?!?!"
>
> 2 parens later and I'm golden!
>

No part of it is invalid, so nothing causes a problem. For instance,
you can write this:

>>> 1

And you can write this:

>>> 1 + 2

And you can write this:

>>> print(1 + 2)

But only one of those is useful in a script. Should the other two be
errors? No. But linters WILL usually catch them, so if you have a good
linter (especially built into your editor), you can notice these
things.

ChrisA

On 2022-11-14 00:55, Greg Ewing wrote:
> On 14/11/22 1:31 pm, Jon Ribbens wrote:
>> On 2022-11-13, DFS <nospam@dfs.com> wrote:
>>> But why is it allowed in the first place?
>>
>> Because it's an expression, and you're allowed to execute expressions.
>
> To put it a bit more clearly, you're allowed to evaluate
> an expression and ignore the result.
>
But if it's an expression where it's expecting a statement and it's not
a call, then it's probably a bug.

On Mon, 14 Nov 2022 at 13:18, MRAB <python@mrabarnett.plus.com> wrote:
>
> On 2022-11-14 00:55, Greg Ewing wrote:
> > On 14/11/22 1:31 pm, Jon Ribbens wrote:
> >> On 2022-11-13, DFS <nospam@dfs.com> wrote:
> >>> But why is it allowed in the first place?
> >>
> >> Because it's an expression, and you're allowed to execute expressions.
> >
> > To put it a bit more clearly, you're allowed to evaluate
> > an expression and ignore the result.
> >
> But if it's an expression where it's expecting a statement and it's not
> a call, then it's probably a bug.

Maybe, but I'd be dubious of making it that simplistic. For instance,
which of these is more likely to be useless?

spam or ham()
spam() or ham

Syntactically, both of them are 'or' expressions, but one of them is
almost certainly unnecessary, while the other is just an oddly-written
conditional statement and most definitely useful.

In any case, this is the job of linters, NOT the language itself.

ChrisA

On 11/13/2022 9:11 PM, Chris Angelico wrote:
> On Mon, 14 Nov 2022 at 11:53, DFS <nospam@dfs.com> wrote:
>>
>> On 11/13/2022 5:20 PM, Jon Ribbens wrote:
>>> On 2022-11-13, DFS <nospam@dfs.com> wrote:
>>>> In code, list.clear is just ignored.
>>>> At the terminal, list.clear shows
>>>> <built-in method clear of list object at 0x000001C9CFEC4240>
>>>>
>>>>
>>>> in code:
>>>> x = [1,2,3]
>>>> x.clear
>>>> print(len(x))
>>>> 3
>>>>
>>>> at terminal:
>>>> x = [1,2,3]
>>>> x.clear
>>>> <built-in method clear of list object at 0x000001C9CFEC4240>
>>>> print(len(x))
>>>> 3
>>>>
>>>>
>>>> Caused me an hour of frustration before I noticed list.clear() was what
>>>> I needed.
>>>>
>>>> x = [1,2,3]
>>>> x.clear()
>>>> print(len(x))
>>>> 0
>>>
>>> If you want to catch this sort of mistake automatically then you need
>>> a linter such as pylint:
>>>
>>> $ cat test.py
>>> """Create an array and print its length"""
>>>
>>> array = [1, 2, 3]
>>> array.clear
>>> print(len(array))
>>> $ pylint -s n test.py
>>> ************* Module test
>>> test.py:4:0: W0104: Statement seems to have no effect (pointless-statement)
>>
>>
>> Thanks, I should use linters more often.
>>
>> But why is it allowed in the first place?
>>
>> I stared at list.clear and surrounding code a dozen times and said
>> "Looks right! Why isn't it clearing the list?!?!"
>>
>> 2 parens later and I'm golden!
>>
>
> No part of it is invalid, so nothing causes a problem. For instance,
> you can write this:

If it wastes time like that it's invalid.

This is an easy check for the interpreter to make.

If I submit a suggestion to python-list@python.org will it just show up
here? Or do the actual Python devs intercept it?

>>>> 1
>
> And you can write this:
>
>>>> 1 + 2
>
> And you can write this:
>
>>>> print(1 + 2)
>
> But only one of those is useful in a script. Should the other two be
> errors? No. But linters WILL usually catch them, so if you have a good
> linter (especially built into your editor), you can notice these
> things.

ran pylint against it and got 0.0/10.

--disable=
invalid-name
multiple-statements
bad-indentation
line-too-long
trailing-whitespace
missing-module-docstring
missing-function-docstring
too-many-lines
fixme

and got 8.9/10.

Python doesn't care what an expression returns.

You've written an expression that returns the value of the 'clear' function
that is bound to that particular list.

The interpreter doesn't know or care if accessing that 'clear' attribute on
the class returns a function or for some reason triggers a bunch of side
effects that the author decided they wanted to use __getattr__ to trigger.

'list.clear' might be a perfectly reasonable expression in some library.
I'd rather it not be, but hey, there are millions of python programmers
making all kinds of code out there

arbitrary expressions can have arbitrary effects. just because a value
isn't assigned, returned or used as an argument to a function doesn't mean
it isn't doing anything.

you might then want python to inspect the result of the function, but how
can python know if the author isn't purposely ignoring the return value of
the expression?

people can call functions that return values for only their side effects.

if you can't tell by the form of the expression or the value it returns,
what is the linter supposed to look for?

what is the interpreter supposed to look for?

if you want to avoid accidentally failing to clear a list during a
function, you should write tests that check that various inputs to the
function produce the expected outputs.

'unit tests' are a good place to make sure that code is acting as you want
it to

for one-off scripts, you should always make the thing dry-run or convert
from an input to an output (rather than in-place) so you can rerun them a
few times and make sure they're doing what you want.

sometimes making sure things are right is just on you.

there will always be the occasional silly error in a script that is hard to
see until you step away for a moment.

stepping away and coming back is a pretty good thing to do if you're stuck
on something that feels impossible.

On Sun, Nov 13, 2022 at 10:33 PM DFS <nospam@dfs.com> wrote:

> On 11/13/2022 9:11 PM, Chris Angelico wrote:
> > On Mon, 14 Nov 2022 at 11:53, DFS <nospam@dfs.com> wrote:
> >>
> >> On 11/13/2022 5:20 PM, Jon Ribbens wrote:
> >>> On 2022-11-13, DFS <nospam@dfs.com> wrote:
> >>>> In code, list.clear is just ignored.
> >>>> At the terminal, list.clear shows
> >>>> <built-in method clear of list object at 0x000001C9CFEC4240>
> >>>>
> >>>>
> >>>> in code:
> >>>> x = [1,2,3]
> >>>> x.clear
> >>>> print(len(x))
> >>>> 3
> >>>>
> >>>> at terminal:
> >>>> x = [1,2,3]
> >>>> x.clear
> >>>> <built-in method clear of list object at 0x000001C9CFEC4240>
> >>>> print(len(x))
> >>>> 3
> >>>>
> >>>>
> >>>> Caused me an hour of frustration before I noticed list.clear() was
> what
> >>>> I needed.
> >>>>
> >>>> x = [1,2,3]
> >>>> x.clear()
> >>>> print(len(x))
> >>>> 0
> >>>
> >>> If you want to catch this sort of mistake automatically then you need
> >>> a linter such as pylint:
> >>>
> >>> $ cat test.py
> >>> """Create an array and print its length"""
> >>>
> >>> array = [1, 2, 3]
> >>> array.clear
> >>> print(len(array))
> >>> $ pylint -s n test.py
> >>> ************* Module test
> >>> test.py:4:0: W0104: Statement seems to have no effect
> (pointless-statement)
> >>
> >>
> >> Thanks, I should use linters more often.
> >>
> >> But why is it allowed in the first place?
> >>
> >> I stared at list.clear and surrounding code a dozen times and said
> >> "Looks right! Why isn't it clearing the list?!?!"
> >>
> >> 2 parens later and I'm golden!
> >>
> >
> > No part of it is invalid, so nothing causes a problem. For instance,
> > you can write this:
>
>
> If it wastes time like that it's invalid.
>
> This is an easy check for the interpreter to make.
>
> If I submit a suggestion to python-list@python.org will it just show up
> here? Or do the actual Python devs intercept it?
>
>
>
>
>
>
> >>>> 1
> >
> > And you can write this:
> >
> >>>> 1 + 2
> >
> > And you can write this:
> >
> >>>> print(1 + 2)
> >
> > But only one of those is useful in a script. Should the other two be
> > errors? No. But linters WILL usually catch them, so if you have a good
> > linter (especially built into your editor), you can notice these
> > things.
>
>
> ran pylint against it and got 0.0/10.
>
>
> --disable=
> invalid-name
> multiple-statements
> bad-indentation
> line-too-long
> trailing-whitespace
> missing-module-docstring
> missing-function-docstring
> too-many-lines
> fixme
>
>
> and got 8.9/10.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>

On 14/11/22 3:13 pm, MRAB wrote:
> But if it's an expression where it's expecting a statement and it's not
> a call, then it's probably a bug.

The key word there is "probably". If there's any chance it
could be not a bug, it can't be an error. At most it should
be a warning, and that's what linters are for. I wouldn't
like the core interpreter to be producing a bunch of warnings
for things like this.

--
Greg

On Mon, 14 Nov 2022 at 18:00, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>
> On 14/11/22 3:13 pm, MRAB wrote:
> > But if it's an expression where it's expecting a statement and it's not
> > a call, then it's probably a bug.
>
> The key word there is "probably". If there's any chance it
> could be not a bug, it can't be an error. At most it should
> be a warning, and that's what linters are for. I wouldn't
> like the core interpreter to be producing a bunch of warnings
> for things like this.
>

Notably, linters can be taught about more complex idioms, like:

try:
raw_input
except NameError:
raw_input = input

which is an easy way to make polyglot Py2/Py3 code that handles the
presence/absence of a particular name. Or, similarly:

try:
os.sendfile
except AttributeError:
... # cope with sendfile not being available

When os.sendfile exists, it's a completely useless expression. When it
doesn't, it's an error. But the difference between those two is
crucial.

ChrisA

On 14/11/2022 12.12, DFS wrote:
> On 11/13/2022 5:20 PM, Jon Ribbens wrote:
>> On 2022-11-13, DFS <nospam@dfs.com> wrote:
>>> In code, list.clear is just ignored.
>>> At the terminal, list.clear shows
>>> <built-in method clear of list object at 0x000001C9CFEC4240>
>>>
>>>
>>> in code:
>>> x = [1,2,3]
>>> x.clear
>>> print(len(x))
>>> 3
>>>
>>> at terminal:
>>> x = [1,2,3]
>>> x.clear
>>> <built-in method clear of list object at 0x000001C9CFEC4240>
>>> print(len(x))
>>> 3
>>>
>>>
>>> Caused me an hour of frustration before I noticed list.clear() was what
>>> I needed.
>>>
>>> x = [1,2,3]
>>> x.clear()
>>> print(len(x))
>>> 0
>>
>> If you want to catch this sort of mistake automatically then you need
>> a linter such as pylint:
>>
>>    $ cat test.py
>>    """Create an array and print its length"""
>>
>>    array = [1, 2, 3]
>>    array.clear
>>    print(len(array))
>>    $ pylint -s n test.py
>>    ************* Module test
>>    test.py:4:0: W0104: Statement seems to have no effect
>> (pointless-statement)
>
>
> Thanks, I should use linters more often.
>
> But why is it allowed in the first place?
>
> I stared at list.clear and surrounding code a dozen times and said
> "Looks right!  Why isn't it clearing the list?!?!"
>
> 2 parens later and I'm golden!
It looks 'right' because it is 'right'!
However, compared with what was intended, it was 'wrong'!

«
I really hate this d***umb machine,
I wish that they would sell it.
It never does quite what I want,
but only what I tell it!
»

Lifting some text from a recent PUG-meeting:

«Distinguishing functions and their names:

Please remind yourself that is_odd is the name of a function, whereas
is_odd() calls the function and could thus be considered a 'label' for
the returned-value – either approach could be used in different situations.
»

In this case, the subject is a method, and accordingly has a slightly
different flavor. Rather than a return-value, the impact is an effect
within the scope and/or to the state of the object. However, not
materially-different from the OP's question.

It is assumed that there is no difficulty related to calling the
function, eg len( x ).

So, why would we use the function/method by name instead of its asking
for its return-value?
(please remember that a Python function is a "first class" object)

The (above) Challenge to PUG-members was to use code which produces the
Fibonacci Sequence, and out of the first 16 values, return the number of
Fibonacci-values which are also odd-numbers.

We started with straight-line code which mixed-up these various steps in
the process. As the challenge continued, such tangling made it very
difficult to enable any variations. To illustrate the SRP and DIP
(Single Responsibility and Dependency Inversion Principles of SOLID
Architecture), we refactored and refactored, ending-up with:

values_counted = sm.sequence_select_and_project(
fg.fibonacci_generator,
is_odd,
limit,
)

sequence_select_and_project is a for-loop spanning two if-statements
which count or break
fibonacci_generator is self-explanatory (hopefully)
is_odd returns boolean advice
limit is 16

Note how the first two arguments are [generator-]function names, cf
function-calls!

Now for 'the magic' of a dependency-inverted plug-in architecture:-

If the 16 is changed to 32, we'll be comfortable with the idea that
twice as many values will be generated and considered.

So, think about changing the generator to produce (say) prime numbers.

Alternately, alter the program to count only values divisible by two
(perhaps using "is_even" as function-name).

By 'plugging-in' a different function-name, the above control-routine
can be used with any suitably-lengthy sequence as its data-source,
and/or selection-criteria function!

Accordingly, using the name of a function can be as useful as using the
result of a function-call - even if the latter is far more common.

--
--
Regards,
=dn

Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>If you want to catch this sort of mistake automatically then you need
>a linter such as pylint:

For comparison, a C program:

main.c

#include <stdio.h> /* printf */

int main( void )
{ printf; }

transcript

main.c: In function 'main':
main.c:7:3: warning: statement with no effect [-Wunused-value]
7 | { printf; }
| ^~~~~~

. Maybe some of the early designers of Python were C programmers.

In VBA, "debug.print" is allowed, having the same meaning as
"debug.print()", while "sin" gives an error: "Argument is not
optional".

Supersedes: <return-20221114095213@ram.dialup.fu-berlin.de>
["evaluation of a function" -> "evaluation of an expression"]

Michael Speer <knomenet@gmail.com> writes:
>Python doesn't care what an expression returns.

In my English, functions return values,
expression are being evaluated to a value.
The evaluation of an expression yields or
produces a value. Expressions do not return,
because they are not functions.

Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>Because it's an expression, and you're allowed to execute expressions.

Yes. This is the dynamical point of view. There's also a
statical point of view, i.e., mere syntax, which is, in
this case, "expression_stmt ::= starred_expression".

|7.1 Expression statements
....
|expression_stmt ::= starred_expression
| |An expression statement evaluates the expression list
|(which may be a single expression).
| |In interactive mode, if the value is not None, it is converted
|to a string using the built-in repr() function and the
|resulting string is written to standard output on a line by
|itself (except if the result is None, so that procedure calls
|do not cause any output.)
| The Python Language Reference (early 3.9)

So, in interactive mode, it even does call a function,
viz., "repr()".

Op 14/11/2022 om 4:23 schreef DFS:
> On 11/13/2022 9:11 PM, Chris Angelico wrote:
>> On Mon, 14 Nov 2022 at 11:53, DFS <nospam@dfs.com> wrote:
>>>
>>> On 11/13/2022 5:20 PM, Jon Ribbens wrote:
>>>> On 2022-11-13, DFS <nospam@dfs.com> wrote:
>>>>> In code, list.clear is just ignored.
>>>>> At the terminal, list.clear shows
>>>>> <built-in method clear of list object at 0x000001C9CFEC4240>
>>>>>
>>>>>
>>>>> in code:
>>>>> x = [1,2,3]
>>>>> x.clear
>>>>> print(len(x))
>>>>> 3
>>>>>
>>> But why is it allowed in the first place?
>>>
>>> I stared at list.clear and surrounding code a dozen times and said
>>> "Looks right!  Why isn't it clearing the list?!?!"
>>>
>>> 2 parens later and I'm golden!
>>>
>>
>> No part of it is invalid, so nothing causes a problem. For instance,
>> you can write this:
>
>
> If it wastes time like that it's invalid.

It's not invalid. In the REPL for example, it does something useful:

>>> x = [1, 2, 3]
>>> x.clear
<built-in method clear of list object at 0x000002947DBBF680>

Others have shown instances where writing a method or function without
calling it are useful in a script too.

There are languages that handle this differently. Ruby, for example,
calls the function/method even when you don't write the parens, if I'm
not mistaken. Personally I don't like that; I much prefer Python's
explicitness in making the difference between the value of a function
and calling that function. Still, there's something to be said for
warnings. I agree with others that such warnings are more the job for a
linter than for the language.

FWIW I've been bitten by this in C++ once. I wanted to write something like

if (some_condition())
    foo();

But I forgot the parens after some_condition, so C++ evaluated the
function pointer (which was non-NULL so evaluated is true in a boolean
context) instead of the return value, and therefore foo() got called
unconditionally.

--

"Don't Panic."
-- Douglas Adams, The Hitchhiker's Guide to the Galaxy

Am Mon, Nov 14, 2022 at 02:13:34AM +0000 schrieb MRAB:

> But if it's an expression where it's expecting a statement and it's not a call, then
> it's probably a bug.

That "probably" makes it suitable for a linter, as was pointed out.

Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B

The terminal told you what x.clear was.

The Python documentation tells you how to call it: https://docs.python.org/3/tutorial/datastructures.html

list.clear()
Remove all items from the list. Equivalent to del a[:].

An IDE (e.g. PyCharm) will try to autocomplete the parentheses and warn you if you don’t:

“Statement seems to have no effect and can be replaced with a function call to have effect”

From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of DFS <nospam@dfs.com>
Date: Sunday, November 13, 2022 at 7:46 PM
To: python-list@python.org <python-list@python.org>
Subject: In code, list.clear doesn't throw error - it's just ignored
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

In code, list.clear is just ignored.
At the terminal, list.clear shows
<built-in method clear of list object at 0x000001C9CFEC4240>

in code:
x = [1,2,3]
x.clear
print(len(x))
3

at terminal:
x = [1,2,3]
x.clear
<built-in method clear of list object at 0x000001C9CFEC4240>
print(len(x))
3

Caused me an hour of frustration before I noticed list.clear() was what
I needed.

x = [1,2,3]
x.clear()
print(len(x))
0

--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!jRrjG0fRo46VyY0jLfD1Z5C6tXDiphZy8zi2AqN_N5BB1_OwBe_wxmsBWmIVOFQDdZnvbRq1JNeGnPg$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!jRrjG0fRo46VyY0jLfD1Z5C6tXDiphZy8zi2AqN_N5BB1_OwBe_wxmsBWmIVOFQDdZnvbRq1JNeGnPg$>

Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>"""Create an array and print its length"""
>array = [1, 2, 3]
>array.clear

BTW: Above, there are /two/ expression statements
with no effect; the other one is

"""Create an array and print its length"""

. Apparently, linters know this and will not create
a warning for such string literals.

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>BTW: Above, there are /two/ expression statements
>with no effect; the other one is
>"""Create an array and print its length"""
>. Apparently, linters know this and will not create
>a warning for such string literals.

And Python is reported to remove such string
statements when invoked with "-OO".

On 2022-11-14, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>>"""Create an array and print its length"""
>>array = [1, 2, 3]
>>array.clear
>
> BTW: Above, there are /two/ expression statements
> with no effect; the other one is
>
> """Create an array and print its length"""
>
> . Apparently, linters know this and will not create
> a warning for such string literals.

Not only do they know this, pylint will complain if you *don't* include
that line, which is why I included it ;-)

On Tue, 15 Nov 2022 at 05:57, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>
> Michael Speer <knomenet@gmail.com> writes:
> >Python doesn't care what an expression returns.
>
> In my English, functions return values,
> expression are being evaluated to a value.
> The evaluation of a function yields or
> produces a value. Expressions do not return,
> because they are not functions.
>

Well, you can dispute the terminology all you like, but there's no
real difference between function calls and other types of expression.
They're all just expressions and they can be combined arbitrarily.

ChrisA

On 13Nov2022 22:23, DFS <nospam@dfs.com> wrote:
>On 11/13/2022 9:11 PM, Chris Angelico wrote:
>> [ ... `x.clear` ... ]
>>No part of it is invalid, so nothing causes a problem. For instance,
>>you can write this:
>
>If it wastes time like that it's invalid.

It's a valid expression.

It looks to your eye like a no-op, but at actually Python _looks up the
name `clear`_ on an object (which happens to be a `list`). That is a
real thing to do, and can have side effects.

While most of the examples here have been in the REPL where running an
expression with no side effects is itself useful, because the REPL can
print the result, I've personally got some real world code with a bare
`some_object.attribute` line. I'm not sure where, or I'd show it, but I
_think_ it was probably prepriming a cached object property. There might
have been a more expressive way to do that, but it was a bare attribute
lookup with side effects, _used for those side effects_.

>This is an easy check for the interpreter to make.

It really isn't, given that (a) this isn't known by the interpreter to
be a `list` until runtime and (b) that would need embedding special
knowledge that looking up an attribute on a `list` has no side effects
(versus some other things, where it is not the case).

Linters are the best place for this: they warn about probably-mistakes
idioms like this, and can have slightly deep knowledge of the code's
semantics sometimes.

>If I submit a suggestion to python-list@python.org will it just show
>up here? Or do the actual Python devs intercept it?

Nah, it'll go through.

Cheers,
Cameron Simpson <cs@cskk.id.au>