These are chat archives for dropbox/pyston

Mar 2015
Travis Hance
Mar 14 2015 06:33
So… right now we can get the __dict__ of a module, but it’s actually an attrwrapper (or something) instead of a real dict. But we need it to be a real __dict__ for compatability reasons, and also because we need to go the other way and be able to use an arbitrary dict for a module, e.g. if you do exec “a = 5” in some_dict
@kmod thoughts?
(also, I figure we should talk here instead of IM for more open conversation)
Kevin Modzelewski
Mar 14 2015 20:27
hmm have we run into places that changing type(__dict__) breaks anything?
I definitely agree that there's the possibility that someone does something like assert isinstance(__dict__, dict), but in practice I don't think I've seen that yet
there's also some precedent for __dict__ being not a real dict, since I think types have a dictproxy instead
we do have the option of making __dict__ a real dict, but we would have to put some optimization work into that to make it not too slow
so I'm hoping for now we can just keep it an attrwrapper
Travis Hance
Mar 14 2015 22:11
yeah I’m worried about the performance on that
but more important is the use-case for exec
in fact in CPython the globals argument to eval or exec is required to be a dict
Travis Hance
Mar 14 2015 22:53
but whether or not we do exec code in {} or exec code in attrwrapper({}), we need a way to connect the dict-like object to the global scope of the exec’ed code