Barry Warsaw wrote: > Why did I do this instead of trying to hunt down some existing getset > or member descriptor? For one thing, there really aren't very good > candidates for such objects in the built-in modules. You can't use > objects like datetime.timedelta.days in types.py because datetime is > not importable early enough for types.py to use it. Even if there > were likely candidates, they would be accidents of implementation and > it doesn't seem like a good idea to force force some future datetime > maintainer to have to fix types.py when she decides that > datetime.timedelta.days should be implemented in some other way. > > A 3rd party extension module doesn't work either because you really > need the tie-in from types.py, inspect.py, and pydoc.py. You > certainly don't want to go poking new values into types.py from the > outside, and besides inspect.py and pydoc.py also need to learn about > these fundamental built-in Python types. > > ISTM the most straightforward approach is to provide these types in a > built-in C module, linked into the interpreter so types.py can get > access to it as early as it needs to. Also, because the type that > these descriptors are attached to cannot be instantiated from Python, > they should be quite benign, existing only in order to give type() > something to query.
Perhaps you could put the objects into _testcapi. That way no new module has to be deployed (is _testcapi installed on every system?) Georg _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
