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.
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.
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 <vinay_sajip <at> yahoo.co.uk> writes:
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.
Why don't you simply write: unicode_support = True try: unicode except NameError: unicode_support = False ?
Antoine Pitrou <solipsis <at> pitrou.net> writes:
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.
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 <vinay_sajip <at> yahoo.co.uk> writes:
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.
Why don't you simply write: unicode_support = True try: unicode except NameError: unicode_support = False ?
Antoine Pitrou <solipsis <at> pitrou.net> writes:
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.
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
participants (4)
-
Antoine Pitrou -
Benjamin Peterson -
Eric Smith -
Vinay Sajip