Re: Py3.3 unicode literal and input()

2012-06-25 Thread jmfauth
Mea culpa. I had not my head on my shoulders. Inputing if working fine, it returns text correctly. However, and this is something different, I'm a little bit surprised, input() does not handle escaped characters (\u, \U). Workaround: encode() and decode() as raw-unicode-escape. jmf --

Re: Py3.3 unicode literal and input()

2012-06-25 Thread Chris Angelico
On Mon, Jun 25, 2012 at 9:17 PM, jmfauth wxjmfa...@gmail.com wrote: Mea culpa. I had not my head on my shoulders. Inputing if working fine, it returns text correctly. However, and this is something different, I'm a little bit surprised, input() does not handle escaped characters (\u, \U).

Re: Py3.3 unicode literal and input()

2012-06-25 Thread Steven D'Aprano
On Mon, 25 Jun 2012 04:17:00 -0700, jmfauth wrote: Mea culpa. I had not my head on my shoulders. Inputing if working fine, it returns text correctly. However, and this is something different, I'm a little bit surprised, input() does not handle escaped characters (\u, \U). No, it is not

Re: Py3.3 unicode literal and input()

2012-06-20 Thread jmfauth
On Jun 20, 1:21 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Mon, 18 Jun 2012 07:00:01 -0700, jmfauth wrote: On 18 juin, 12:11, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Mon, 18 Jun 2012 02:30:50 -0700, jmfauth wrote: On 18 juin, 10:28,

Re: Py3.3 unicode literal and input()

2012-06-20 Thread Christian Heimes
Am 18.06.2012 20:45, schrieb Terry Reedy: The simultaneous reintroduction of 'ur', but with a different meaning than in 2.7, *was* a problem and it should be removed in the next release. FYI: http://hg.python.org/cpython/rev/8e47e9af826e Christian --

Re: Py3.3 unicode literal and input()

2012-06-20 Thread jmfauth
On Jun 20, 11:22 am, Christian Heimes li...@cheimes.de wrote: Am 18.06.2012 20:45, schrieb Terry Reedy: The simultaneous reintroduction of 'ur', but with a different meaning than in 2.7, *was* a problem and it should be removed in the next release.

Re: Py3.3 unicode literal and input()

2012-06-20 Thread Steven D'Aprano
On Wed, 20 Jun 2012 01:12:00 -0700, jmfauth wrote: Python 3.3.0a4 (v3.3.0a4:7c51388a3aa7+, May 31 2012, 20:15:21) [MSC v. 1600 32 bit (Intel)] on win32 --- running smidzero.py... ...smidzero has been executed What is smidzero.py, and what is it doing? --- input(':') :éléphant

Re: Py3.3 unicode literal and input()

2012-06-20 Thread Ian Kelly
On Jun 18, 2012 8:07 AM, jmfauth wxjmfa...@gmail.com wrote: A string is a string, a piece of text, period. I do not see why a unicode literal and an (well, I do not know how the call it) a normal class str should behave differently in code source or as an answer to an input(). Strings are a

Re: Py3.3 unicode literal and input()

2012-06-19 Thread Steven D'Aprano
On Mon, 18 Jun 2012 07:00:01 -0700, jmfauth wrote: On 18 juin, 12:11, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Mon, 18 Jun 2012 02:30:50 -0700, jmfauth wrote: On 18 juin, 10:28, Benjamin Kaplan benjamin.kap...@case.edu wrote: The u prefix is only there to make it

Re: Py3.3 unicode literal and input()

2012-06-18 Thread Benjamin Kaplan
On Mon, Jun 18, 2012 at 1:19 AM, jmfauth wxjmfa...@gmail.com wrote: What is input() supposed to return? u'a' == 'a' True r1 = input(':') :a r2 = input(':') :u'a' r1 == r2 False type(r1), len(r1) (class 'str', 1) type(r2), len(r2) (class 'str', 4) --- sys.argv? jmf Python 3

Re: Py3.3 unicode literal and input()

2012-06-18 Thread jmfauth
On 18 juin, 10:28, Benjamin Kaplan benjamin.kap...@case.edu wrote: On Mon, Jun 18, 2012 at 1:19 AM, jmfauth wxjmfa...@gmail.com wrote: What is input() supposed to return? u'a' == 'a' True r1 = input(':') :a r2 = input(':') :u'a' r1 == r2 False type(r1), len(r1) (class

Re: Py3.3 unicode literal and input()

2012-06-18 Thread Steven D'Aprano
On Mon, 18 Jun 2012 01:19:32 -0700, jmfauth wrote: What is input() supposed to return? Whatever you type. u'a' == 'a' True This demonstrates that in Python 3.3, u'a' gives a string equal to 'a'. r1 = input(':') :a Since you typed the letter a, r1 is the string a (a single character).

Re: Py3.3 unicode literal and input()

2012-06-18 Thread Steven D'Aprano
On Mon, 18 Jun 2012 02:30:50 -0700, jmfauth wrote: On 18 juin, 10:28, Benjamin Kaplan benjamin.kap...@case.edu wrote: The u prefix is only there to make it easier to port a codebase from Python 2 to Python 3. It doesn't actually do anything. It does. I shew it! Incorrect. You are

Re: Py3.3 unicode literal and input()

2012-06-18 Thread jmfauth
On 18 juin, 12:11, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Mon, 18 Jun 2012 02:30:50 -0700, jmfauth wrote: On 18 juin, 10:28, Benjamin Kaplan benjamin.kap...@case.edu wrote: The u prefix is only there to make it easier to port a codebase from Python 2 to Python 3. It

Re: Py3.3 unicode literal and input()

2012-06-18 Thread Andrew Berg
Perhaps this will clear things up: Python 3.3.0a4 (v3.3.0a4:7c51388a3aa7, May 31 2012, 20:17:41) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. ua = u'a' literal_ua = u'a' ua == literal_ua False input_ua = input() u'a' input_ua u'a'

Re: Py3.3 unicode literal and input()

2012-06-18 Thread Dave Angel
On 06/18/2012 10:00 AM, jmfauth wrote: SNIP A string is a string, a piece of text, period. I do not see why a unicode literal and an (well, I do not know how the call it) a normal class str should behave differently in code source or as an answer to an input(). Wrong. The rules for

Re: Py3.3 unicode literal and input()

2012-06-18 Thread Ulrich Eckhardt
Am 18.06.2012 16:00, schrieb jmfauth: A string is a string, a piece of text, period. No. There are different representations for the same piece of text even in the context of just Python. b'fou', u'fou', 'fou' are three different source code representations, resulting in two different runtime

Re: Py3.3 unicode literal and input()

2012-06-18 Thread jmfauth
Thinks are very clear to me. I wrote enough interactive interpreters with all available toolkits for Windows since I know Python (v. 1.5.6). I do not see why the semantic may vary differently in code source or in an interactive interpreter, esp. if Python allow it! If you have to know by advance

Re: Py3.3 unicode literal and input()

2012-06-18 Thread Chris Angelico
On Tue, Jun 19, 2012 at 1:44 AM, jmfauth wxjmfa...@gmail.com wrote: I do not see why the semantic may vary differently in code source or in an interactive interpreter, esp. if Python allow it! When you're asking for input, you usually aren't looking for code. It doesn't matter about string

Re: Py3.3 unicode literal and input()

2012-06-18 Thread Jussi Piitulainen
jmfauth writes: Thinks are very clear to me. I wrote enough interactive interpreters with all available toolkits for Windows r = input() u'a Traceback (most recent call last): File stdin, line 1, in module SyntaxError: u'a Er, no, not really :-) --

Re: Py3.3 unicode literal and input()

2012-06-18 Thread Andrew Berg
On 6/18/2012 11:32 AM, Jussi Piitulainen wrote: jmfauth writes: Thinks are very clear to me. I wrote enough interactive interpreters with all available toolkits for Windows r = input() u'a Traceback (most recent call last): File stdin, line 1, in module SyntaxError: u'a Er, no,

Re: Py3.3 unicode literal and input()

2012-06-18 Thread John Roth
On Monday, June 18, 2012 9:44:17 AM UTC-6, jmfauth wrote: Thinks are very clear to me. I wrote enough interactive interpreters with all available toolkits for Windows since I know Python (v. 1.5.6). I do not see why the semantic may vary differently in code source or in an interactive

Re: Py3.3 unicode literal and input()

2012-06-18 Thread David M Chess
If you (the programmer) want a function that asks the user to enter a literal at the input prompt, you'll have to write a post-processing for it, which looks for prefixes, for quotes, for backslashes, etc., and encodes the result. There very well may be such a decoder in the Python library,

Re: Py3.3 unicode literal and input()

2012-06-18 Thread jmfauth
We are turning in circles. You are somehow legitimating the reintroduction of unicode literals and I shew, not to say proofed, it may be a source of problems. Typical Python desease. Introduce a problem, then discuss how to solve it, but surely and definitivly do not remove that problem. As far

Re: Py3.3 unicode literal and input()

2012-06-18 Thread Dave Angel
On 06/18/2012 12:55 PM, Andrew Berg wrote: On 6/18/2012 11:32 AM, Jussi Piitulainen wrote: jmfauth writes: Thinks are very clear to me. I wrote enough interactive interpreters with all available toolkits for Windows r = input() u'a Traceback (most recent call last): File stdin, line 1,

Re: Py3.3 unicode literal and input()

2012-06-18 Thread Andrew Berg
On 6/18/2012 12:03 PM, Dave Angel wrote: And you're missing the context. jmfauth thinks we should re-introduce the input/raw-input distinction so he could parse literal strings. So Jussi demonstrated that the 2.x input did NOT satisfy fmfauth's dreams. You're right. I missed that part of

Re: Py3.3 unicode literal and input()

2012-06-18 Thread Jussi Piitulainen
Andrew Berg writes: On 6/18/2012 11:32 AM, Jussi Piitulainen wrote: jmfauth writes: Thinks are very clear to me. I wrote enough interactive interpreters with all available toolkits for Windows r = input() u'a Traceback (most recent call last): File stdin, line 1, in module

Re: Py3.3 unicode literal and input()

2012-06-18 Thread Terry Reedy
On 6/18/2012 12:39 PM, jmfauth wrote: We are turning in circles. You are, not we. Please stop. You are somehow legitimating the reintroduction of unicode literals We are not 'reintroducing' unicode literals. In Python 3, string literals *are* unicode literals. Other developers

Re: Py3.3 unicode literal and input()

2012-06-18 Thread jmfauth
On Jun 18, 8:45 pm, Terry Reedy tjre...@udel.edu wrote: On 6/18/2012 12:39 PM, jmfauth wrote: We are turning in circles. You are, not we. Please stop. You are somehow legitimating the reintroduction of unicode literals We are not 'reintroducing' unicode literals. In Python 3, string