Bug Report: Incorrect Classification of Method Calls as Operands

[batzlov]

Description:
When analyzing the provided code snippet, I expected multimetric to correctly classify operators, operands, and calculate the volume. However, it appears that the library is not correctly distinguishing between operators and operands in certain cases, resulting in an inaccurate volume calculation.

Steps to Reproduce:

1. Analyze the following code snippet with multimetric to measure operators, operands, and volume:

   class Dog:
       def __init__(self, name):
           self.name = name
   
       def wake_up(self):
           self.stretch()
           self.jump_on_bed()
   
       def stretch(self):
           print("Uh what a big stretch")
   
       def jump_on_bed(self):
           print("Jump")

2. Expected Behavior:

   • The method calls self.stretch() and self.jump_on_bed() should be classified solely as operators.

3. Actual Behavior:

   • The method calls self.stretch() and self.jump_on_bed() are counted both as operators and as operands.
   • This misclassification appears to be due to the fact that function calls on self are not properly identified as operators, leading to incorrect operand counts.
   • Consequently, this also leads to an inflated calculated volume.

Environment:

• Operating System: Ubuntu 22.04
• Python Version: 3.10.12
• multimetric Library Version: 2.2.1

Additional Notes:
Could this be a misunderstanding on my part regarding the classification of operators and operands in multimetric, or is this a genuine issue with the library's calculation logic?
This misclassification affects the accuracy of metrics, particularly for projects with frequent method calls on self. A correction to recognize these as operators (not operands) would improve metric accuracy.

[priv-kweihmann]

stretch is tokenized as Token.Name, which could be a variable or a function call IMO.
I will leave this open, but not intent to tackle the issue any time soon - patches welcome