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. The
Antoine Pitrou pitrou.net> writes:
> 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 t
Vinay Sajip 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.
> to determine the existence of Unicode support. The co
2009/10/10 Vinay Sajip :
> Excuse my ignorance, but how come?
Because __builtins__ is a module in __main__ and a dict in other
places. You should always check __builtin__; __builtins__ is an
implementation detail.
--
Regards,
Benjamin
___
Python-Dev m
>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
