[Python-Dev] Re: What to do about invalid escape sequences

On 15/08/2019 12:17:36, Petr Viktorin wrote: On 8/15/19 10:40 AM, Greg Ewing wrote: If we want a truly raw string format that allows all characters, including any kind of quote, we could take a tip from Fortran: s = 31HThis is a "totally raw" string! Or from Rust: let s = r"Here's a

[Python-Dev] Re: What to do about invalid escape sequences

On 8/15/2019 4:17 AM, Petr Viktorin wrote: On 8/15/19 10:40 AM, Greg Ewing wrote: If we want a truly raw string format that allows all characters, including any kind of quote, we could take a tip from Fortran: s = 31HThis is a "totally raw" string! Or from Rust: let s = r"Here's a raw

[Python-Dev] Re: What to do about invalid escape sequences

On 8/15/19 10:40 AM, Greg Ewing wrote: If we want a truly raw string format that allows all characters, including any kind of quote, we could take a tip from Fortran:     s = 31HThis is a "totally raw" string! Or from Rust: let s = r"Here's a raw string"; let s = r#"Here's a raw string with

[Python-Dev] Re: What to do about invalid escape sequences

If we want a truly raw string format that allows all characters, including any kind of quote, we could take a tip from Fortran: s = 31HThis is a "totally raw" string! -- Greg ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send

[Python-Dev] Re: What to do about invalid escape sequences

On 8/14/2019 8:02 AM, Random832 wrote: On Mon, Aug 12, 2019, at 15:15, Terry Reedy wrote: Please no more combinations. The presence of both legal and illegal combinations is already a mild nightmare for processing and testing. idlelib.colorizer has the following re to detest legal combinations

[Python-Dev] Re: What to do about invalid escape sequences

On 8/14/2019 11:02 AM, Random832 wrote: On Mon, Aug 12, 2019, at 15:15, Terry Reedy wrote: Please no more combinations. The presence of both legal and illegal combinations is already a mild nightmare for processing and testing. idlelib.colorizer has the following re to detest legal

[Python-Dev] Re: What to do about invalid escape sequences

On Mon, Aug 12, 2019, at 15:15, Terry Reedy wrote: > Please no more combinations. The presence of both legal and illegal > combinations is already a mild nightmare for processing and testing. > idlelib.colorizer has the following re to detest legal combinations > > stringprefix =

[Python-Dev] Re: What to do about invalid escape sequences

12.08.19 22:51, Glenn Linderman пише: On 8/12/2019 12:11 AM, Serhiy Storchaka wrote: For example, in many cases `\"` can be replaced with `"'"'r"`, but it does not look pretty readable. No, that is not readable.  But neither does it seem to be valid syntax, or else I'm not sure what you are

[Python-Dev] Re: What to do about invalid escape sequences

On 2019-08-10, Serhiy Storchaka wrote: > Actually we need to distinguish the the author and the user of the code and > show warnings only to the author. Using .pyc files was just an heuristic: > the author compiles the Python code, and the user uses compiled .pyc files. > Would be nice to have

[Python-Dev] Re: What to do about invalid escape sequences

On 8/12/2019 12:11 AM, Serhiy Storchaka wrote: 11.08.19 23:07, Glenn Linderman пише: On 8/11/2019 1:26 AM, Serhiy Storchaka wrote: 10.08.19 22:10, Glenn Linderman пише: I wonder how many raw strings actually use the \"  escape productively? Maybe that should be deprecated too! ?  I can't

[Python-Dev] Re: What to do about invalid escape sequences

On 8/12/2019 6:34 AM, Eric V. Smith wrote: On 8/12/2019 2:52 AM, Greg Ewing wrote: Eric V. Smith wrote: I'm not in any way serious about this. I just want people to realize how many wacky combinations there would be. It doesn't matter how many combinations there are, as long as multiple

[Python-Dev] Re: What to do about invalid escape sequences

On 8/7/2019 6:57 PM, raymond.hettin...@gmail.com wrote: For me, these warnings are continuing to arise almost daily. See two recent examples below. Both examples are fragile, as explained below. They make me more in favor of no longer guessing what \ means in the default mode. The

[Python-Dev] Re: What to do about invalid escape sequences

On Mon, Aug 12, 2019 at 6:26 PM Terry Reedy wrote: > On 8/8/2019 5:31 AM, Dima Tisnek wrote: > [...] > > To me, this one of the major problems with the half-baked default. > People who want string literals left as is sometimes get away with > omitting explicit mention of that fact, but sometimes

[Python-Dev] Re: What to do about invalid escape sequences

On 8/8/2019 5:31 AM, Dima Tisnek wrote: These two ought to be converted to raw strings, shouldn't they? For the first example, yes or no. It depends ;-) See below. The problem is that string literals in python code are, by default, half-baked. The interpretation of '\' by the python

[Python-Dev] Re: What to do about invalid escape sequences

On 10Aug2019 1544, Glenn Linderman wrote: On 8/10/2019 3:36 PM, Greg Ewing wrote: It might be better to introduce a new string prefix, e.g. 'v' for 'verbatim':    v"C:\Users\Fred\" Which is why I suggested  rr"C:\directory\", but allowed as how there might be better spellings I like your 

[Python-Dev] Re: What to do about invalid escape sequences

On 8/12/2019 2:52 AM, Greg Ewing wrote: Eric V. Smith wrote: I'm not in any way serious about this. I just want people to realize how many wacky combinations there would be. It doesn't matter how many combinations there are, as long as multiple prefixes combine in the way you would expect,

[Python-Dev] Re: What to do about invalid escape sequences

11.08.19 23:07, Glenn Linderman пише: On 8/11/2019 1:26 AM, Serhiy Storchaka wrote: 10.08.19 22:10, Glenn Linderman пише: I wonder how many raw strings actually use the \"  escape productively? Maybe that should be deprecated too! ?  I can't think of a good and necessary use for it, can

[Python-Dev] Re: What to do about invalid escape sequences

Eric V. Smith wrote: I'm not in any way serious about this. I just want people to realize how many wacky combinations there would be. It doesn't matter how many combinations there are, as long as multiple prefixes combine in the way you would expect, which they do as far as I can see. -- Greg

[Python-Dev] Re: What to do about invalid escape sequences

On 8/11/2019 8:40 PM, Eric V. Smith wrote: On 8/11/2019 4:18 PM, Glenn Linderman wrote: On 8/11/2019 2:50 AM, Steven D'Aprano wrote: On Sat, Aug 10, 2019 at 12:10:55PM -0700, Glenn Linderman wrote: Or invent "really raw" in some spelling, such as rr"c:\directory\" or e for exact, or x for

[Python-Dev] Re: What to do about invalid escape sequences

On 8/11/2019 4:18 PM, Glenn Linderman wrote: On 8/11/2019 2:50 AM, Steven D'Aprano wrote: On Sat, Aug 10, 2019 at 12:10:55PM -0700, Glenn Linderman wrote: Or invent "really raw" in some spelling, such as rr"c:\directory\" or e for exact, or x for exact, or "c:\directory\" And that brings me

[Python-Dev] Re: What to do about invalid escape sequences

On 8/11/2019 2:50 AM, Steven D'Aprano wrote: On Sat, Aug 10, 2019 at 12:10:55PM -0700, Glenn Linderman wrote: Or invent "really raw" in some spelling, such as rr"c:\directory\" or e for exact, or x for exact, or "c:\directory\" And that brings me to the thought that if   \e  wants to become

[Python-Dev] Re: What to do about invalid escape sequences

On 8/11/2019 1:26 AM, Serhiy Storchaka wrote: 10.08.19 22:10, Glenn Linderman пише: As pointed out elsewhere, Raw strings have limitations, paths ending in \ cannot be represented, and such do exist in various situations, not all of which can be easily avoided... except by the "extra

[Python-Dev] Re: What to do about invalid escape sequences

On Sun, 11 Aug 2019 at 03:37, Rob Cliffe via Python-Dev wrote: > Usually, but not always. I have not infrequently used files with a > blank extension. > I can't recall using a directory name with an extension (but I can't > swear that I never have). I've often seen directory names like "1.

[Python-Dev] Re: What to do about invalid escape sequences

On Sat, Aug 10, 2019 at 12:10:55PM -0700, Glenn Linderman wrote: > Or invent "really raw" in some spelling, such as rr"c:\directory\" > or e for exact, or x for exact, or here>"c:\directory\" > > And that brings me to the thought that if   \e  wants to become an > escape for escape, that maybe

[Python-Dev] Re: What to do about invalid escape sequences

On 8/10/2019 10:30 PM, Rob Cliffe via Python-Dev wrote: On 10/08/2019 23:30:18, Greg Ewing wrote: Rob Cliffe via Python-Dev wrote: Also, the former is simply more *informative* - it tells the reader that baz is expected to be a directory, not a file. On Windows you can usually tell that

[Python-Dev] Re: What to do about invalid escape sequences

10.08.19 22:10, Glenn Linderman пише: As pointed out elsewhere, Raw strings have limitations, paths ending in \ cannot be represented, and such do exist in various situations, not all of which can be easily avoided... except by the "extra character contortion" of   "C:\directory\ "[:-1]  (does

[Python-Dev] Re: What to do about invalid escape sequences

On 10/08/2019 23:30:18, Greg Ewing wrote: Rob Cliffe via Python-Dev wrote: Also, the former is simply more *informative* - it tells the reader that baz is expected to be a directory, not a file. On Windows you can usually tell that from the fact that filenames almost always have an

[Python-Dev] Re: What to do about invalid escape sequences

On 8/10/2019 3:36 PM, Greg Ewing wrote: Glenn Linderman wrote: I wonder how many raw strings actually use the \"  escape productively? Maybe that should be deprecated too! ?  I can't think of a good and necessary use for it, can anyone? Quite rare, I expect, but it's bound to break

[Python-Dev] Re: What to do about invalid escape sequences

Glenn Linderman wrote: I wonder how many raw strings actually use the \" escape productively? Maybe that should be deprecated too! ? I can't think of a good and necessary use for it, can anyone? Quite rare, I expect, but it's bound to break someone's code. It might be better to introduce

[Python-Dev] Re: What to do about invalid escape sequences

Rob Cliffe via Python-Dev wrote: Also, the former is simply more *informative* - it tells the reader that baz is expected to be a directory, not a file. On Windows you can usually tell that from the fact that filenames almost always have an extension, and directory names almost never do. --

[Python-Dev] Re: What to do about invalid escape sequences

On 8/10/19, Rob Cliffe via Python-Dev wrote: > On 10/08/2019 11:50:35, eryk sun wrote: >> On 8/9/19, Steven D'Aprano wrote: >>> I'm also curious why the string needs to *end* with a backslash. Both of >>> these are the same path: >>> >>> C:\foo\bar\baz\ >>> C:\foo\bar\baz > > Also, the

[Python-Dev] Re: What to do about invalid escape sequences

On 8/10/2019 12:19 PM, Guido van Rossum wrote: Regular expressions. I assume that is in response to the "good use for \" escape" question? But can't you just surround them with ' instead of " ?  Or  ''' ? On Sat, Aug 10, 2019 at 12:12 Glenn Linderman >

[Python-Dev] Re: What to do about invalid escape sequences

Regular expressions. On Sat, Aug 10, 2019 at 12:12 Glenn Linderman wrote: > On 8/10/2019 11:16 AM, Terry Reedy wrote: > > On 8/10/2019 4:33 AM, Paul Moore wrote: > > (Side issue) > > > This deserves its own thread. > > As a Windows developer, who has seen far too many cases where use of >

[Python-Dev] Re: What to do about invalid escape sequences

On 8/10/2019 11:16 AM, Terry Reedy wrote: On 8/10/2019 4:33 AM, Paul Moore wrote: (Side issue) This deserves its own thread. As a Windows developer, who has seen far too many cases where use of slashes in filenames implies a Unix-based developer not thinking sufficiently about Windows

[Python-Dev] Re: What to do about invalid escape sequences

On 10/08/2019 11:50:35, eryk sun wrote: On 8/9/19, Steven D'Aprano wrote: I'm also curious why the string needs to *end* with a backslash. Both of these are the same path: C:\foo\bar\baz\ C:\foo\bar\baz Also, the former is simply more *informative* - it tells the reader that baz

[Python-Dev] Re: What to do about invalid escape sequences

On 8/10/2019 4:33 AM, Paul Moore wrote: (Side issue) This deserves its own thread. As a Windows developer, who has seen far too many cases where use of slashes in filenames implies a Unix-based developer not thinking sufficiently about Windows compatibility, or where it leads to people hard

[Python-Dev] Re: What to do about invalid escape sequences

On 8/10/2019 7:03 AM, Paul Moore wrote: On Sat, 10 Aug 2019 at 12:06, Chris Angelico wrote: On Sat, Aug 10, 2019 at 6:39 PM Paul Moore wrote: There are *many* valid ways to write Windows pathnames in your code: 1. Raw strings 2. Doubling the backslashes 3. Using pathlib (possibly with slash

[Python-Dev] Re: What to do about invalid escape sequences

On Sat, 10 Aug 2019 at 12:06, Chris Angelico wrote: > > On Sat, Aug 10, 2019 at 6:39 PM Paul Moore wrote: > > There are *many* valid ways to write Windows pathnames in your code: > > > > 1. Raw strings > > 2. Doubling the backslashes > > 3. Using pathlib (possibly with slash as a directory

[Python-Dev] Re: What to do about invalid escape sequences

On 8/10/19, eryk sun wrote: > > The per-logon directory is located at "\\Sessions\\0\\DosDevices\\ Session ID>". In the Windows API, it's accessible as "//?/" or "//./", > or with any mix of forward slashes or backslashes, but only the > all-backslash form is special-cased to bypass the

[Python-Dev] Re: What to do about invalid escape sequences

On 06/08/2019 23:41:25, Greg Ewing wrote: Rob Cliffe via Python-Dev wrote: Sorry, that won't work.  Strings are parsed at compile time, open() is executed at run-time. It could check for control characters, which are probably the result of a backslash accident. Maybe even auto-correct

[Python-Dev] Re: What to do about invalid escape sequences

On Sat, Aug 10, 2019 at 6:39 PM Paul Moore wrote: > There are *many* valid ways to write Windows pathnames in your code: > > 1. Raw strings > 2. Doubling the backslashes > 3. Using pathlib (possibly with slash as a directory separator, where > it's explicitly noted as a portable option) > 4.

[Python-Dev] Re: What to do about invalid escape sequences

On 8/9/19, Steven D'Aprano wrote: > > I'm also curious why the string needs to *end* with a backslash. Both of > these are the same path: > > C:\foo\bar\baz\ > C:\foo\bar\baz The above two cases are equivalent. But that's not the case for the root directory. Unlike Unix, filesystem

[Python-Dev] Re: What to do about invalid escape sequences

On Sat, 10 Aug 2019 at 00:36, Steven D'Aprano wrote: > 2. To strongly discourage newbie Windows developers from hard-coding > paths using backslashes, but to use forward slashes instead. (Side issue) As a Windows developer, who has seen far too many cases where use of slashes in filenames

[Python-Dev] Re: What to do about invalid escape sequences

While not a total solution, it seems like it might be worthwhile forcing flake8 or similar checks when uploading PyPI modules. That would catch the illegal escape sequences where it really matters - before they enter the ecosystem. (general) fathead:pyxll-www sholden$ cat t.py "Docstring with

[Python-Dev] Re: What to do about invalid escape sequences

10.08.19 02:04, Gregory P. Smith пише: I've merged the PR reverting the behavior in 3.8 and am doing the same in the master branch. I was going to rebase it to master and go in normal backporting process if we decide that DeprecationWarning should be in master. I waited the end of the

[Python-Dev] Re: What to do about invalid escape sequences

09.08.19 19:39, Steve Dower пише: I also posted another possible option that helps solve the real problem faced by users, and not just the "we want to have a warning" problem that is purely ours. Warnings solve two problems: * Teaching users that a backslash has special meaning and should be

[Python-Dev] Re: What to do about invalid escape sequences

On 8/9/2019 3:56 PM, Steven D'Aprano wrote: I'm not trying to be confrontational, I'm trying to understand your use-case(s) and see if it would be broken by the planned change to string escapes. Yeah, that's fine. Sometimes it is hard to communicate via email (versus saying a lot). On Fri,

[Python-Dev] Re: What to do about invalid escape sequences

On 8/9/2019 4:08 PM, MRAB wrote: On 2019-08-09 23:56, Steven D'Aprano wrote: I'm not trying to be confrontational, I'm trying to understand your use-case(s) and see if it would be broken by the planned change to string escapes. On Fri, Aug 09, 2019 at 03:18:29PM -0700, Glenn Linderman wrote:

[Python-Dev] Re: What to do about invalid escape sequences

On 8/9/2019 4:07 PM, Gregory P. Smith wrote: On Fri, Aug 9, 2019 at 11:37 AM Eric V. Smith > wrote: On 8/9/2019 2:28 PM, Jonathan Goble wrote: > On Fri, Aug 9, 2019 at 12:34 PM Nick Coghlan mailto:ncogh...@gmail.com>> wrote: >> I find the "Our

[Python-Dev] Re: What to do about invalid escape sequences

On Fri, Aug 09, 2019 at 02:28:13PM -0400, Jonathan Goble wrote: > I am perplexed at the opinion, seemingly espoused by multiple people > in this thread, that because a major part of the problem is that the > warnings were not visible enough, somehow the proposed solution is > making them not

[Python-Dev] Re: What to do about invalid escape sequences

On 2019-08-09 23:56, Steven D'Aprano wrote: I'm not trying to be confrontational, I'm trying to understand your use-case(s) and see if it would be broken by the planned change to string escapes. On Fri, Aug 09, 2019 at 03:18:29PM -0700, Glenn Linderman wrote: On 8/9/2019 2:53 PM, Steven

[Python-Dev] Re: What to do about invalid escape sequences

On Fri, Aug 9, 2019 at 11:37 AM Eric V. Smith wrote: > On 8/9/2019 2:28 PM, Jonathan Goble wrote: > > On Fri, Aug 9, 2019 at 12:34 PM Nick Coghlan wrote: > >> I find the "Our deprecation warnings were even less visible than > >> normal" argument for extending the deprecation period compelling.

[Python-Dev] Re: What to do about invalid escape sequences

On Fri, Aug 9, 2019 at 8:43 AM Guido van Rossum wrote: > This discussion looks like there's no end in sight. Maybe the Steering > Council should take a vote? > I've merged the PR reverting the behavior in 3.8 and am doing the same in the master branch. The sheer volume of email this is

[Python-Dev] Re: What to do about invalid escape sequences

I'm not trying to be confrontational, I'm trying to understand your use-case(s) and see if it would be broken by the planned change to string escapes. On Fri, Aug 09, 2019 at 03:18:29PM -0700, Glenn Linderman wrote: > On 8/9/2019 2:53 PM, Steven D'Aprano wrote: > >On Fri, Aug 09, 2019 at

[Python-Dev] Re: What to do about invalid escape sequences

On 8/9/2019 2:53 PM, Steven D'Aprano wrote: On Fri, Aug 09, 2019 at 01:12:59PM -0700, Glenn Linderman wrote: The reason I never use raw strings is in the documentation, it is because \ still has a special meaning, and the first several times I felt the need for raw strings, it was for

[Python-Dev] Re: What to do about invalid escape sequences

On Fri, Aug 09, 2019 at 01:12:59PM -0700, Glenn Linderman wrote: > The reason I never use raw strings is in the documentation, it is > because \ still has a special meaning, and the first several times I > felt the need for raw strings, it was for directory names that wanted to > end with \

[Python-Dev] Re: What to do about invalid escape sequences

Nathaniel Smith wrote: > Unfortunately, their solution isn't a pytest incantation, it's a > separate 'compileall' invocation they run on their source tree. I'm > not sure how you'd convert this into a pytest feature, because I don't > think pytest always know which parts of your code are your code

[Python-Dev] Re: What to do about invalid escape sequences

On Fri, Aug 9, 2019 at 12:07 PM wrote: > > Eric V. Smith wrote: > > Hopefully the warnings in 3.9 would be more visible that what we saw in > > 3.7, so that library authors can take notice and do something about it > > before 3.10 rolls around. > > Eric > > Apologies for the ~double-post on the

[Python-Dev] Re: What to do about invalid escape sequences

On 8/9/2019 9:08 AM, Nick Coghlan wrote: On Sat, 10 Aug 2019 at 01:44, Guido van Rossum wrote: This discussion looks like there's no end in sight. Maybe the Steering Council should take a vote? I find the "Our deprecation warnings were even less visible than normal" argument for extending

[Python-Dev] Re: What to do about invalid escape sequences

Eric V. Smith wrote: > Hopefully the warnings in 3.9 would be more visible that what we saw in > 3.7, so that library authors can take notice and do something about it > before 3.10 rolls around. > Eric Apologies for the ~double-post on the thread, but: the SymPy team has figured out the

[Python-Dev] Re: What to do about invalid escape sequences

On Fri, Aug 9, 2019 at 2:36 PM Eric V. Smith wrote: > > On 8/9/2019 2:28 PM, Jonathan Goble wrote: > > On Fri, Aug 9, 2019 at 12:34 PM Nick Coghlan wrote: > >> I find the "Our deprecation warnings were even less visible than > >> normal" argument for extending the deprecation period compelling.

[Python-Dev] Re: What to do about invalid escape sequences

On 8/9/2019 2:28 PM, Jonathan Goble wrote: On Fri, Aug 9, 2019 at 12:34 PM Nick Coghlan wrote: I find the "Our deprecation warnings were even less visible than normal" argument for extending the deprecation period compelling. Outsider's 2 cents from reading this discussion (with no personal

[Python-Dev] Re: What to do about invalid escape sequences

On Fri, Aug 9, 2019 at 12:34 PM Nick Coghlan wrote: > > I find the "Our deprecation warnings were even less visible than > normal" argument for extending the deprecation period compelling. Outsider's 2 cents from reading this discussion (with no personal experience with this warning): I am

[Python-Dev] Re: What to do about invalid escape sequences

On Fri, 9 Aug 2019 at 17:55, Steve Dower wrote: > > * change the SyntaxWarning into a default-silenced one that fires every > > time a .pyc is loaded (this is the hard part, but it's doable) > > * change pathlib.PureWindowsPath, os.fsencode and os.fsdecode to explicitly > > warn when the path

[Python-Dev] Re: What to do about invalid escape sequences

On 09Aug2019 0905, Serhiy Storchaka wrote: 09.08.19 18:30, Guido van Rossum пише: This discussion looks like there's no end in sight. Maybe the Steering Council should take a vote? Possible options: 1. SyntaxWarning in 3.8+ (the current status). 2. DeprecationWarning in 3.8, SyntaxWarning in

[Python-Dev] Re: What to do about invalid escape sequences

On Sat, 10 Aug 2019 at 01:44, Guido van Rossum wrote: > > This discussion looks like there's no end in sight. Maybe the Steering > Council should take a vote? I find the "Our deprecation warnings were even less visible than normal" argument for extending the deprecation period compelling. I

[Python-Dev] Re: What to do about invalid escape sequences

09.08.19 18:30, Guido van Rossum пише: This discussion looks like there's no end in sight. Maybe the Steering Council should take a vote? Possible options: 1. SyntaxWarning in 3.8+ (the current status). 2. DeprecationWarning in 3.8, SyntaxWarning in 3.9+ (revert changes in 3.8 only). 3.

[Python-Dev] Re: What to do about invalid escape sequences

This discussion looks like there's no end in sight. Maybe the Steering Council should take a vote? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)*

[Python-Dev] Re: What to do about invalid escape sequences

> This whole thread would be an excellent justification for following 3.9 > with 4.0. It's as near as we ever want to get to a breaking change, and a > major version number would indicate the need to review. If increasing > strictness of escape code interpretation in string literals is the only >

[Python-Dev] Re: What to do about invalid escape sequences

On Fri, Aug 9, 2019 at 11:22 PM Steven D'Aprano wrote: > > And this change won't fix that, because *good* paths that currently work > today will fail in the future, but *bad* paths that silently do the > wrong thing will continue to silently do the wrong thing. Except that many paths can be both

[Python-Dev] Re: What to do about invalid escape sequences

On Wed, Aug 07, 2019 at 07:47:45PM +1000, Chris Angelico wrote: > On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano wrote: > > What's the rush? Let's be objective here: what benefit are we going to > > get from this change? Is there anyone hanging out desperately for "\d" > > and "\-" to become

[Python-Dev] Re: What to do about invalid escape sequences

Steve Holden writes: > This whole thread would be an excellent justification for following 3.9 > with 4.0. It's as near as we ever want to get to a breaking change, and a > major version number would indicate the need to review. If increasing > strictness of escape code interpretation in

[Python-Dev] Re: What to do about invalid escape sequences

FWIW, the web archive https://mail.python.org/archives/list/python-dev@python.org/thread/ZX2JLOZDOXWVBQLKE4UCVTU5JABPQSLB/ does not seem to display the problems ... apparently the individual messages are not included in view source, and are cleaned up for chrome's inspect. I'm not sure

[Python-Dev] Re: What to do about invalid escape sequences

On 8/5/2019 4:30 PM, raymond.hettin...@gmail.com wrote: Thanks for weighing in. I think this is an important usability discussion. IMO it is the number one issue affecting the end user experience with this release. If we could get more people to actively use the beta release, the issue

[Python-Dev] Re: What to do about invalid escape sequences

> When you take a text string and create a string literal to represent > it, sometimes you have to modify it to become syntactically valid. Even simpler: use r""" instead of """ The only case where that won't work is when you need actual escape sequences. But I find this very rare in practice

[Python-Dev] Re: What to do about invalid escape sequences

Hey friends, This is IMHO a great idea. If a package claims to be Python 3.8 compatible, then it has to be correct concerning invalid escapes. A new pip version could perhaps even refuse packages with such literals when it claims to be supporting Python 3.8 . But how can it actually happen that

[Python-Dev] Re: What to do about invalid escape sequences

These two ought to be converted to raw strings, shouldn't they? On Thu, 8 Aug 2019 at 08:04, wrote: > > For me, these warnings are continuing to arise almost daily. See two recent > examples below. In both cases, the code previously had always worked without > complaint. > > - Example

[Python-Dev] Re: What to do about invalid escape sequences

I feel this is one of the cases, where we're expecting early adopters to proactively post pull requests against affected libraries. Failing that opening issues against affected libraries. I was ready to do just that, but alas didn't even have to! Matt's analysis shows that it's now too hard.

[Python-Dev] Re: What to do about invalid escape sequences

On 8/7/2019 6:13 PM, raymond.hettin...@gmail.com wrote: This isn't about me. As a heavy user of the 3.8 beta, I'm just the canary in the coal mine. Are you, with an understanding of the issue, submitting bug reports on the issues you find, thus helping to alleviate the problem, and educate

[Python-Dev] Re: What to do about invalid escape sequences

08.08.19 07:55, Toshio Kuratomi пише: Like the Ansible feature, though, the problem is that over time we've discovered that it is hard to educate users about the exact characteristic of the feature (\k == k but \n == newline; No, \k == \\k. This differs from most other programming languages.

[Python-Dev] Re: What to do about invalid escape sequences

On Mon, Aug 5, 2019 at 6:47 PM wrote: > > I wish people with more product management experience would chime in; > otherwise, 3.8 is going to ship with an intentional hard-to-ignore annoyance > on the premise that we don't like the way people have been programming and > that they need to change

[Python-Dev] Re: What to do about invalid escape sequences

This isn't about me. As a heavy user of the 3.8 beta, I'm just the canary in the coal mine. After many encounters with these warnings, I'm starting to believe that Python's long-standing behavior was convenient for users. Effectively, "\-" wasn't an error, it was just a way of writing "\-".

[Python-Dev] Re: What to do about invalid escape sequences

On 2019-08-07 23:43, Steve Holden wrote: This whole thread would be an excellent justification for following 3.9 with 4.0. It's as near as we ever want to get to a breaking change, and a major version number would indicate the need to review. If increasing strictness of escape code

[Python-Dev] Re: What to do about invalid escape sequences

On Thu, Aug 8, 2019 at 8:58 AM wrote: > > For me, these warnings are continuing to arise almost daily. See two recent > examples below. In both cases, the code previously had always worked without > complaint. > > - Example from yesterday's class > > ''' How old-style formatting

[Python-Dev] Re: What to do about invalid escape sequences

For me, these warnings are continuing to arise almost daily. See two recent examples below. In both cases, the code previously had always worked without complaint. - Example from yesterday's class ''' How old-style formatting works with positional placeholders print('The answer is

[Python-Dev] Re: What to do about invalid escape sequences

This whole thread would be an excellent justification for following 3.9 with 4.0. It's as near as we ever want to get to a breaking change, and a major version number would indicate the need to review. If increasing strictness of escape code interpretation in string literals is the only

[Python-Dev] Re: What to do about invalid escape sequences

On 8/7/19, Steve Dower wrote: > > * change the PyErr_SetExcFromWindowsErrWithFilenameObjects function to > append (or chain) an extra message when either of the filenames contains c > control characters (or change OSError to do it, or the default > sys.excepthook) On a related note for Windows,

[Python-Dev] Re: What to do about invalid escape sequences

Steven D'Aprano wrote: > Because our processes don't work the way we assumed, it turns out that > in practice we haven't given developers the deprecation period we > thought we had. Read Nathaniel's post, if you haven't already done so: >

[Python-Dev] Re: What to do about invalid escape sequences

On 07Aug2019 0247, Chris Angelico wrote: On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano wrote: What's the rush? Let's be objective here: what benefit are we going to get from this change? Is there anyone hanging out desperately for "\d" and "\-" to become SyntaxErrors, so they can... do what?

[Python-Dev] Re: What to do about invalid escape sequences

For what I can see, the majority of new users in an interactive environment seeing the warning will do so because the incorrect string will be in _their_ code. The benefits are immediate, as people change to either using raw-strings or using forward-slashes for file paths. The examples in the

[Python-Dev] Re: What to do about invalid escape sequences

On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano wrote: > What's the rush? Let's be objective here: what benefit are we going to > get from this change? Is there anyone hanging out desperately for "\d" > and "\-" to become SyntaxErrors, so they can... do what? So that problems can start to be

[Python-Dev] Re: What to do about invalid escape sequences

On Wed, 7 Aug 2019 at 10:32, Steven D'Aprano wrote: > No, I'm saying we don't have to rush this into 3.8. Let's keep the > warning silent and push everything back a release. > > Now is better than never. > Although never is often better than *right* now. > > Right now, we're looking at a

[Python-Dev] Re: What to do about invalid escape sequences

On Wed, Aug 07, 2019 at 02:33:51PM +1000, Chris Angelico wrote: > On Wed, Aug 7, 2019 at 1:54 PM Steven D'Aprano wrote: > > Don't think of this as a failure. Think of it as an opportunity: we've > > identified a weakness in our deprecation process. Let's fix that > > process, make sure that

[Python-Dev] Re: What to do about invalid escape sequences

07.08.19 03:57, Gregory P. Smith пише: People distribute code via pypi.  if we reject uploads of packages with these problems and link to fixers (modernize can be taught what to do), we prevent them from spreading further. How can we check that there are such problems in the package? Pass all

[Python-Dev] Re: What to do about invalid escape sequences

07.08.19 03:31, Rob Cliffe via Python-Dev пише: How about: whenever a third-party library uses a potentially-wrong escape sequence, it creates a message on the console. Then when someone sees that message, they can post a bug report against the package. Would not it just increase the amount of

[Python-Dev] Re: What to do about invalid escape sequences

07.08.19 01:37, Brett Cannon пише: I think this is a good example of how the community is not running tests with warnings on and making sure that their code is warnings-free. This warning has existed for at least one full release and fixing it doesn't require some crazy work-around for

[Python-Dev] Re: What to do about invalid escape sequences

06.08.19 20:37, Paul Moore пише: I don't see issues reported in the bug trackers for docutils and bottle. Maybe as a start, someone could raise issues there? The warning in docutils was fixed. https://sourceforge.net/p/docutils/code/8255/ ___

[Python-Dev] Re: What to do about invalid escape sequences

On Wed, Aug 7, 2019 at 1:54 PM Steven D'Aprano wrote: > Don't think of this as a failure. Think of it as an opportunity: we've > identified a weakness in our deprecation process. Let's fix that > process, make sure that *developers* will see the warning in 3.8 or 3.9, > and not raise an exception

[Python-Dev] Re: What to do about invalid escape sequences

On Tue, Aug 06, 2019 at 07:58:12PM -0700, Nathaniel Smith wrote: > For example, all my projects run tests with deprecation warnings > enabled and warnings turned into errors, but I never saw any of these > warnings. What happens is: the warning is issued when the .py file is > byte-compiled; but

[Python-Dev] Re: What to do about invalid escape sequences

On Wed, Aug 07, 2019 at 10:14:08AM +1000, Chris Angelico wrote: > On Wed, Aug 7, 2019 at 10:03 AM Steven D'Aprano wrote: > > - Keep the SyntaxWarning silent by default for 3.8. That gives us > > another year or more to gently pressure third-party libraries to fix > > their code, and to find ways

  1   2   >