A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-October/092927.html below:

[Python-Dev] Initialization of __builtins__

[Python-Dev] Initialization of __builtins__ [Python-Dev] Initialization of __builtins__Vinay Sajip vinay_sajip at yahoo.co.uk
Sat Oct 10 22:03:52 CEST 2009
Antoine Pitrou <solipsis <at> 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 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

More information about the Python-Dev mailing list

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