On Tue, 15 Nov 2022 09:11:10 +1100, Cameron Simpson <cs@cskk.id.au>
declaimed the following:

>On 13Nov2022 22:23, DFS <nospam@dfs.com> wrote:
>>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).
>

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
[]
>>>

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

On 14Nov2022 19:15, Dennis Lee Bieber <wlfraed@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@cskk.id.au>

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@python.org> On
Behalf Of Cameron Simpson
Sent: Monday, November 14, 2022 9:34 PM
To: python-list@python.org
Subject: Re: In code, list.clear doesn't throw error - it's just ignored

On 14Nov2022 19:15, Dennis Lee Bieber <wlfraed@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@cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>In VBA, "debug.print" is allowed, having the same meaning as
>"debug.print()", while "sin" gives an error: "Argument is not
>optional".

In Python 2.6, one could write

print

to print an empty line. Today, "print" would be a mere name.

print
<built-in function print>

In Python 3.9, one needs to write

print()

for the same effect as "print" had in Python 2.6.

One also could have gone the other way, that of VBA.
By this, we would be able to call any function without
parenthesis in the top (outermost) level of a statement.

So, if I would have written a function

def trace( message ):
print message

, I would then be able to call it via

trace "my message"

. It would look as if the language could be extended
by new user-defined commands, while under the hood it
would still be a function call.

One would be able to define a no-argument function:

def here:
print "I'm here."

and call it with just the statement

here

. This would not prevent functions as values.

return here

,

print here

or

x = here

could still be used, because in those cases "here" is not
used at the /outermost/ level of a statement. So in those
cases, it would denote the function, not invoke it.

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:

output

<string>, line 1
list.clear
Warning: Attribute used as statement.

<string>, line 5
list.clear
Warning: Attribute used as statement.

source code

import ast, sys

def check( point, source ):
if isinstance( point, ast.Expr ) and\
type( point.value )== ast.Attribute:
print( "<string>, line", point.lineno, file=sys.stderr )
print( source.split( '\n' )[ point.lineno-1 ], file=sys.stderr )
print\
( "Warning:", "Attribute used as statement.", file=sys.stderr )
print()

def mylinter( source ):
for point in ast.walk( ast.parse( example )):
check( point, source )

example = """\
list.clear
list.clear()
x = list.clear
print( list.clear )
list.clear
"""

mylinter( example )

On Thu, 24 Nov 2022 at 06:26, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>
> 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:
>
> output
>
> <string>, line 1
> list.clear
> Warning: Attribute used as statement.
>
> <string>, line 5
> list.clear
> Warning: Attribute used as statement.
>
> source code
>
> import ast, sys
>
> def check( point, source ):
> if isinstance( point, ast.Expr ) and\
> type( point.value )== ast.Attribute:
> print( "<string>, line", point.lineno, file=sys.stderr )
> print( source.split( '\n' )[ point.lineno-1 ], file=sys.stderr )
> print\
> ( "Warning:", "Attribute used as statement.", file=sys.stderr )
> print()
>
> def mylinter( source ):
> for point in ast.walk( ast.parse( example )):
> check( point, source )
>
> example = """\
> list.clear
> list.clear()
> x = list.clear
> print( list.clear )
> list.clear
> """
>
> mylinter( example )
>

Uhh, yes? You just created an extremely simplistic linter. Your point?

ChrisA

On Sun, 13 Nov 2022 16:28:39 -0500, DFS wrote:

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

It is obvious why ignores it. It's a method:

Python 3.10.8 (main, Nov 1 2022, 14:18:21) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> l=[1,2,3]
>>> help(l.clear)

Help on built-in function clear:

clear() method of builtins.list instance
Remove all items from list.

--
Gilmeh

Contains no artificial colors or ingredients.

On Sun, Nov 13, 2022 at 4:45 PM 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
>
> --
> https://mail.python.org/mailman/listinfo/python-list

I'm not 100% sanguine about properties, but the fact is they are part of
the language:

$ cat p
below cmd output started 2022 Fri Nov 25 07:54:42 AM PST
#!/usr/bin/env python3

class P:
def __init__(self):
self.count = 0

@property
def increment(self):
self.count += 1

def result(self):
return self.count

p = P()
p.increment
p.increment
print(p.result())
above cmd output done 2022 Fri Nov 25 07:54:42 AM PST
dstromberg@tp-mini-c:~/src/experiments/property x86_64-pc-linux-gnu 2670

$ ./p
below cmd output started 2022 Fri Nov 25 07:54:44 AM PST
2

As you can see, if the interpreter refused to do something with p.increment
because it has no parens, the meaning of this code would change
significantly.