Issue1520294
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2006-07-11 01:45 by barry, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
getset.diff | barry, 2006-07-11 01:45 | |||
types.diff | barry, 2006-07-13 16:05 |
Messages (10) | |||
---|---|---|---|
msg50651 - (view) | Author: Barry A. Warsaw (barry) * | Date: 2006-07-11 01:45 | |
Attributes defined in extension modules via PyGetSetDef aren't instances of property and aren't really handled correctly in the above three modules. This patch adds a types.GetSetterType an inspect.isgetsetter() function, and support for getsetters in pydoc, along with test cases and doc changes. This patch should go into Python 2.5 and part of it should get backported to Python 2.4. Specifically the support for PyGetSetDef in pydoc should be backported, but it should be done in such a way as to not add isgetsetter() or GetSetterType (fairly easy to do as module globals in pydoc.py). Mostly I'm looking for another set of eyes to proof my changes. |
|||
msg50652 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2006-07-11 02:57 | |
Logged In: YES user_id=33168 I haven't looked at the patch, but the name seems a little funny to me due to the lack of parallel names. GetterSetter makes more sense or the current GetSet. |
|||
msg50653 - (view) | Author: Barry A. Warsaw (barry) * | Date: 2006-07-11 03:07 | |
Logged In: YES user_id=12800 Yeah, I went back and forth on that a few times. GetSetter was a poor compromise between GetSet and GetterSetter :) |
|||
msg50654 - (view) | Author: Georg Brandl (georg.brandl) * | Date: 2006-07-11 07:04 | |
Logged In: YES user_id=849994 Why not GetSet? Apart from that, the patch looks fine. |
|||
msg50655 - (view) | Author: Barry A. Warsaw (barry) * | Date: 2006-07-13 16:05 | |
Logged In: YES user_id=12800 Here's an updated patch with several improvements. First, the name is now GetSetType and isgetset(). Also, I've added support for member descriptors with MemberDescriptorType and ismemberdescriptor(). I've also added pydoc help for member descriptors. The appropriate things are done for implementations other than CPython that don't have such extension types. This patch includes the usual docs and tests updates. The other improvement is that rather than relying on accidents of implementation in the C Python interpreter, I've added a built-in _types module which implements specifically the types that are needed. This seems like the best way to ensure that we have accurate types without tying down future development of obscure other modules. This may make it more difficult to backport to Python 2.4, but that's a different concern. Better to DTRT for Python 2.5 first. Assigning back to Georg for another quick review, but feel free to assign it back to me for final checkin (assuming Anthony okays it). |
|||
msg50656 - (view) | Author: Georg Brandl (georg.brandl) * | Date: 2006-07-17 13:17 | |
Logged In: YES user_id=849994 Looks fine, I noticed a few things: - perhaps GetSet should be named GetSetDescriptor for consistency with DataDescriptor and MemberDescriptor - in pydoc, shouldn't "data descriptor" be tested with "inspectisdatadescriptor"? - in the docs, false should be False - test_twelve should now be called test_thirteen ;) and the comment in it should be adapted - is the test suite expected to pass in implementations without the newly tested descriptor types? |
|||
msg50657 - (view) | Author: Barry A. Warsaw (barry) * | Date: 2006-07-19 12:21 | |
Logged In: YES user_id=12800 Thanks for the comments. - I've changed it to GetSetDescriptorType - 'data descriptor' is just what Python itself prints for the type(getset_descriptor) so that's what I chose, but the test should still be with isgetsetdescriptor(). Although it's inconsistent with type(), I changed inspect.py's text to read 'getset descriptor' since I think that's more accurate. - I've changed false to \code{False} in the docs, but libinspect.text uses "true" all over the place. I am not changing that. :) - updated the test and tried to make it pass in other implementations. Since no one else has really commented either for or against, and the RM hasn't pronounced, I'm going to take silence as approval and commit these changes later today. |
|||
msg50658 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2006-07-20 03:18 | |
Logged In: YES user_id=33168 I know that Anthony has been busy. I'm -0 on the patch moreso because of the added _types.c. It's not the code that I have a problem with, but the direction we are going. At various points, we've talked about doing away with types.py. This makes that a bit messier. it's a little like the idea of adding __module_name__ at the last minute. Once this is in, it's next to impossible to remove if incorrect. Also, I'm a little concerned about how this affects other impls (PyPy, IronPython, Jython). Would you mind posting more of the impl details on py-dev and see if anyone still has an opinion? I don't recall any support pro or con. I suspect most don't really care and few people have read the patch. If you mention the impl details, I don't know if that would change anything. What is the impact of waiting? These features have been in since 2.2, right? Also, unlike Tim's threading changes, these can be exposed with a third party extension module can't they? |
|||
msg50659 - (view) | Author: Barry A. Warsaw (barry) * | Date: 2006-07-20 19:28 | |
Logged In: YES user_id=12800 I've posted this to python-dev: http://mail.python.org/pipermail/python-dev/2006-July/067590.html Hope it helps. |
|||
msg50660 - (view) | Author: Barry A. Warsaw (barry) * | Date: 2006-07-27 23:51 | |
Logged In: YES user_id=12800 r50881 for *nix r50885 for Windows |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:18 | admin | set | github: 43646 |
2006-07-11 01:45:07 | barry | create |