Initialization of __builtins__
I'm not top-posting, but gmane is giving me a hard time :-(
In the py3k branch, logging has the line _unicode = 'unicode' in dir(__builtins__) to determine the existence of Unicode support. The code in trunk, being 1.5.2 compatible, used hasattr(types, 'UnicodeType') I wanted to eliminate the types import and modernise the trunk code a bit, so I copied the py3k line to the trunk version of logging. It didn't work as expected! So I added the line print dir(__builtins__) in logging fairly early on (though not the very first line - just after the __date__ = ... line. Here's what I got with 2.7a0 and 2.6.1: Python 2.7a0 (trunk:75292M, Oct 9 2009, 09:21:05) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import logging ['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__', '__hash__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', 'clear', 'copy', 'fromkeys', 'get', 'has_key', 'items', 'iteritems', 'iterkeys', 'itervalues', 'keys', 'pop', 'popitem', 'setdefault', 'update', 'values']
ActivePython 2.6.1.1 (ActiveState Software Inc.) based on Python 2.6.1 (r261:67515, Dec 5 2008, 13:58:38) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import logging ['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__', '__hash__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', 'clear', 'copy', 'fromkeys', 'get', 'has_key', 'items', 'iteritems', 'iterkeys', 'itervalues', 'keys', 'pop', 'popitem', 'setdefault', 'update', 'values']
However, if I just do dir(__builtins__) in the interactive prompt, I get the whole shebang. Excuse my ignorance, but how come? Regards, Vinay Sajip
Vinay Sajip
In the py3k branch, logging has the line
_unicode = 'unicode' in dir(__builtins__)
Why do you do this? In py3k, unicode is always enabled but it's called "str" and the name "unicode" doesn't exist.
to determine the existence of Unicode support. The code in trunk, being 1.5.2 compatible, used
hasattr(types, 'UnicodeType')
Why don't you simply write: unicode_support = True try: unicode except NameError: unicode_support = False ?
Antoine Pitrou
Why do you do this? In py3k, unicode is always enabled but it's called "str" and the name "unicode" doesn't exist.
That wasn't done by me but by GvR (according to svn annotate) in r55818, presumably during the stdlib porting to py3k. I just copied the line over, not thinking it wouldn't work for 2.7.
Why don't you simply write:
unicode_support = True try: unicode except NameError: unicode_support = False
That's just about what I've actually done: I was just curious about the difference between py3k and trunk :-) If __builtins__ is an implementation detail which can't be relied on, should the py3k code be changed to the try: form? Or shall I just remove the checks altogether, since Unicode should always be there in 3.x? Regards, Vinay Sajip
Vinay Sajip wrote:
If __builtins__ is an implementation detail which can't be relied on, should the py3k code be changed to the try: form? Or shall I just remove the checks altogether, since Unicode should always be there in 3.x?
Remember that the identifier "unicode" isn't present in py3k. There it's "str" and it holds Unicode strings. Unless you're trying to keep the code identical in both branches, I'd just remove the check in py3k and assume str is what you always want to use. Eric.
participants (4)
-
Antoine Pitrou -
Benjamin Peterson -
Eric Smith -
Vinay Sajip