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
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