On the REPL, when autocompleting with the TAB key, getattr is called, potentially triggering code execution.

This took me by surprise. Until you press RETURN, it should be pretty safe to go around autocompleting with certainty that you won't run any code. But that might be just my opinion.

What do you think?

I can reproduce the problem in Python 3.7.

Could it be the problem from readline?
Using python 2 with readline trigger same behavior.

This branch (working on the PR) fixes it:

https://github.com/franciscod/cpython/tree/bpo-29630

This is how Python works. Accessing an attribute (and even checking that the attribute exists) can trigger code executing.

Changes in https://github.com/franciscod/cpython/tree/bpo-29630 break autocompliting of proxy objects. And in any case it triggers code execution due to calling eval().

I think this is not a bug and changing current behavior can decrease usability.

I agree with Serhiy. There is no way to safely inspect any Python object without triggering some dunder functions like __getattr__, __getattribute__ or __dir__.

I've updated that branch and made a pull request (https://github.com/python/cpython/pull/248)

I think this is a good compromise: inspect.getattr_static can tell if it's a property, and in that case we don't call getattr on it to prevent code execution on the completion. If it isn't a property, the current codepath is preserved.

Your change is not backwards compatible and makes auto-completion less useful.

> There is no way to safely inspect any Python object without triggering some dunder functions like __getattr__, __getattribute__ or __dir__.

But somehow inspect.getattr_static can do it?

> Your change is not backwards compatible and makes auto-completion less useful.

Why is it less useful? The only change is not executing property getters when showing completion options. It's removing a surprising code execution before the newline is received.

Should CPython keep backwards compatibility of this execution-on-completion at the REPL?

It is less useful because don't work with dynamic attributes (with __getattar__ and __getattribute__). And if executing property getters is an issue (I don't think it is), this change doesn't fix it completely.

inspect.getattr_static *tries* to get attributes without triggering dunder methods. It's neither fully compatible to getattr() nor does it guarantee that no code is triggered. The function may or may not be secure.

Surprise or not surprise is a matter of perspective. I don't find it surprising.

It's incompatible because it gives different results:

>>> class Example:
...     @property
...     def example(self):
...          def func(): pass
...          return func
... 
>>> e = Example()
>>> e.exa<TAB>
>>> e.example(

with your patch, I'm getting:
>>> e.exa<TAB>
>>> e.example

Do you notice the difference?

Serhiy, Chris, thank you for your additional comments. They surely helped me understand why my solution to this "problem?" isn't that good (also I slept on it a bit and maybe that helped).

I still ponder for a way to get autocompletion while guarranteeing no code will run, but a) any getter code is meant to run in that way, and b) it would somehow need to know the result of running that code without running it (Tricky, huh?).

Thanks again for your patience. I feel enlightened :)