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
--
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).
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
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,
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
--
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.
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
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
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
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
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
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).
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
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
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'
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
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
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
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
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 :-)
--
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,
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
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,
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
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,
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
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
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
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
29 matches
Mail list logo