| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
I commented more generally at https://discuss.python.org/t/disallow-access-to-class-variables-with-self/105434/8
Sorry, something went wrong.
| ClassB.a # E: Ambigous access | ||
| ClassB.a = ClassB.method1() # E: Ambigous write |
There was a problem hiding this comment.
Are these supposed to be ChildB?
Sorry, something went wrong.
There was a problem hiding this comment.
You are right, this was a typo. My bad, thanks for looking into it!
Sorry, something went wrong.
|
I'm afraid that I don't think this change makes sense as currently worded, and I don't think we should add this to the spec. As shown in my Discuss comment, the soundness issues mentioned as rationale here are unrelated to access via the class. Any inheritance of any mutable attribute typed with Self is unsound even if only ever accessed via instances. In the code sample added to the spec here, the actual unsound line of code is class D(C): pass, not C.others or D.others. It would be controversial to require soundness here, because people use mutable Self attributes and inherit classes containing them. But I don't see the rationale for specifically erroring on access via the class object. (Edit to clarify: by "as currently worded" I mean "if it is worded as a restriction on access via class objects", I don't mean more minor wording changes around how to specify that.) |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
I have tried to create a first draft for disallowing access to variables through the class object containing Self, as discussed here.
The general reception of this proposed change was pretty positive, but I guess we are all not sure how this rule should be worded.
The by far biggest issue is that I write:
where "contains an occurrence of Self" is according to Eric a bit of a new concept. I guess I understand that this is not well defined in the glossary or anywhere else and can of course be used for other things as well. I have tried to skim the Spec and found the following usages in the spec:
There's also two times where "in" is used:
I have not found other language about this. I have tried to search for "depends on", "references", "mentions", "introduces" and none of them are used.
However I feel like this concept is often talked in almost implicit ways about TypeVars/Self. For example in the chapter "Type Parameters as Parameters to Generics" (talks about T1 = TypeVar("T2", default=list[T1])):
I feel like there's a couple of other places where different words are used, but it's not like this concept is new.
Please let me know what you all think. I'm happy to improve the wording.