[Python-ideas] pep-0484 - Forward references and Didactics - be orthogonal

[Andrew Barnert]

On Aug 26, 2015, at 13:22, Sven R. Kunze <srkunze at mail.de> wrote:
> 
>> On 26.08.2015 07:50, Terry Reedy wrote:
>> A developer should not expect to use not-yet-existent attributes and methods of the object.
> 
> Unfortunately, that is where I disagree. The definition of "not-yet-existent attribute" can vary from developer to developer.

But it has to mean something, and what it means dramatically affects what the code does. That's why Python has a simple rule: a straightforward imperative execution order that means you can easily tell whether the attribute was created before use.

Also note that in Python, attributes can be added, replaced, and removed later, and their values can be mutated later. So the notion of "later" has to be simple to understand. Just saying "evaluate these statements in some order that's legal" doesn't work when some of those statements can be mutating state. In Python, a statement can create, replace, or destroys attributes of the module or any other object, and even an expression can mutate the values of those attributes. And in fact that's what everything in Python is doing, even declarative-looking statements like class, so you can't just block mutation, you have to deal with it as a fundamental thing.

Besides fully compiler-driven evaluation order, there are two obvious alternatives that let you to keep linear order, but make sense of using values before they're created: lazy evaluation, as in Haskell, and dataflow evaluation, as in Oz. Maybe one of those is what you want here. But trying to fit either of those together with mutable objects sensibly is not trivial, nor is it trivial to fit them together with the kind of dynamic OO that Python provides, much less both in one. I'd love to see what someone could come up with by pursuing either of those, but I suspect it wouldn't feel much like Python.