Author jeff.allen
Recipients Arfrever, jeff.allen, psykiatris, zyasoft
Date 2018-09-30.15:43:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
On second thoughts ... my understanding of the interaction with __dict__  was incorrect.

I should have added that __delattr__ is the implementation of "del" at the REPL. But I was wrong in that we *do* delete ps* from __dict__, as well as set the field member to PyAttributeDeleted.INSTANCE during a call. However, we start in an inconsistent state with ps1, ps2 in the __dict__ but set to PyAttributeDeleted.

In a regular interactive REPL, observe this:

>>> import sys
>>> 'ps2' in dir(sys)
>>> del sys.ps2
>>> 'ps2' in dir(sys)
>>> sys.ps2 = '::: '
>>> 'ps2' in dir(sys)
False    # This is wrong.

I've set breakpoints in PySystemState.__setattr__ and __delattr__, so I can observe how it goes internally. You see that after mid-sequence above, ps2==PyAttributeDeleted and is absent from the dictionary (as reported by dir()). However, putting a value back in ps2 doesn't put it back in __dict__, which is wrong.

We should either 1. always remove/add to __dict__ on del/set, and always use del/set at the Java level or 2. del/set only the Java member (not __dict__) and then respect PyAttributeDeleted everywhere they crop up. It seems like the idea of PyAttributeDeleted is to do the latter, but __setattr__ is incorrect, and __rawdir__.
Date User Action Args
2018-09-30 15:43:49jeff.allensetmessageid: <>
2018-09-30 15:43:49jeff.allensetrecipients: + jeff.allen, zyasoft, Arfrever, psykiatris
2018-09-30 15:43:49jeff.allenlinkissue2305 messages
2018-09-30 15:43:49jeff.allencreate