[Python-Dev] Support for PyGetSetDefs in pydoc
Barry Warsaw
barry at python.org
Thu Jul 13 18:12:28 CEST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Jul 13, 2006, at 9:15 AM, Nick Coghlan wrote:
> Could you include a "look up late-breaking types" function in
> types.py that site.py calls after it finishes setting up the
> standard library path?
>
> Still a little hackish, I know, but it seems less icky than your
> suggestions above, as it means that fixing anything similar that
> comes up in the future will only require modification of types.py.
I've come to the conclusion that it's much better to add a "helper"
module that defines a few extension types solely for the purposes of
exposing them in types.py, than it is to rely on accidents of
implementation discovered in the existing interpreter. To that end,
I've implemented a _typesmodule.c that exposes a getset descriptor
and a member descriptor on a type that can't be instantiated. That
module gets built into Python and provides a central place to add any
future C extension types. It also provides a handy place for Jython
or IronPython to hang their own equivalents, if and when they ever
get them.
Then in types.py, we import _types and pull the appropriate types
from there. types.py will not define GetSetType or
MemberDescriptorType if that module can't be imported so that it's
robust for other Python implementations. I like not defining them
better than setting them to None in that case.
Then inspect.py defines isgetset() and ismemberdescriptor() in terms
of those types, but it always returns False if those types don't
exist. So inspect.py too is robust for other Python implementations.
I've updated SF patch #1520294 and assigned it back to Georg for
another quick review. Assuming he likes the updated patch and
Anthony approves, please assign it back to me for final checkin.
In thinking about this more, re: back porting to Python 2.4, I don't
think we can expose GetSetType, MemberDescriptorType, isgetset(), or
ismemberdescriptor() in the appropriate modules. That smells too
much like the True/False thing. However, I believe I can weedle a
fix into pydoc for those types without exposing these new names, so
I'd like to do that if there are no objections.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iQCVAwUBRLZw8XEjvBPtnXfVAQLkIAP+O0WXh+xO902KNah/kIYy/GSPsO/CfRUO
+YchtF2HdbyEXORwhsLXJVTKVROYgohCQrZp7LUX5vNUah0J0ycIPXhzpqrB0Gmc
8AaRChkFO8EGofzEGOvtunGUGdl9733u2mNUUAhGk15YFs8GDyiuzkL8SitcJQ3q
OHnCsdNRuSU=
=pbA8
-----END PGP SIGNATURE-----
More information about the Python-Dev
mailing list