On 23.02.15 04:55, Chris Angelico wrote:
I agree, the fault is primarily with Windows. But I've seen similar
issues when people use /-\| for box drawing and framing and such;
Windows paths are by far the most common case of this, but not the
sole.
There is also issues with regular expressions.
Ben Finney wrote:
Chris Angelico ros...@gmail.com writes:
That said, though, there's probably a lot of code out there that
depends on backslashes being non-special, so it's quite probably
something that can't be changed. But it'd be nice to be able to turn
on a warning for it.
If you're
On 02/22/2015 09:29 PM, Chris Angelico wrote:
In Python, unrecognized escape sequences are treated literally,
without (as far as I can tell) any sort of warning or anything. This
can mask bugs, especially when Windows path names are used:
'C:\sqlite\Beginner.db'
'C:\\sqlite\\Beginner.db'
On 02/22/2015 09:41 PM, Ben Finney wrote:
Chris Angelico ros...@gmail.com writes:
In Python, unrecognized escape sequences are treated literally,
without (as far as I can tell) any sort of warning or anything.
Right. Text strings literals are documented to work that way
On Mon, Feb 23, 2015 at 1:41 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Right. Text strings literals are documented to work that way
URL:https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str,
which refers the reader to the language reference
Chris Angelico ros...@gmail.com writes:
In Python, unrecognized escape sequences are treated literally,
without (as far as I can tell) any sort of warning or anything.
Right. Text strings literals are documented to work that way
On Mon, Feb 23, 2015 at 1:41 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Chris Angelico ros...@gmail.com writes:
Why is it that Python interprets them this way, and doesn't even give
a warning?
Because the interpretation of those literals is unambiguous and correct.
And it also implies
Chris Angelico ros...@gmail.com writes:
That said, though, there's probably a lot of code out there that
depends on backslashes being non-special, so it's quite probably
something that can't be changed. But it'd be nice to be able to turn
on a warning for it.
If you're motivated to see such
In Python, unrecognized escape sequences are treated literally,
without (as far as I can tell) any sort of warning or anything. This
can mask bugs, especially when Windows path names are used:
'C:\sqlite\Beginner.db'
'C:\\sqlite\\Beginner.db'
'c:\sqlite\beginner.db'
'c:\\sqlite\x08eginner.db'
On 12/26/2011 12:04 PM, Felipe O wrote:
Hi all,
Whenever I take any input (raw_input, of course!) or I read from a
file, etc., any backslashes get escaped automatically.
Python never escapes backslashes when reading from raw_input or files.
Python only ever escapes backslashes when displaying
obscure backslash escapes or other tricks I should be aware of?
I guess the alternative is to make a dictionary of all the escapes I
want to support, but that sounds tedious and error-prone.
Thanks,
Felipe
--
http://mail.python.org/mailman/listinfo/python-list
from an
unfriendly source.
+ Are there any obscure backslash escapes or other tricks I should be aware of?
I guess the alternative is to make a dictionary of all the escapes I
want to support, but that sounds tedious and error-prone.
Try input_string.decode(string-escape) if input_string
in parts)
I'm not entirely convinced that it's safe on two accounts.
+ Is that eval statement safe? The input could be coming from an
unfriendly source.
+ Are there any obscure backslash escapes or other tricks I should be aware
of?
I guess the alternative is to make a dictionary of all
string... I guess the alternative is to make a dictionary of all the
escapes I
want to support, but that sounds tedious and error-prone.
The question really is: Are you looking to support some backslash
escapes, or are you looking to imitate Python? If the former, I
recommend making a specific list
Ron Adam added the comment:
It looks like the disabling of \u and \U in raw strings is done. Does
tokenize.py need to be fixed, to match?
While working on this I was able to clean up the string parsing parts of
tokenize.c, and have a separate patch with just that.
And an updated patch with
Changes by Ron Adam:
Added file: http://bugs.python.org/file8763/no_raw_escapes_patch.diff
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1720390
_
___
Python-bugs-list
Guido van Rossum added the comment:
I don't think tokenizer.py needs to be changed -- it never interpreted
backslashes in string literals anyway (not even in regular, non-raw
literals).
The tokenizer.c cleanup is submitted as revision 59007.
I still am not warming up towards the no-raw-escapes
Christian Heimes added the comment:
Can you create a new patch and verify that the problem still exists?
norawescape3.diff doesn't apply cleanly any more.
--
nosy: +tiran
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1720390
Ron Adam added the comment:
Yes, I will update it.
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1720390
_
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
FWIW, I'm +1 on the part of this patch that disables \u in raw strings.
I just had a problem with a doctest that couldn't be run in verbose mode
because \u was being interpreted in raw mode... But I'm still solidly
-1 on allowing trailing \.
Changes by Guido van Rossum:
--
versions: +Python 3.0
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1720390
_
___
Python-bugs-list mailing list
Unsubscribe:
21 matches
Mail list logo
