My (very) recent patch #635933 allows assignment to both __name__ and
__bases__ of new-style classes. Given that the code for __bases__ is
much more complicated, it's a little odd that __name__ is the one
still giving me headaches.
It's all to do with dots.
An extension type like (e.g.) time.struct_time is created with a
tp_name of 'time.struct_time' which the accessors for __module__ and
__name__ translate thusly:
>>> time.struct_time.__name__
'struct_time'
>>> time.struct_time.__module__
'time'
User defined new-style classes _seem_ to behave similary:
>>> class C(object):
... pass
...
>>> C.__name__
'C'
>>> C.__module__
'__main__'
but under the hood it's quite different: tp_name is just "C" and
'__module__' is a key in C.__dict__. This shows up when in:
>>> C.__name__ = 'C.D'
>>> C.__name__
'D'
>>> C.__module__
'C'
which isn't really what I would have expected.
What I'd like to do is treat heap types and not-heap types distinctly:
For non-heap types, do as we do today: everything in tp_name up to the
first dot is __module__, the rest is __name__. You can't change
anything here, no worries about that.
For heap types, __module__ is always __dict__['__module__'], __name__
is always tp_name (or rather ((etype*)type)->name).
Comments? I think this is fine, so long as there aren't heap types
that are created by some wierd means that leaves them without
"'__modules__' in t.__dict__".
(If someone does
del t.__dict__['__modules__']
they deserve to lose, but we shouldn't crash. I don't expect this to
be a problem).
Cheers,
M.
--
First time I've gotten a programming job that required a drug
test. I was worried they were going to say "you don't have
enough LSD in your system to do Unix programming". -- Paul Tomblin
-- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4