Author steven.daprano
Recipients docs@python, graingert, jeff.allen, pablogsal, pitrou, serhiy.storchaka, steven.daprano
Date 2021-10-12.11:03:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20211012110105.GD9984@ando.pearwood.info>
In-reply-to <1634024527.01.0.0254961095934.issue45435@roundup.psfhosted.org>
Content
Jeff makes an excellent point about the docs failing to distinguish 
between language guarantees, implementation guarantees, and things which 
are merely true sometimes.

On the other hand, we only need document what is true *now*, not what 
may be true in some long distant future.

On Tue, Oct 12, 2021 at 07:42:07AM +0000, Jeff Allen wrote:

> 2. In x = L[i], the index and assignment are distinct actions (in 
> today's byte code), allowing L or i to change before x is assigned.

Does that matter though? I think that's a distinction that makes no 
difference.

We know that another thread could change the L or the i before the 
assignment, if they are global. But once the L[i] lookup has occurred, 
it doesn't matter if they change. It's not going to affect what value 
gets bound to the x.

So in a practical sense, we can say that once the lookup L[i] has 
occurred, the binding might as well be atomic. I think that's what the 
entry is trying to say. Have I missed something?

> 3. A compiler (even a CPU) is free to re-order operations and cache 
> values in unguessable ways, on the assumption of a single thread.

The CPU doesn't operate at the level of Python byte code though, and 
there are limits to what the compiler will do. It's not going to reorder 
things in ways that change the semantics of the code (that would be a 
compiler bug). Its not going to reorder this code:

    x = 1
    print(x)
    x = 2

so that "2" gets printed. So I don't see that this objection is 
relevant.

> 4. Code written on these principals is fragile. It only takes the 
> replacement of a built-in with sub-class redefining __getitem__ (to 
> support some worthy aim elsewhere in the code) to invalidate it.

The FAQ entry could be more forceful that it is only talking about 
certain built-in types, and once you change things to another type, the 
promises may no longer hold.

But we should not hold it against the FAQs that the promises made about 
one type don't apply to other types.

> 5. sort() is not atomic if an element is of a type that overrides 
> comparison in Python. (Nor is modifying a dictionary if __hash__ or 
> __eq__ are redefined.)

Indeed, and the FAQ should be more forceful about that proviso.
History
Date User Action Args
2021-10-12 11:03:31steven.dapranosetrecipients: + steven.daprano, pitrou, docs@python, serhiy.storchaka, jeff.allen, graingert, pablogsal
2021-10-12 11:03:31steven.dapranolinkissue45435 messages
2021-10-12 11:03:31steven.dapranocreate