Patch review: [ 1009811 ] Add missing types to __builtin__
Last August, James Knight posted to python-dev, "There's a fair number of classes that claim they are defined in __builtin__, but do not actually appear there". There was a discussion and James submitted this patch: http://sourceforge.net/tracker/index.php?func=detail&aid=1009811&group_id=5470&atid=305470 The final result of the discussion is unclear. Guido declared himself +0.5 on the concept, but nobody has reviewed the patch in detail yet. The original email thread starts here: http://mail.python.org/pipermail/python-dev/2004-August/047477.html The patch still applies, and test cases still run OK afterwards. Now that 2.4 has been released it is perhaps a good time to discuss in on python-dev again. If it isn't discussed, then the patch should be closed due to lack of interest. Alan. -- Alan Green alan.green@cardboard.nu - http://cardboard.nu
Last August, James Knight posted to python-dev, "There's a fair number of classes that claim they are defined in __builtin__, but do not actually appear there". There was a discussion and James submitted this patch:
http://sourceforge.net/tracker/index.php?func=detail&aid=1009811&group_i d=
5470&atid=305470
I'm -1 on adding these to __builtin__. They are just distractors and have almost no use in real Python programs. Worse, if you do use them, then you are likely to be programming badly -- we don't want to encourage that. Also, I take some of these, such as dictproxy and cell, to be implementation details that are subject to change. Adding them to __builtin__ would unnecessarily immortalize them.
The final result of the discussion is unclear. Guido declared himself +0.5 on the concept, but nobody has reviewed the patch in detail yet.
Even if Guido were suffering from time machine induced hallucinations that day, he still knew better than to go a full +1. Raymond
Raymond Hettinger wrote:
I'm -1 on adding these to __builtin__. They are just distractors and have almost no use in real Python programs. Worse, if you do use them, then you are likely to be programming badly -- we don't want to encourage that.
I agree. Because of the BDFL pronouncement, I cannot reject the patch, but I won't accept it, either. So it seems that this patch will have to sit in the SF tracker until either Guido processes it, or it is withdrawn. Regards, Martin
On Jan 27, 2005, at 1:20 AM, Martin v. Löwis wrote:
I agree. Because of the BDFL pronouncement, I cannot reject the patch, but I won't accept it, either. So it seems that this patch will have to sit in the SF tracker until either Guido processes it, or it is withdrawn.
If people want to restart this discussion, I'd like to start back with the following message, rather than simply accepting/rejecting the patch. From the two comments so far, it seems like it's not the patch that needs reviewing, but still the concept. On August 10, 2004 12:17:14 PM EDT, I wrote:
Sooo should (for 'generator' in objects that claim to be in __builtins__ but aren't), 1) 'generator' be added to __builtins__ 2) 'generator' be added to types.py and its __module__ be set to 'types' 3) 'generator' be added to <newmodule>.py and its __module__ be set to '<newmodule>' (and a name for the module chosen)
Basically, I'd like to see them be given a binding somewhere, and have their claimed module agree with that, but am not particular as to where. Option #2 seemed to be rejected last time, and option #1 was given approval, so that's what I wrote a patch for. It sounds like it's getting pretty strong "no" votes this time around, however. Therefore, I would like to suggest option #3, with <newmodule> being, say, 'internals'. James
On Thu, 27 Jan 2005 02:01:20 -0500, James Y Knight <foom@fuhm.net> wrote:
Basically, I'd like to see them be given a binding somewhere, and have their claimed module agree with that, but am not particular as to where. Option #2 seemed to be rejected last time, and option #1 was given approval, so that's what I wrote a patch for. It sounds like it's getting pretty strong "no" votes this time around, however. Therefore, I would like to suggest option #3, with <newmodule> being, say, 'internals'.
+1 -- --Guido van Rossum (home page: http://www.python.org/~guido/)
[James Y Knight]
Basically, I'd like to see them be given a binding somewhere, and have their claimed module agree with that, but am not particular as to where. Option #2 seemed to be rejected last time, and option #1 was given approval, so that's what I wrote a patch for. It sounds like it's getting pretty strong "no" votes this time around, however. Therefore, I would like to suggest option #3, with <newmodule> being, say, 'internals'.
[GvR]
+1
That gives them a place to live and doesn't clutter __builtin__. However, it should be named __internals__. The next question is how to document it. My preference is to be clear that it is implementation specific (Jython won't have cell, PyCFunction, and dictproxy types); that it is subject to change between versions (so as not to prematurely immortalize design/implementation accidents); and that they have only esoteric application (99.9% of programs won't need them and should avoid them like the plague). Calling it __internals__ will help emphasize that we are exposing parts of the implementation that were consciously left semi-private or undocumented. Raymond
James Y Knight wrote:
Sooo should (for 'generator' in objects that claim to be in __builtins__ but aren't), 1) 'generator' be added to __builtins__ 2) 'generator' be added to types.py and its __module__ be set to 'types' 3) 'generator' be added to <newmodule>.py and its __module__ be set to '<newmodule>' (and a name for the module chosen)
There are more alternatives: 4) the __module__ of these types could be absent (i.e. accessing __module__ could give an AttributeError) 5) the __module__ could be present and have a value of None 6) anything could be left as is. The __module__ value of these types might be somewhat confusing, but not enough so to justify changing it to any of the alternatives, which might also be confusing (each in their own way).
Basically, I'd like to see them be given a binding somewhere, and have their claimed module agree with that, but am not particular as to where.
I think I cannot agree with this as a goal regardless of the consequences.
Option #2 seemed to be rejected last time, and option #1 was given approval, so that's what I wrote a patch for. It sounds like it's getting pretty strong "no" votes this time around, however. Therefore, I would like to suggest option #3, with <newmodule> being, say, 'internals'.
-1. 'internals' is not any better than 'sys', 'new', or 'types'. It is worse, as new modules are confusing to users - one more thing they have to learn. Regards, Martin
Basically, I'd like to see them be given a binding somewhere, and have their claimed module agree with that, but am not particular as to where.
I think I cannot agree with this as a goal regardless of the consequences.
Other than a vague feeling of completeness is there any reason this needs to be done? Is there anything useful that currently cannot be expressed without this new module? Raymond
Raymond Hettinger wrote:
Other than a vague feeling of completeness is there any reason this needs to be done? Is there anything useful that currently cannot be expressed without this new module?
That I wonder myself, too. Regards, Martin
On Thu, 2005-01-27 at 17:24, "Martin v. Löwis" wrote:
Raymond Hettinger wrote:
Other than a vague feeling of completeness is there any reason this needs to be done? Is there anything useful that currently cannot be expressed without this new module?
That I wonder myself, too.
One reason is correct documentation. If the code is rejected, there should be a patch proposed to remove the erroneous documentation references that indicates things are in __builtins_ when they are in fact not. If they are put into __builtins__, the documentation won't need updating. ;-) -Jeff Rush
participants (6)
-
"Martin v. Löwis" -
Alan Green -
Guido van Rossum -
James Y Knight -
Jeff Rush -
Raymond Hettinger