Home Original page

[Python-Dev] PEP 549 v2: now titled Instance Descriptors

Ethan Furman ethan at stoneleaf.us
Fri Sep 8 17:26:47 EDT 2017 
On 09/08/2017 01:45 PM, Ethan Furman wrote:

> I will admit I don't see what reassigning the __class__ attribute on a module did for us.

Nathaniel Smith wrote:
---------------------
 > If you have an existing package that doesn't replace itself in
 > sys.modules, then it's difficult and risky to switch to that form --
 > don't think of toy examples, think of django/__init__.py or
 > numpy/__init__.py. You have to rewrite the whole export logic, and you
 > have to figure out what to do with things like submodules that import
 > from the parent module before the swaparoo happens, you can get skew
 > issues between the original module namespace and the replacement class
 > namespace, etc. The advantage of the __class__ assignment trick (as
 > compared to what we had before) is that it lets you easily and safely
 > retrofit this kind of magic onto existing packages.

Ah, that makes sense.

Larry Hastings wrote:
---------------------
 > Assigning the module's __class__ means you can otherwise initialize your module instance
 > normally--all your class needs to do is declare your properties or magic methods.  If you
 > overwrite the sys.modules entry for your module with a new instance of a custom subclass,
 > all your module initialization needs to be done within--or propagated to--the new class
 > or instance.

So with the module level __class__ we have to use two steps to get what we want, and PEP 549 takes it back to one step. 
  Hmm.  In theory it sounds cool; on the other hand, the existing __class__ assignment method means all the magic is in 
one place in the module, not scattered around -- but that's a style issue.

Thanks for the info!

--
~Ethan~
More information about the Python-Dev mailing list