On Thu, May 24, 2018 at 9:34 PM, Mikhail V wrote:
> Hi.
> I've put some thoughts together, and
> need some feedback on this proposal.
> Main question is: Is it convincing?
> Is there any flaw?
> My own opinion - there IS something to chase.
> Still the justification for such syntax is hard.
>
Th
On Sat, May 26, 2018 at 10:21 PM, Chris Angelico wrote:
>
> I'm done. Argue with brick walls for the rest of eternity if you like.
I see you like me, but I can reciprocate your feelings.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/
On Sun, May 27, 2018 at 5:13 AM, Mikhail V wrote:
> On Sat, May 26, 2018 at 7:10 PM, Steven D'Aprano
>> temp = >>| Mikhail's syntax for {65290} is {65290}
>> Can you see the problem yet? How does your collapse function f()
>> distinguish between the escape code {65290} and the literal string
On Sat, May 26, 2018 at 7:10 PM, Steven D'Aprano
wrote:
> On Sat, 26 May 2018 18:22:15 +0300, Mikhail V wrote:
>
>>> Here is a string assigned to name `s` using Python's current syntax:
>>>
>>> s = "some\ncharacters\0abc\x01\ndef\uFF0A\nhere"
>>>
>>> How do you represent that assignment using your
On Sat, 26 May 2018 18:22:15 +0300, Mikhail V wrote:
>> Here is a string assigned to name `s` using Python's current syntax:
>>
>> s = "some\ncharacters\0abc\x01\ndef\uFF0A\nhere"
>>
>> How do you represent that assignment using your syntax?
>
> Hope its not mandatory to decipher your random exam
On Sat, May 26, 2018 at 10:55 AM, Steven D'Aprano
wrote:
> On Sat, 26 May 2018 08:09:51 +0300, Mikhail V wrote:
>
>> On Fri, May 25, 2018 at 1:15 PM, bartc wrote:
> [...]
>>> One problem here is how to deal with embedded non-printable characters:
>>> CR, LF and TAB might become part of the normal
On Sat, 26 May 2018 08:09:51 +0300, Mikhail V wrote:
> On Fri, May 25, 2018 at 1:15 PM, bartc wrote:
[...]
>> One problem here is how to deal with embedded non-printable characters:
>> CR, LF and TAB might become part of the normal source text, but how
>> about anything else? Or would you only al
On Fri, May 25, 2018 at 1:15 PM, bartc wrote:
> On 25/05/2018 05:34, Mikhail V wrote:
>
> I had one big problem with your proposal, which is that I couldn't make head
> or tail of your syntax. Such a thing should be immediately obvious.
>
> (In your first two examples, what IS the exact string th
On 25/05/2018 05:34, Mikhail V wrote:
Proposal
---
Current proposal suggests adding syntax for the "raw text" statement.
This should enable the possibility to define text pieces in source
code without the need for interpreted characters.
Thereby it should solve the mentioned issues.
Add
In article <7p2juvfu8...@mid.individual.net>,
Gregory Ewing wrote:
>MRAB wrote:
>>
>> In simple cases you might be replacing with the same string every time,
>> but other cases you might want the replacement to contain substrings
>> captured by the regex.
>
>But you can give it a function that ha
On Fri, 18 Dec 2009 17:58:08 -, Alan G Isaac
wrote:
On 12/17/2009 7:59 PM, Rhodri James wrote:
"re.compile('a\\nc')" passes a sequence of four characters to
re.compile: 'a', '\', 'n' and 'c'. re.compile() then does it's own
interpretation: 'a' passes through as is, '\' flags an escape w
On Sat, 19 Dec 2009 02:24:00 +, MRAB wrote:
> Gregory Ewing wrote:
>> MRAB wrote:
>>
>>> In simple cases you might be replacing with the same string every
>>> time, but other cases you might want the replacement to contain
>>> substrings captured by the regex.
>>
>> But you can give it a fun
Gregory Ewing wrote:
MRAB wrote:
In simple cases you might be replacing with the same string every
time, but other cases you might want the replacement to contain
substrings captured by the regex.
But you can give it a function that has access to the match object
and can produce whatever repl
MRAB wrote:
In simple cases you might be replacing with the same string every time,
but other cases you might want the replacement to contain substrings
captured by the regex.
But you can give it a function that has access to the
match object and can produce whatever replacement string
it want
On 12/19/2009 4:59 AM, Alan G Isaac wrote:
On 12/18/2009 12:17 PM, MRAB wrote:
In simple cases you might be replacing with the same string every time,
but other cases you might want the replacement to contain substrings
captured by the regex.
Of course that "conversion" is needed in the repla
On 12/18/2009 12:17 PM, MRAB wrote:
In simple cases you might be replacing with the same string every time,
but other cases you might want the replacement to contain substrings
captured by the regex.
Of course that "conversion" is needed in the replacement.
But e.g. Vim substitutions handle th
On 12/17/2009 7:59 PM, Rhodri James wrote:
"re.compile('a\\nc')" passes a sequence of four characters to
re.compile: 'a', '\', 'n' and 'c'. re.compile() then does it's own
interpretation: 'a' passes through as is, '\' flags an escape which
combined with 'n' produces the newline character (0x0a),
Gregory Ewing wrote:
MRAB wrote:
Regular expressions and replacement strings have their own escaping
mechanism, which also uses backslashes.
This seems like a misfeature to me. It makes sense for a regular
expression to give special meanings to backslash sequences, because
it's a sublanguage
Gregory Ewing wrote:
>MRAB wrote:
>> Regular expressions and replacement strings have their own escaping
>> mechanism, which also uses backslashes.
>This seems like a misfeature to me. It makes sense for
>a regular expression to give special meanings to backslash
>sequences, because it's a sublan
MRAB wrote:
Regular expressions and replacement strings have their own escaping
mechanism, which also uses backslashes.
This seems like a misfeature to me. It makes sense for
a regular expression to give special meanings to backslash
sequences, because it's a sublanguage with its own syntax.
B
On Thu, 17 Dec 2009 20:18:12 -, Alan G Isaac
wrote:
So is the bottom line the following?
A string replacement is not just "converted"
as described in the documentation, essentially
it is compiled?
That depends entirely on what you mean.
But that cannot quite be right. E.g., \b will b
Alan G Isaac wrote:
On 12/17/2009 2:45 PM, MRAB wrote:
re.compile('a\\nc') _does_ compile to the same as regex as
re.compile('a\nc').
However, regex objects never compare equal to each other, so, strictly
speaking, re.compile('a\nc') != re.compile('a\nc').
However, having said that, the re mod
On 12/17/2009 2:45 PM, MRAB wrote:
re.compile('a\\nc') _does_ compile to the same as regex as
re.compile('a\nc').
However, regex objects never compare equal to each other, so, strictly
speaking, re.compile('a\nc') != re.compile('a\nc').
However, having said that, the re module contains a cache
Alan G Isaac wrote:
Alan G Isaac wrote:
>>> re.sub('abc', r'a\nb\n.c\a','123abcdefg') ==
re.sub('abc', 'a\\nb\\n.c\\a','123abcdefg') == re.sub('abc',
'a\nb\n.c\a','123abcdefg')
True
Why are the first two strings being treated as if they are the last one?
On 12/17/2009
Alan G Isaac wrote:
>>> re.sub('abc', r'a\nb\n.c\a','123abcdefg') == re.sub('abc',
'a\\nb\\n.c\\a','123abcdefg') == re.sub('abc', 'a\nb\n.c\a','123abcdefg')
True
Why are the first two strings being treated as if they are the last one?
On 12/17/2009 12:19 PM, D'Arcy J.M.
Alan G Isaac wrote:
On 12/17/2009 11:24 AM, Richard Brodie wrote:
A raw string is not a distinct type from an ordinary string
in the same way byte strings and Unicode strings are. It
is a merely a notation for constants, like writing integers
in hexadecimal.
(r'\n', u'a', 0x16)
('\\n', u'a',
On Thu, 17 Dec 2009 11:51:26 -0500
Alan G Isaac wrote:
> >>> re.sub('abc', r'a\nb\n.c\a','123abcdefg') == re.sub('abc',
> 'a\\nb\\n.c\\a',' 123abcdefg') == re.sub('abc', 'a\nb\n.c\a','123abcdefg')
> True
Was this a straight cut and paste or did you make a manual change? Is
tha
On 12/17/2009 11:24 AM, Richard Brodie wrote:
A raw string is not a distinct type from an ordinary string
in the same way byte strings and Unicode strings are. It
is a merely a notation for constants, like writing integers
in hexadecimal.
(r'\n', u'a', 0x16)
('\\n', u'a', 22)
Yes, that was
"Alan G Isaac" wrote in message
news:qemdnrut0jvj1lfwnz2dnuvz_vqdn...@rcn.net...
> Naturally enough. So I think the right answer is:
>
> 1. this is a documentation bug (i.e., the documentation
>fails to specify unexpected behavior for raw strings), or
> 2. this is a bug (i.e., raw strings
En Wed, 16 Dec 2009 11:09:32 -0300, Ed Keith escribió:
I am having a problem when substituting a raw string. When I do the
following:
re.sub('abc', r'a\nb\nc', '123abcdefg')
I get
"""
123a
b
cdefg
"""
what I want is
r'123a\nb\ncdefg'
On 12/16/2009 9:35 AM, Gabriel Genellina wrote:
Fr
--- On Wed, 12/16/09, Peter Otten <__pete...@web.de> wrote:
> Another possibility:
>
> >>> print re.sub('abc', lambda m: r'a\nb\n.c\a',
> '123abcdefg')
> 123a\nb\n.c\adefg
I'm not sure whether that is clever, ugly, or just plain strange!
I think I'll stick with:
>>> m = re.match('^(.*)abc(.*)
Gabriel Genellina wrote:
> En Wed, 16 Dec 2009 14:51:08 -0300, Peter Otten <__pete...@web.de>
> escribió:
>
>> Ed Keith wrote:
>>
>>> --- On Wed, 12/16/09, Gabriel Genellina wrote:
>>>
Ed Keith
escribió:
> I am having a problem when substituting a raw string.
When I do
En Wed, 16 Dec 2009 14:51:08 -0300, Peter Otten <__pete...@web.de>
escribió:
Ed Keith wrote:
--- On Wed, 12/16/09, Gabriel Genellina wrote:
Ed Keith
escribió:
> I am having a problem when substituting a raw string.
When I do the following:
>
> re.sub('abc', r'a\nb\nc', '123abcdefg')
>
>
Ed Keith wrote:
> --- On Wed, 12/16/09, Gabriel Genellina wrote:
>
>> From: Gabriel Genellina
>> Subject: Re: Raw string substitution problem
>> To: python-list@python.org
>> Date: Wednesday, December 16, 2009, 9:35 AM
>> En Wed, 16 Dec 2009 11:09:32 -0300,
--- On Wed, 12/16/09, Gabriel Genellina wrote:
> From: Gabriel Genellina
> Subject: Re: Raw string substitution problem
> To: python-list@python.org
> Date: Wednesday, December 16, 2009, 9:35 AM
> En Wed, 16 Dec 2009 11:09:32 -0300,
> Ed Keith
> escribió:
>
> &
On Dec 16, 9:09 am, Ed Keith wrote:
> I am having a problem when substituting a raw string. When I do the following:
>
> re.sub('abc', r'a\nb\nc', '123abcdefg')
>
> I get
>
> """
> 123a
> b
> cdefg
> """
>
> what I want is
>
> r'123a\nb\ncdefg'
>
> How do I get what I want?
>
> Thanks,
>
> -Ed
En Wed, 16 Dec 2009 11:09:32 -0300, Ed Keith escribió:
I am having a problem when substituting a raw string. When I do the
following:
re.sub('abc', r'a\nb\nc', '123abcdefg')
I get
"""
123a
b
cdefg
"""
what I want is
r'123a\nb\ncdefg'
From http://docs.python.org/library/re.html#re.sub
MRAB wrote:
In Python 3.x a backslash doesn't have a special meaning in a raw
string, except that it can prevent a following quote from ending the
string, but the backslash is still included. Why? How useful is that? I
think it would've been simpler if a backslash had _no_ special effect,
not ev
andrew cooke wrote:
MRAB wrote:
andrew cooke wrote:
MRAB wrote:
[...]
The other special case is with \u in a Unicode string:
>>> ur"\u0041"
u'A'
this isn't true for 3.0:
r"\u0041"
'\\u0041'
(there's no "u" because it's a string, not a bytes literal)
and as far as i can tell, that's cor
MRAB wrote:
> andrew cooke wrote:
>> MRAB wrote:
>> [...]
>>> The other special case is with \u in a Unicode string:
>>>
>>> >>> ur"\u0041"
>>> u'A'
>>
>> this isn't true for 3.0:
>>
> r"\u0041"
>> '\\u0041'
>>
>> (there's no "u" because it's a string, not a bytes literal)
>>
>> and as far as
andrew cooke wrote:
MRAB wrote:
[...]
The other special case is with \u in a Unicode string:
>>> ur"\u0041"
u'A'
this isn't true for 3.0:
r"\u0041"
'\\u0041'
(there's no "u" because it's a string, not a bytes literal)
and as far as i can tell, that's correct behaviour according to the d
MRAB wrote:
[...]
> The other special case is with \u in a Unicode string:
>
> >>> ur"\u0041"
> u'A'
this isn't true for 3.0:
>>> r"\u0041"
'\\u0041'
(there's no "u" because it's a string, not a bytes literal)
and as far as i can tell, that's correct behaviour according to the docs.
andrew
-
Jim Garrison wrote:
Tim Chase wrote:
>>> r"a\"
SyntaxError: EOL while scanning string literal (, line 1)
It seems the parser is interpreting the backslash as an escape
character in a raw string if the backslash is the last character.
Is this expected?
Yep...as documented[1], "even a raw s
On Thu, Mar 12, 2009 at 3:28 PM, Jim Garrison wrote:
> OK, I'm curious as to the reasoning behind saying that
>
> When an 'r' or 'R' prefix is present, a character following a
> backslash is included in the string without change, and all
> backslashes are left in the string.
>
> which sounds
> > Yep...as documented[1], "even a raw string cannot end in an odd number
> > of backslashes".
>
> So how do you explain this?
>
> >>> r'a\'b'
> "a\\'b"
That doesn't "end in an odd number of backslashes."
Python is __repr__esenting a raw string as a "regular" string.
Literally they
Tim Chase wrote:
>>> r"a\"
SyntaxError: EOL while scanning string literal (, line 1)
It seems the parser is interpreting the backslash as an escape
character in a raw string if the backslash is the last character.
Is this expected?
Yep...as documented[1], "even a raw string cannot end in a
Jim Garrison wrote:
> OK, I'm curious as to the reasoning behind saying that
>
> When an 'r' or 'R' prefix is present, a character following a
> backslash is included in the string without change, and all
> backslashes are left in the string.
>
> which sounds reasonable, but then sa
Jim Garrison wrote:
> >>> r"a\b"
>'a\\b'
> >>> r"a\"
>SyntaxError: EOL while scanning string literal (, line 1)
> >>> r"a\ "
>'a\\ '
> >>> r"a\""
>'a\\"'
>
> It seems the parser is interpreting the backslash as an escape
> character in a raw string if the backslash is th
Tim Chase wrote:
>>> r"a\"
SyntaxError: EOL while scanning string literal (, line 1)
It seems the parser is interpreting the backslash as an escape
character in a raw string if the backslash is the last character.
Is this expected?
Yep...as documented[1], "even a raw string cannot end in a
>>> r"a\"
SyntaxError: EOL while scanning string literal (, line 1)
It seems the parser is interpreting the backslash as an escape
character in a raw string if the backslash is the last character.
Is this expected?
Yep...as documented[1], "even a raw string cannot end in an odd
number of b
On Sep 25, 2:24 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
> Alexandre Badez wrote:
> > I would like to do something like:
>
> > s = r"a\tb\n"
> > print unraw(s) # <= this is the "magic" function I'm searching for
> > # result with
> > ab
> > n
>
> > Does any of you know how to do it properly ?
Alexandre Badez wrote:
> I would like to do something like:
>
> s = r"a\tb\n"
> print unraw(s) # <= this is the "magic" function I'm searching for
> # result with
> ab
> n
>
> Does any of you know how to do it properly ?
>>> print r"a\tb\nx".decode("string-escape")
a b
x
Peter
--
h
On Sep 18, 5:20 am, Konstantinos Pachopoulos <[EMAIL PROTECTED]>
wrote:
> Hi,
> i am trying to execute the following query on a DB:
> qe.execQuery(r"SELECT * FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY
> '"' LINES TERMINATED BY '\n' FROM Commiter")
>
> However, whether i put the r in the front
Konstantinos Pachopoulos wrote:
> Hi,
> i am trying to execute the following query on a DB:
> qe.execQuery(r"SELECT * FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY
> '"' LINES TERMINATED BY '\n' FROM Commiter")
>
> However, whether i put the r in the front or not, i always get an error
> about
On 26 Oct 2005 12:27:53 -0700, "Paul McGuire" <[EMAIL PROTECTED]>
wrote:
>"Raw string fu"? A new martial art?
For the udon-aware.
--dang
--
http://mail.python.org/mailman/listinfo/python-list
"Raw string fu"? A new martial art?
--
http://mail.python.org/mailman/listinfo/python-list
Joshua Ginsberg wrote:
> >>> r'\'
> File "", line 1
> r'\'
> ^
> SyntaxError: EOL while scanning single-quoted string
> >>> r'\\'
> ''
>
> Does that seem wrong to anybody else? Shouldn't the first one be
> syntactically correct?
the "r" prefix doesn't change how string literals are parsed; it
Doh. that example was supposed to be ->
>>> r'I can\'t end strings with a \.'
"I can\\'t end strings with a \\."
On 10/26/05, Jaime Wyant <[EMAIL PROTECTED]> wrote:
> This URL has a good section on raw strings.
>
> http://www.ferg.org/projects/python_gotchas.html
>
> r'\' is wrong because raw stri
This URL has a good section on raw strings.
http://www.ferg.org/projects/python_gotchas.html
r'\' is wrong because raw strings were originally added to make
regular expressions easier to write. And you can't have a regexp that
ends with \.
Also, you can use the \ to escape your original quote c
59 matches
Mail list logo
