Simplify the logic handling the EvaluationMethods mixin class for Expression

[jdemeyer]

Depends on #20825
Depends on #20686

CC: @nthiery @tscrim

Component: symbolics

Author: Nicolas M. Thiéry

Branch/Commit: u/nthiery/optimize_method_lookup_from_the_categories_for_instances_of_cython_classes @ 5619a7d

Issue created by migration from https://trac.sagemath.org/ticket/20859

[jdemeyer]

Dependencies: #20825, #20686

[jdemeyer]

Branch: u/nthiery/optimize_method_lookup_from_the_categories_for_instances_of_cython_classes

[jdemeyer]

New commits:

44e80b3	EvaluationMethods should be a new-style class
9a1ff6e	Improve getattr_from_other_class
744ffa6	Test that static methods work
f5361d9	Improve _sage_src_lines_()
782f140	20686: minor comments improvements
dc84d88	Remove comments about "private" attributes with two underscores
8a4f48d	Abstract away category lookup in cdef method getattr_from_category
2e93afe	Merge branch 'u/jdemeyer/optimize_method_lookup_from_the_categories_for_instances_of_cython_classes' of trac.sagemath.org:sage into t/20686/optimize_method_lookup_from_the_categories_for_instances_of_cython_classes
5619a7d	20686: simplified the logic handling the EvaluationMethods mixin class for Expression's (internally backward incompatible)

[jdemeyer]

Commit: 5619a7d

[jdemeyer]

comment:3

You really should use new-style classes. Old-style classes exist only for backwards compatibility and will be gone in Python 3.

[jdemeyer]

comment:4

I just moved your branch from #20686 here. Feel free to rewrite history to make it depend only on #20825.

[jdemeyer]

comment:5

The use of cls.__dict__ seems to preclude the use of inheritance since cls.__dict__ does not do MRO lookup while dir(cls) does.

[nthiery]

comment:6

Thanks for creating the ticket and splitting of the commit! I am fine with this depending on #20686.

[nthiery]

comment:7

Replying to @jdemeyer:

You really should use new-style classes. Old-style classes exist only for backwards compatibility and will be gone in Python 3.

Fun: from the same premises, we arrive at opposite conclusions :-)

Here is my logical chain:

In Python 3 we won't make the inheritance from object explicit: it would be
redundant to write:

        class XXXMethods(object):

Furthermore, for our XXXMethods classes, it does not matter whether
they are old style or new style classes (they just are bags of
methods). Thus it feels natural to use right away the Python 3
idiom. That's what we have been doing in all the categories.

[nthiery]

comment:8

Replying to @jdemeyer:

The use of cls.__dict__ seems to preclude the use of inheritance since cls.__dict__ does not do MRO lookup while dir(cls) does.

That's on purpose, for consistency with what we do in categories: the XXXMethods are meant to be pure mixins / bags of methods; they are not supposed to inherit from anything.

[jdemeyer]

comment:9

Replying to @nthiery:

XXXMethods are meant to be pure mixins / bags of methods;

Given that it's a class, I would expect it to behave like a class. If you insist that it should not behave like a class, then at least make it explicit and invent a new metaclass BagOfMethods which disallows inheritance for example.

they are not supposed to inherit from anything.

How is a random Sage developer supposed to know that? That's one thing that I really don't like about the category framework in general: it makes several assumptions which work fine most of the time, but can bite you badly (the automatic binding is another such one). It almost feels like a slightly different programming language (that class is not really a Python class, it's just a dict).