[issue14176] Fix unicode literals

Martin v. Löwis added the comment: I propose to close this issue as invalid (although out-of-date might be fine as well). Jean-Michel is apparently unable to describe what issue *precisely* he wants to see fixed, rather than just complaining that open source is a disaster. I don't think we ca

[issue14176] Fix unicode literals

Georg Brandl added the comment: I'd like to encourage you to not try this sort of thing out from an interactive interpreter (incidentally, where does "" come from? It doesn't look like Python's REPL). As David and Terry noted, interactions with such a console, be it Windows' "cmd" or IDLE, h

[issue14176] Fix unicode literals

Jean-Michel Fauth added the comment: 2012/3/3 Terry J. Reedy > > Terry J. Reedy added the comment: > > > That would mean in Python 3, '...' works and u'...' will not work. > > You misunderstand the PEP: in 3.3, '...' and u'...' will be *exactly* the > same. The only change is that the interpr

[issue14176] Fix unicode literals

Terry J. Reedy added the comment: > That would mean in Python 3, '...' works and u'...' will not work. You misunderstand the PEP: in 3.3, '...' and u'...' will be *exactly* the same. The only change is that the interpreter will ignore the u prefix instead of raising SyntaxError. It will be as

[issue14176] Fix unicode literals

Jean-Michel Fauth added the comment: You do not get it or I do not explain it correctly. I do not care if Py 3.3 accepts '...' ou u'...'. I'm only affraid, Py 3.3 is suffering from the same non working behaviour Python 2 is suffering. I have seen so many things... I can only use an Py2/Py3 ana

[issue14176] Fix unicode literals

Terry J. Reedy added the comment: As I explained to J-M when he posted much the same to python-list, Idle's French keyboard support is faulty because tcl/tk's French keyboard support is faulty. A patch for this was recently applied to tcl/tk. I hope it will be in a released version that we ca

[issue14176] Fix unicode literals

R. David Murray added the comment: I'm changing the title since PEP 414 has no bearing here. -- title: Fix unicode literals (for PEP 414) -> Fix unicode literals ___ Python tracker

[issue14176] Fix unicode literals (for PEP 414)

R. David Murray added the comment: OK, so I still don't understand what problem it is you are reporting. What do you mean by "can't craete non-valid strings"? Of course you can't. (I don't see how you could do that programatically, either, although that depends heavily on your definition o

[issue14176] Fix unicode literals (for PEP 414)

Jean-Michel Fauth added the comment: Sorry, I neglected the most important information. Python 3.2 is working perfectly. It is simply impossible to create non valid strings (type/class 'str') from a keyboard. (non programmatically created). Like the limited characters set I used when I wrote m

[issue14176] Fix unicode literals (for PEP 414)

R. David Murray added the comment: Unless I'm misunderstanding, this is a duplicate of issue 1602. You will note that the problem is *not* with Python (or open source software in general), the problem is that Microsoft treats the command line as a second (or third, or fourth) class citizen.

[issue14176] Fix unicode literals (for PEP 414)

Georg Brandl added the comment: Well, let me soothe your mind then: in Python 3, '...' and u'...' will be absolutely equal, so you won't find any more "mess" with the changes from PEP 414. -- nosy: +georg.brandl ___ Python tracker

[issue14176] Fix unicode literals (for PEP 414)

Jean-Michel Fauth added the comment: I deliberately hid the information about the used interactive interpreter; just to show you the "experience" of new Python user. (This is what I'm showing to potential Python devs who are interested in this tool; I know Python and use it since v. 1.5.6 as a n

[issue14176] Fix unicode literals (for PEP 414)

Martin v. Löwis added the comment: What operating system and what terminal are you using? If Windows: what code page does your terminal run in? -- nosy: +loewis ___ Python tracker

[issue14176] Fix unicode literals (for PEP 414)

Changes by Ezio Melotti : -- components: +Unicode -None nosy: +ezio.melotti type: -> behavior ___ Python tracker ___ ___ Python-bugs-

[issue14176] Fix unicode literals (for PEP 414)

Benjamin Peterson added the comment: What exactly is the bug you're reporting? Python 2.7.2 (default, Oct 27 2011, 22:35:02) [GCC 4.5.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print u'abcœé€' abcœé€ -- nosy: +benjamin.peterson ___

[issue14176] Fix unicode literals (for PEP 414)

New submission from Jean-Michel Fauth : Now, that the PEP 414 has been accepted, I can only strongly recommend to fix the problem of unicode literals as a partial workaround. >>> print u'abcœé€' abcé >>> If these six characters are not rendered correctly, you shoud read: LATIN SMALL LETTER A L