On 05/08/2019 06:22, raymond.hettinger@gmail.com wrote: I have read through (most) of the thread, and visited the issue referenced.
We should revisit what we want to do (if anything) about invalid escape sequences. IMHO - revisit is okay, generally - but that was actually done a long time ago. Now it is, to me, just another example of "Python" being indecisive.
For Python 3.8, the DeprecationWarning was converted to a SyntaxWarning which is visible by default. The intention is to make it a SyntaxError in Python 3.9. Sounds like this has been discussed in depth - and decided.
This once seemed like a reasonable and innocuous idea to me; however, I've been using the 3.8 beta heavily for a month and no longer think it is a good idea. The warning crops up frequently, often due to third-party packages (such as docutils and bottle) that users can't easily do anything about. And during live demos and student workshops, it is especially distracting.
Because it is not innocuous? My experience with developers (you mention 3rd party) - is that they are lazy. If something is not up there, "in the face", they will always have a reason to say - tomorrow. Or, perhaps, since this has been a silent issue (and they are too lazy to read "What's new" they do not even know. The "head buried in the sand" sort of thing. As to demo's and workshops - YOU know this - so use it as an example to explain how Python development works and DEPENDS on 3rd party developers paying attention. Yes,I am sure you are concerned about speeding adoption of Python3.latest-is-greatest, but that is not the world. For example, RHEL8 is (coming) out. iirc, they way it comes out it what they intend to support for 10 years - so changes are it will be Python 3.7 (at best) for several years. I have a system with Centos(-7) and it's default python is python2 [root@t430 ~]# python3 bash: python3: command not found... Similar command is: 'python' [root@t430 ~]# python Python 2.7.5 (default, Jun 20 2019, 20:27:34) ...
I now think our cure is worse than the disease. If code currently has a non-raw string with '\latex', do we really need Python to yelp about it (for 3.8) or reject it entirely (for 3.9)? If someone can't remember exactly which special characters need to be escaped, do we really need to stop them in their tracks during a data analysis session? Do we really need to reject ASCII art in docstrings: ` \-------> special case'? Simply put - yes, reject. You decided. There is a solution - perhaps boring to implement - but as is mentioned - there are 'linters', so an automated approach is likely possible. If not today, someone will write a module. IIRC, the original problem to be solved was false positives rather than false negatives: filename = '..\training\new_memo.doc'. The warnings and errors don't do (and likely can't do) anything about this. For "filenames" you could, perhaps, make an exception in the calls that use them. e.g., when they are hard-coded in something such as open("..\training\new_memo.doc"). iirc, Windows can (and does) use forward-slash for file names for system calls like open. The "shell" command.exe does not, because it uses "/" the way posix shells use "-" (as in /h and -h for the "option" h).
If Python 3.8 goes out as-is, we may be punching our users in the nose and getting almost no gain from it. ISTM this is a job best left for linters. For a very long time, Python has been accepting the likes of 'more \latex markup' and has been silently converting it to 'more \\latex markup'. I now think it should remain that way. This issue in the 3.8 beta releases has been an almost daily annoyance for me and my customers. Depending on how you use Python, this may not affect you or it may arise multiple times per day.
IMHO - Python will not be punching anyone. Python will be delivering "a promise", being decisive, being clear. Not following through only creates insecurity - will they ever do it? Nah - no guts (these are 3rd-party developers chatting). Users are your friend. If they really want Python3.8+ and they get lots of warning messages - THEY will complain - and be heard - in ways CPython never will (or was). Again - revisit is fine - and I hope my 2 cents helps you stay the course! Michael