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

[dn]

On 14/11/2022 12.12, DFS 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!
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