After making a class using the @property decorator to implement a getter, using tab completion that matches the getter function name executes the function. 

See below for example (line numbers added, <tab> indicates when the user presses the tab key):

1  >>> class Foo(object):
2  ...     def __init__(self,value):
3  ...         self.value = value
4  ...     @property
5  ...     def print_value(self):
6  ...         print("Foo has a value of {}".format(self.value))
7  ... 
8  >>> bar = Foo(4)
9  >>> bar.<tab>~~~Foo has a value of 4~~~
10 <tab>~~~Foo has a value of 4~~~
11 
12 bar.print_value  bar.value        
13 >>> bar.p<tab>~~~Foo has a value of 4~~~
14 <tab>rint_value~~~Foo has a value of 4~~~
15 ~~~Foo has a value of 4~~~
16 
17 bar.print_value
18 >>> bar.v<tab>alue

I pressed tab after typing "bar." in line 9. It then printed the remainder of line 9 and moved the cursor to line 10. Pressing tab again prints line 10 and 11 before finally showing the expected output on line 12. lines 13-17 follow the same steps, but after typing "bar.p" to show that it happens whenever you tab and it matches the getter. Line 18 shows a correct tab completion resulting from hitting tab after typing "bar.v" which does not match the getter function.

I forgot to mention that I also added "~~~" to either side of the printed string every time it printed to help differentiate the printed string from commands that I typed into the interpreter.

Woah, til the python shell has tab completion! This does seem like undesirable behavior. I'd like to work on a fix for this if that's all right, assuming that this behavior should not occur.

I haven't exactly found where the tab autocomplete is implemented, but I'm assuming I'll find in one of the functions I see in the backtrace when I pause python at the interpreter prompt; maybe one of these? (my best quick guesses by function name).

- _PyRun_InteractiveLoopObject
- PyRun_InteractiveOneObjectEx
- interactive_rule
- statement_newline_rule

If anyone can point me in the right direction, that'd be great, and I think I can work on this one tomorrow if that's all right!

It looks to me like the issue is caused by the eval() in line 155 of the rlcompleter.py file (https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Lib/rlcompleter.py#L155) which runs the function in order to see if it runs or raises an exception.

I thought maybe replacing it with hasattr() might work, but it looks like the issue is repeated there as well!

>>> hasattr(bar, "print_value")
Foo has a value of 4
True

This goes over to the C side of things now (https://github.com/python/cpython/blob/196998e220d6ca030e5a1c8ad63fcaed8e049a98/Python/bltinmodule.c#L1162) and I'll put in another issue regarding that!

Actually, hasattr() specifically states that it uses getattr() so that behavior is expected from getattr() so I will not be creating a separate issue for that.

Now that I see hasattr() uses getattr(), it looks like the tab completion issue might not stem from line 155, but from line 180 (https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Lib/rlcompleter.py#L180) where it calls getattr().

A possible fix to the tab completion issue might be to add to/expand the warning about evaluating arbitrary C code (https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Lib/rlcompleter.py#L145) when using tab to autocomplete.

> Now that I see hasattr() uses getattr(), it looks like the tab completion issue might not stem from line 155, but from line 180 (https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Lib/rlcompleter.py#L180) where it calls getattr().

That is correct! I was able to fix the undesirable behavior by adding an early exit condition if we appear to have a property object. I checked for the existence of a property object like this:

    class Foo:

        @property
        def bar(self):
            return 'baz'

    def is_property(object, attr):
        return isinstance(getattr(type(object), attr, None), property)

    assert is_property(Foo(), 'bar')

The code that follows line 180 in the loop just checks if ``object.attribute`` is callable, and whether the callable takes arguments in order to determine whether to add parenthesis to the completion. In my opinion, we never really want to add parenthesis when providing completion for a property attribute anyway, so there's no reason to go through that code block if we are dealing with a property.

I opened a GitHub PR. Let me know what you think!

Wow, that was quick and the code looks clean too! Thanks for fixing that up!

New changeset 50de8f74f8e92b20e76438c22b6a8f91afd6df75 by Jack DeVries in branch 'main':
bpo-44752: Make rlcompleter not call `@property` methods (GH-27401)
https://github.com/python/cpython/commit/50de8f74f8e92b20e76438c22b6a8f91afd6df75

New changeset d20f1095a6a51ee8f41ef445a009d26256e1fa61 by Miss Islington (bot) in branch '3.10':
bpo-44752: Make rlcompleter not call `@property` methods (GH-27401) (GH-27444)
https://github.com/python/cpython/commit/d20f1095a6a51ee8f41ef445a009d26256e1fa61

New changeset acaf3b959492e7a84dcc9d46101ed6dc313768c8 by Miss Islington (bot) in branch '3.9':
bpo-44752: Make rlcompleter not call `@property` methods (GH-27401) (#27445)
https://github.com/python/cpython/commit/acaf3b959492e7a84dcc9d46101ed6dc313768c8

New changeset 6741794dd420c6b9775a188690dbf265037cd69f by Jack DeVries in branch 'main':
bpo-44752: refactor part of rlcompleter.Completer.attr_matches (GH-27433)
https://github.com/python/cpython/commit/6741794dd420c6b9775a188690dbf265037cd69f

New changeset f8e13e35d12bee6e3447c791199522249ba7f05a by Miss Islington (bot) in branch '3.10':
bpo-44752: refactor part of rlcompleter.Completer.attr_matches (GH-27433) (GH-27447)
https://github.com/python/cpython/commit/f8e13e35d12bee6e3447c791199522249ba7f05a

New changeset 93d90871d216625b8d9db0fa59693953353d19ae by Miss Islington (bot) in branch '3.9':
bpo-44752: refactor part of rlcompleter.Completer.attr_matches (GH-27433) (GH-27446)
https://github.com/python/cpython/commit/93d90871d216625b8d9db0fa59693953353d19ae

Thanks, Jack! ✨ 🍰 ✨