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 n
On Mon, Jun 25, 2012 at 9:17 PM, 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).
> Workaround:
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
--
http:/
On Jun 18, 2012 8:07 AM, "jmfauth" 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 " should behave
> differently in code source or as an answer to an input().
Strings are a data type th
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
On Jun 20, 11:22 am, Christian Heimes 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.
>
> FYI:http://hg.python.org/cpython/rev/8e47e9af826e
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
--
http://mail.python.org/mailman/listinfo/
On Jun 20, 1:21 am, Steven D'Aprano wrote:
> On Mon, 18 Jun 2012 07:00:01 -0700, jmfauth wrote:
> > On 18 juin, 12:11, Steven D'Aprano > +comp.lang.pyt...@pearwood.info> wrote:
> >> On Mon, 18 Jun 2012 02:30:50 -0700, jmfauth wrote:
> >> > On 18 juin, 10:28, Benjamin Kaplan wrote:
> >> >> The u
On Mon, 18 Jun 2012 07:00:01 -0700, jmfauth wrote:
> On 18 juin, 12:11, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> On Mon, 18 Jun 2012 02:30:50 -0700, jmfauth wrote:
>> > On 18 juin, 10:28, Benjamin Kaplan wrote:
>> >> The u prefix is only there to
>> >> make it easier to port a
On Jun 18, 8:45 pm, Terry Reedy 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
> lit
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 reintroduc
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 "",
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 jm
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):
>>
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 a
> 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
> libra
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
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 "", line 1, in
> SyntaxError: u'a
>
> Er,
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 "", line 1, in
SyntaxError: u'a
Er, no, not really :-)
--
http://mail.python.org/mailman/listinfo/pytho
On Tue, Jun 19, 2012 at 1:44 AM, jmfauth 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 literal formats, bec
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
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
On 06/18/2012 10:00 AM, jmfauth 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 " should behave differently in code source or as an answer
> to an input().
Wrong. The rules for parsi
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'
On 18 juin, 12:11, Steven D'Aprano wrote:
> On Mon, 18 Jun 2012 02:30:50 -0700, jmfauth wrote:
> > On 18 juin, 10:28, Benjamin Kaplan 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
On Mon, 18 Jun 2012 02:30:50 -0700, jmfauth wrote:
> On 18 juin, 10:28, Benjamin Kaplan 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 assuming that Python
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 ch
On 18 juin, 10:28, Benjamin Kaplan wrote:
> On Mon, Jun 18, 2012 at 1:19 AM, jmfauth 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)
> > (, 1)
> ty
On Mon, Jun 18, 2012 at 1:19 AM, jmfauth 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)
> (, 1)
type(r2), len(r2)
> (, 4)
>
> ---
>
> sys.argv?
>
> jmf
Python
29 matches
Mail list logo
