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/2008-March/077963.html below:

[Python-Dev] Proposal: from __future__ import unicode_string_literals

[Python-Dev] Proposal: from __future__ import unicode_string_literals [Python-Dev] Proposal: from __future__ import unicode_string_literalsEric Smith eric+python-dev at trueblade.com
Thu Mar 20 23:55:01 CET 2008
Following up on a python-3000 discussion about making porting from 2.6 
to 3.0 easier.  Martin suggested making this its own thread.

This proposal is to add "from __future__ import 
unicode_string_literals", which would make all string literals in the 
importing module into unicode objects in 2.6.

This is similar to the -U flag, but would only affect a single module at 
a time.  I think history has shown that -U isn't really usable when 
using any number of modules, including many in the standard library.

There was another proposal from Christian Heimes to add "from __future__ 
import py3k_literals", which would:
1) '' creates an unicode object instead of a str object
2) b'' creates a str object (aka bytes in Python 3.0)
3) 1 creates a long instead of an int
4) 1L and u'' are invalid

2) is already taken care of in 2.6, since: type(b'') == str.  I don't 
think 3) is necessary.  It's an implementation detail.  4) is really two 
issues.  It's my understanding that there's a 2to3 fixer for both of 
these issues.  But I'm open to debate on this.

I'm willing to implement this if there's consensus on it.

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