2013/6/17 Éric Araujo :
> Le 17/06/2013 20:49, Benjamin Peterson a écrit :
>> Reading Python coding cookies is outside the purview of TextIOWrapper.
>> However, it would be good to have a function in the stdlib to read a
>> python source file to Unicode; I've definitely implemented that
>> several
Le 17/06/2013 20:49, Benjamin Peterson a écrit :
> Reading Python coding cookies is outside the purview of TextIOWrapper.
> However, it would be good to have a function in the stdlib to read a
> python source file to Unicode; I've definitely implemented that
> several times.
IIUC you want http://d
2013/6/17 Guido van Rossum :
> On Mon, Jun 17, 2013 at 5:02 PM, Benjamin Peterson
> wrote:
>> 2013/6/17 Guido van Rossum :
>>> On Mon, Jun 17, 2013 at 4:40 PM, Benjamin Peterson
>>> wrote:
>>> What exactly does the parser handles better than the io module? Is it
>>> just the coding cookies? I s
On 06/17/2013 05:18 PM, Greg Ewing wrote:
I'm still not convinced that this is necessary or desirable
behaviour. I can understand the parser doing this as a
workaround before we had universal newlines, but now that
we do, I'd expect any Python string to already have newlines
converted to their
It may be possible to implement parsing the codec cookie as a Python codec :-)
Victor
2013/6/18 Guido van Rossum :
> On Mon, Jun 17, 2013 at 5:02 PM, Benjamin Peterson
> wrote:
>> 2013/6/17 Guido van Rossum :
>>> On Mon, Jun 17, 2013 at 4:40 PM, Benjamin Peterson
>>> wrote:
2013/6/17 Gre
On Mon, Jun 17, 2013 at 5:02 PM, Benjamin Peterson wrote:
> 2013/6/17 Guido van Rossum :
>> On Mon, Jun 17, 2013 at 4:40 PM, Benjamin Peterson
>> wrote:
>>> 2013/6/17 Greg Ewing :
Guido van Rossum wrote:
>
> No. Executing a file containing those exact characters produces a
> str
2013/6/17 Guido van Rossum :
> On Mon, Jun 17, 2013 at 4:40 PM, Benjamin Peterson
> wrote:
>> 2013/6/17 Greg Ewing :
>>> Guido van Rossum wrote:
No. Executing a file containing those exact characters produces a
string containing only '\n' and exec/eval is meant to behave the same
>
On Mon, Jun 17, 2013 at 4:40 PM, Benjamin Peterson wrote:
> 2013/6/17 Greg Ewing :
>> Guido van Rossum wrote:
>>>
>>> No. Executing a file containing those exact characters produces a
>>> string containing only '\n' and exec/eval is meant to behave the same
>>> way. The string may not have origina
2013/6/17 Greg Ewing :
> Guido van Rossum wrote:
>>
>> No. Executing a file containing those exact characters produces a
>> string containing only '\n' and exec/eval is meant to behave the same
>> way. The string may not have originated from a file, so the universal
>> newlines behavior of the io m
On Mon, Jun 17, 2013 at 3:18 PM, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
>> No. Executing a file containing those exact characters produces a
>> string containing only '\n' and exec/eval is meant to behave the same
>> way. The string may not have originated from a file, so the universal
>>
Guido van Rossum wrote:
No. Executing a file containing those exact characters produces a
string containing only '\n' and exec/eval is meant to behave the same
way. The string may not have originated from a file, so the universal
newlines behavior of the io module is irrelevant here -- the parser
On 06/17/2013 12:04 PM, Walter Dörwald wrote:
Making the string raw, of course turns it into:
U+0027: APOSTROPHE
U+0027: APOSTROPHE
U+0027: APOSTROPHE
U+005C: REVERSE SOLIDUS
U+0072: LATIN SMALL LETTER R
U+005C: REVERSE SOLIDUS
U+006E: LATIN SMALL LETTER N
U+002
On Mon, Jun 17, 2013 at 10:04 AM, Walter Dörwald wrote:
> I expected that eval()ing a string that contains the characters
>
>U+0027: APOSTROPHE
>U+0027: APOSTROPHE
>U+0027: APOSTROPHE
>U+000D: CR
>U+000A: LR
>U+0027: APOSTROPHE
>U+0027: APOSTROPHE
>U+0027: APOSTROPH
On 17.06.13 19:04, Walter Dörwald wrote:
Hmm, it seems that codecs.unicode_escape_decode() does what I want:
>>> codecs.unicode_escape_decode("\r\n\\r\\n\\x0d\\x0a\\u000d\\u000a")
('\r\n\r\n\r\n\r\n', 26)
Hmm, no it doesn't:
>>> codecs.unicode_escape_decode("\u1234")
('á\x88´', 3)
Servus,
On 14.06.13 23:03, PJ Eby wrote:
On Fri, Jun 14, 2013 at 2:11 PM, Ron Adam wrote:
On 06/14/2013 10:36 AM, Guido van Rossum wrote:
Not a bug. The same is done for file input -- CRLF is changed to LF before
tokenizing.
Should this be the same?
python3 -c 'print(bytes("""\r\n""", "utf8")
On 06/15/2013 03:23 PM, Guido van Rossum wrote:
The semantics of raw strings are clear. I don't see that they should be
called out especially in any context. (Except for regexps.) Usually exec()
is not used with a literal anyway (what would be the point).
There are about a hundred instances
The semantics of raw strings are clear. I don't see that they should be
called out especially in any context. (Except for regexps.) Usually exec()
is not used with a literal anyway (what would be the point).
--Guido van Rossum (sent from Android phone)
On Jun 15, 2013 1:03 PM, "Ron Adam" wrote:
On 06/14/2013 04:03 PM, PJ Eby wrote:
>Should this be the same?
>
>
>python3 -c 'print(bytes("""\r\n""", "utf8"))'
>b'\r\n'
>
>
eval('print(bytes("""\r\n""", "utf8"))')
>b'\n'
No, but:
eval(r'print(bytes("""\r\n""", "utf8"))')
should be. (And is.)
What I believe you and Walter are mi
On 15 June 2013 14:08, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
>> Not a bug. The same is done for file input -- CRLF is changed to LF before
>> tokenizing.
>
>
> I'm not convinced it's reasonable behaviour to re-scan the
> string as though it's being read from a file. It's a Python
> string
Guido van Rossum wrote:
Not a bug. The same is done for file input -- CRLF is changed to LF
before tokenizing.
I'm not convinced it's reasonable behaviour to re-scan the
string as though it's being read from a file. It's a Python
string, so it's already been through whatever line-ending
transfo
On Fri, Jun 14, 2013 at 2:11 PM, Ron Adam wrote:
>
>
> On 06/14/2013 10:36 AM, Guido van Rossum wrote:
>>
>> Not a bug. The same is done for file input -- CRLF is changed to LF before
>> tokenizing.
>
>
>
> Should this be the same?
>
>
> python3 -c 'print(bytes("""\r\n""", "utf8"))'
> b'\r\n'
>
>
On 06/14/2013 10:36 AM, Guido van Rossum wrote:
Not a bug. The same is done for file input -- CRLF is changed to LF before
tokenizing.
Should this be the same?
python3 -c 'print(bytes("""\r\n""", "utf8"))'
b'\r\n'
>>> eval('print(bytes("""\r\n""", "utf8"))')
b'\n'
Ron
On Jun 14, 2
Not a bug. The same is done for file input -- CRLF is changed to LF before
tokenizing.
On Jun 14, 2013 8:27 AM, "Walter Dörwald" wrote:
> Hello all!
>
> This surprised me:
>
>>>> eval("'''\r\n'''")
>'\n'
>
> Where did the \r go? ast.literal_eval() has the same problem:
>
>>>> ast.lite
Hello all!
This surprised me:
>>> eval("'''\r\n'''")
'\n'
Where did the \r go? ast.literal_eval() has the same problem:
>>> ast.literal_eval("'''\r\n'''")
'\n'
Is this a bug/worth fixing?
Servus,
Walter
___
Python-Dev mailing list
Py
24 matches
Mail list logo
