I am very much against this. The two are not at all like each other. Also, what's the use case?
On Sunday, July 24, 2016, Martin Teichmann <lkb.teichm...@gmail.com> wrote: > Hi list, Hi Nick, > > Sorry for my delayed response, it is summer here... > > > However, phrasing it that way suggest that it's possible we *did* miss > > something in the PEP: we haven't specified whether or not __set_name__ > > should be called when someone does someone does "cls.attr = descr". > > Given the name, I think we *should* call it in that case, and then the > > semantics during class creation are approximately what would happen if > > we actually built up the class attributes as: > > > > for attr, value in cls_ns.items(): > > setattr(cls, attr, value) > > That's a very good point and actually easy to solve: we would just > need to override type.__setattr__ to do so. Actually, it is already > overridden, so we just need to add code to type.__setattr__ to also > call __set_name__. > > One could be of the other standpoint that in your above example it's > the duty of the caller of setattr to also call __set_name__. It would > be pretty easy to add a line in the loop that also calls > __set_owner__. > > Greetings > > Martin > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org <javascript:;> > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido (mobile)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
