Tab completion executes @property getter function

@ambv

BPO	44752
Nosy	@ambv, @miss-islington, @jdevries3133
PRs	bpo-44752: Make rlcompleter not call `@property` methods #27401 bpo-44752: refactor part of rlcompleter.Completer.attr_matches #27433 [3.10] bpo-44752: Make rlcompleter not call `@property` methods (GH-27401) #27444 [3.9] bpo-44752: Make rlcompleter not call `@property` methods (GH-27401) #27445 [3.9] bpo-44752: refactor part of rlcompleter.Completer.attr_matches (GH-27433) #27446 [3.10] bpo-44752: refactor part of rlcompleter.Completer.attr_matches (GH-27433) #27447

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2021-07-29.15:48:38.581>
created_at = <Date 2021-07-27.21:41:47.767>
labels = ['interpreter-core', 'type-bug', '3.9', '3.10', '3.11']
title = 'Tab completion executes @property getter function'
updated_at = <Date 2021-07-29.15:48:38.575>
user = 'https://bugs.python.org/RPecor'

bugs.python.org fields:

activity = <Date 2021-07-29.15:48:38.575>
actor = 'lukasz.langa'
assignee = 'none'
closed = True
closed_date = <Date 2021-07-29.15:48:38.581>
closer = 'lukasz.langa'
components = ['Interpreter Core']
creation = <Date 2021-07-27.21:41:47.767>
creator = 'RPecor'
dependencies = []
files = []
hgrepos = []
issue_num = 44752
keywords = ['patch']
message_count = 14.0
messages = ['398323', '398324', '398327', '398330', '398331', '398341', '398343', '398479', '398483', '398485', '398486', '398490', '398491', '398492']
nosy_count = 4.0
nosy_names = ['lukasz.langa', 'miss-islington', 'jack__d', 'RPecor']
pr_nums = ['27401', '27433', '27444', '27445', '27446', '27447']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue44752'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']

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 (

cpython/Lib/rlcompleter.py

Line 155 in bb3e0c2

thisobject = eval(expr, self.namespace)

) 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 (

cpython/Python/bltinmodule.c

Line 1162 in 196998e

builtin_hasattr_impl(PyObject *module, PyObject *obj, PyObject *name)

) 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 (

cpython/Lib/rlcompleter.py

Line 180 in bb3e0c2

val = getattr(thisobject, word)

) 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 (

cpython/Lib/rlcompleter.py

Line 145 in bb3e0c2

WARNING: this can still invoke arbitrary C code, if an object

) 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 (

cpython/Lib/rlcompleter.py

Line 180 in bb3e0c2

val = getattr(thisobject, word)

) 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 50de8f7 by Jack DeVries in branch 'main':
bpo-44752: Make rlcompleter not call @property methods (GH-27401)
50de8f7

New changeset d20f109 by Miss Islington (bot) in branch '3.10':
bpo-44752: Make rlcompleter not call @property methods (GH-27401) (GH-27444)
d20f109

New changeset acaf3b9 by Miss Islington (bot) in branch '3.9':
bpo-44752: Make rlcompleter not call @property methods (GH-27401) (bpo-27445)
acaf3b9

New changeset 6741794 by Jack DeVries in branch 'main':
bpo-44752: refactor part of rlcompleter.Completer.attr_matches (GH-27433)
6741794

New changeset f8e13e3 by Miss Islington (bot) in branch '3.10':
bpo-44752: refactor part of rlcompleter.Completer.attr_matches (GH-27433) (GH-27447)
f8e13e3

New changeset 93d9087 by Miss Islington (bot) in branch '3.9':
bpo-44752: refactor part of rlcompleter.Completer.attr_matches (GH-27433) (GH-27446)
93d9087

Thanks, Jack! ✨ 🍰 ✨

I'm not sure whether this solution is complete yet. It is nice that property descriptors are now excluded, but users can easily add their own descriptors and if the getter on that descriptors raise an exception, the exception is no longer caught.
Ideally we'd have an abstract class for descriptors so we cann filter out all the descriptor stuff.

Navigation Menu

Repository navigation

Tab completion executes @property getter function #88915

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Tab completion executes @property getter function #88915

Description

Activity

RPecor commented on Jul 27, 2021

RPecor commented on Jul 27, 2021

jdevries3133 commented on Jul 27, 2021

RPecor commented on Jul 27, 2021

RPecor commented on Jul 27, 2021

jdevries3133 commented on Jul 28, 2021

RPecor commented on Jul 28, 2021

ambv commented on Jul 29, 2021

ambv commented on Jul 29, 2021

ambv commented on Jul 29, 2021

ambv commented on Jul 29, 2021

ambv commented on Jul 29, 2021

ambv commented on Jul 29, 2021

ambv commented on Jul 29, 2021

LeonarddeR commented on Dec 6, 2023

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions