symtable.Class.get_methods() returns non-methods

[JelleZijlstra]

Bug report

Bug description:

Running this file:

import symtable

st = symtable.symtable("""
class X:
    class Nested: pass
    type Alias = int
    x = (x for x in range(10))
    y = filter(lambda z: z % 2, range(10))
""", "mod", "exec")

cls = st.get_children()[0]
print(cls.get_methods())

Prints:

('Nested', 'Alias', 'genexpr', 'lambda')

None of these are methods.

@carljm and I noticed this as part of the work on PEP 649 (#119361 (comment)). My draft implementation excludes generated __annotate__ functions from the list of "methods", but perhaps all non-methods should be excluded.

CPython versions tested on:

3.12, CPython main branch

Operating systems tested on:

macOS

Linked PRs

• gh-119698: deprecate symtable.Class.get_methods #120148
• gh-119698: fix symtable.Class.get_methods and document its behaviour correctly #120151
• [3.12] gh-119698: fix symtable.Class.get_methods and document its behaviour correctly (#120151) #120776
• [3.13] gh-119698: fix symtable.Class.get_methods and document its behaviour correctly (GH-120151) #120777
• gh-119698: symtable: Fix merge race #120779
• gh-119698: fix a special case in symtable.Class.get_methods #121802
• gh-119698: deprecate symtable.Class.get_methods #121902
• [3.13] gh-119698: fix a special case in symtable.Class.get_methods (GH-121802) #121909
• [3.12] gh-119698: fix a special case in symtable.Class.get_methods (GH-121802) #121910

[serhiy-storchaka]

The symtable CLI

$ echo "
class X:
    class Nested: pass
    type Alias = int
    x = (x for x in range(10))
    y = filter(lambda z: z % 2, range(10))
" | ./python -m symtable

shows details:

symbol table for module from file '<stdin>':
    local symbol 'X': def_local

    symbol table for class 'X':
        local symbol 'Nested': def_local
        local symbol 'Alias': def_local
        local symbol 'x': def_local
        global_implicit symbol 'range': use
        local symbol 'y': def_local
        global_implicit symbol 'filter': use

        symbol table for class 'Nested':

        symbol table for type alias 'Alias':
            free symbol '__classdict__': use
            global_implicit symbol 'int': use

        symbol table for function 'genexpr':
            local symbol '.0': def_param
            local symbol 'x': use, def_local

        symbol table for function 'lambda':
            local symbol 'z': use, def_param

We see that get_methods() returns the names of nested symbol tables. Some symbol table names like "genexpr" and "lambda" has no relation to the name of any nested symbol. It is a question why get_methods() can be useful at all.

We can simply deprecate get_methods(). Or define it as returning names of local symbols that has corresponding symbol table with type "function". Then it may be worth to add also get_classes() and get_aliases(). What do you need?

[JelleZijlstra]

Then it may be worth to add also get_classes() and get_aliases(). What do you need?

I have never used this module and I don't know how people are using it; I ran into this problem because some tests failed while I was working on the PEP 649 implementation.

Deprecating this method seems like a reasonable path forward.

[JelleZijlstra]

cc @picnixz in case you're interested in other problems with the symtable module.

[picnixz]

Personally, I've never used it but I was interested in contributing to CPython so I started where I thought it was something not too hard and interesting. One use case that I have in mind is IntelliSense but I would expect those tools to actually use the AST instead (but since their code is private, I cannot say for sure).

If there is really no use-case, I'd suggest deprecating it (less things to maintain, easier for us). I've tried to search whether it's used or not on github but I've only seen this occurrence https://github.com/skulpt/skulpt/blob/8daae6db0d2834ae2e66f6407e00239d4a95ead1/skulpt.py#L101 being relevant (others are not I think). However, they are using the thing for Python 2 and are not claiming full Python 3 compatibility.

[picnixz]

I've implemented two suggestions so feel free to pick either of the two.

I decided to keep the PR fixing the interface since Carl and Jelle have reviewed it and the work was not that much.

[picnixz]

For the record, I've implemented get_aliases and get_classes using a more generic approach in a separate branch: https://github.com/picnixz/cpython/tree/feat-symtable-classes

Note that the branch actually contains a local copy of #120151 (and I will not open a PR yet).

[JelleZijlstra]

I would only add such methods if someone comes up with an actual use case.

[serhiy-storchaka]

I only have found the use of this method in the skulpt project, which is Python 2 only. I also prefer to deprecate it.

[picnixz]

To summarize, we would fix the method in 3.14 (and 3.12, 3.13, depending on the backport decision), deprecate it in 3.15 and remove it in 3.17? (and it's fine that we don't need the other methods)

[serhiy-storchaka]

Why not deprecate it in 3.14?

[picnixz]

Err..., maybe someone will be interested in using it since we fixed it? (I can add the deprecation in the same or a follow-up PR though)