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

[avi.e.gross at gmail.com]

Cameron,

What would be the meaning of an ordering relation determining what is MORE
VALID?

As has been pointed out, not only are some uses that look odd sometimes
valid, but perhaps even can be used in ways you simply may not see, such as
side effects. Some examples ranging from poor to horrible are mentioned
below.

In some languages, trying to access a variable that is not properly existing
or initialized, can generate an error, as an example, which may cause the
current function to terminate if not caught and jump up the call chain till
an error handler is found. Code like:

1/0

May seem meaningless as the result is not saved, but may trigger a divide by
zero error.

Is it an error to write code like:

If x.clear:
  pass

I suspect it is possible to write quite weird code that might pass most
linters but that does nothing useful and also to write code that is useful
but might be disparaged by many interpreters or linters. 

My example above is a fairly common code pattern while code is being written
as a sort of reminder to perhaps come back later and flesh it out properly,
or remove it if it is no longer applicable. If so, it would be reasonable
for it to be challenged and also to ignore such warnings until later when
either it is gone, or the code hint should be gone.

There are many cases where short-circuit evaluation means code is not run
such as "True || x"  that is less obvious but equally bypassed if you set a
variable to True and do not change it and use it instead of True above. But
is it an error? What if again, my later goal is to add code that may change
the Truth value. As it is, the statement is not evaluated. But it may be set
up as a placeholder to enhance later, perhaps long after, or retain some
flexibility. Insisting it be removed might be too harsh while a warning
might be reasonable. Yet again, it is not always an error to not use
something like declaring a variable you might need or importing a module you
never use. 

Code is chock full of such things in mid-stream. And you can deliberately
ignore some things without it being a mistake as in:

( _, mean, _) = minMeanMax(args)

Sure, it may be overkill to call a function that returns three things then
ignore two of them. So what? What if instead of "_" I used real variable
names like min and max? Should I get error messages that two variable are
set up with values but never again used?

Or consider what I sometimes do when I write code that someone else will use
and to test it I must use something like a different filename/path on my
machine than they do on theirs. I might write code like

# Comment out one or more of the below so only one exists:
Place = "whatever"
Place = "Some other place"

Clearly if I am using the second one, I can comment the first out OR I can
leave it alone and at minor expenses let the variable be unconditionally
reset to the second value. Is it a bug or a feature?

I could go on with other examples including some more subtle ones like
declaring a variable name just to mask another variable from being
accessible from a higher level and perhaps prevent the interpreter or
compiler  optimizing it away by using it in the meaningless way this
discussion began with as it has been accessed once.

One person's bug can be another person's feature. And clearly, as has been
mentioned, there MAY be subtle side effects like invoking your custom setter
or dunder method which also does logging or increments a count.

There is a spectrum between being overly permissive and overly strict. This
case almost amuses me because of the way that many a REPL works so something
run directly in a console will take an expression like  "varname" and PRINT
the current value to the screen. If the same code is run from a file, or
from inside some function, it does nothing useful and you need something
like "print(varname)" instead. People often cut and paste such snippets of
code and in one context they did something and in another, it seems
meaningless and possibly an error.

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com at python.org> On
Behalf Of Cameron Simpson
Sent: Monday, November 14, 2022 9:34 PM
To: python-list at python.org
Subject: Re: In code, list.clear doesn't throw error - it's just ignored

On 14Nov2022 19:15, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
>	There is also the minor facet that "x.clear" can be bound to a 
>different name...
>
>>>> x = [1, 2, 3.145926536, "Pie"]
>>>> clearx = x.clear
>>>> x
>[1, 2, 3.145926536, 'Pie']
>>>> clearx()
>>>> x
>[]
>>>>

I think the OP would take the stance that this:

     clearx = x.clear

is more valid than:

     x.clear

which discards the return value of the expression.

Cheers,
Cameron Simpson <cs at cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list