In code, list.clear doesn't throw error - it's just ignored

Michael Speer knomenet at gmail.com
Sun Nov 13 23:53:08 EST 2022


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 at dfs.com> wrote:

> On 11/13/2022 9:11 PM, Chris Angelico wrote:
> > On Mon, 14 Nov 2022 at 11:53, DFS <nospam at dfs.com> wrote:
> >>
> >> On 11/13/2022 5:20 PM, Jon Ribbens wrote:
> >>> On 2022-11-13, DFS <nospam at 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 at 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
>


More information about the Python-list mailing list