[Python-Dev] Re: What to do about invalid escape sequences
On Mon, Aug 5, 2019 at 2:24 PM wrote: > 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. > > 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. > Those third-party packages will need to be fixed in time for 3.9. This isn't the first time this has happened. > 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'? > > 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. > Many MANY file names will include some that are and some that aren't. If you're lucky, it'll begin "C:\Users" and you'll get an immediate hard error; but if it starts out "C:\Program Files", this warning is what's going to catch it. (Still true in lowercase for both of those.) > 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. > > P.S. Before responding, it would be a useful exercise to think for a moment > about whether you remember exactly which characters must be escaped or > whether you habitually put in an extra backslash when you aren't sure. Then > see: https://bugs.python.org/issue32912 > With alphabetics, I never put in an extra backslash just to be sure. My habit is to escape the quotation mark used to delimit the string, the escape character itself, and nothing else, unless I'm actually constructing a deliberate escape sequence. Except in a regular expression, and then I'm inevitably bitten by differences between grep, sed, Python, etc, etc, etc, so I have to just test it anyway. What does Python actually gain by allowing errors to pass silently? Are there any other languages that allow arbitrary backslash sequences through unchanged? I tested Lua (syntax error), Pike (syntax warning), GCC in both C and C++ (warning), and Node.js (silent). Incidentally, I haven't found any other language in which "asdf\qwer" == "asdf\\qwer"; they're always just ignoring the backslash altogether. IMO Python's solution is better, but Lua's is best. A bad escape is an error. ChrisA ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/XJI33TJB2ZMRNRTOSOUQ4YFWJ7KY7WTP/
[Python-Dev] Re: What to do about invalid escape sequences
05.08.19 07:22, [email protected] пише: We should revisit what we want to do (if anything) about invalid escape sequences. 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. I do not think there is such intention. I think this warning can be kept for a long time. 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. Since the bytecode is cached, the warning in a third-party code is emitted at most once: when you install a package or when use it the first time. The warning in your code is emitted every time when you change it, until you fix it. In contrary, other deprecation warnings (for example a one about importing Mapping from collections) is emitted on every run. 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)? Yes, because it is very likely that there is something like '\arrow' or '\newline' in the same string literal or in other string literals in the same file. I follow for fixes of incompatibilities with new Python versions in third-party projects, and it looks to me, that in many (if not most) cases a warning about invalid escape sequences exposes a real bug. So there is a real benefit from such warnings. 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? The only character which must be escaped is a backslash. And a quote if it happens to match a quote used for creating a string literal. It is a simple rule. Do we really need to reject ASCII art in docstrings: ` \---> special case'? Do we reject ASCII art like '\xxx/'? A backslash should be escaped, otherwise use raw string literals. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/YPZX7MJSGIOH7EZ2VVPIOA75GUPVUYIN/
[Python-Dev] Re: Is "%zd" format is portable now?
On 02/08/2019 04:12, Inada Naoki wrote:
> On Thu, Aug 1, 2019 at 10:21 PM Victor Stinner wrote:
>> Hi INADA-san,
>>
>> Is it supported on macOS, FreeBSD, AIX, Android, etc.?
>>
>> My notes on platforms supported by Python:
>> https://pythondev.readthedocs.io/platforms.html
>>
>> For example, xlc C compiler seems to be commonly used on AIX. I don't
>> know how is its C99 support.
>>
>> Can we write an unit test somewhere to ensure that %zd works as expected?
>>
>> Victor
>>
> I don't know about AIX too. I googled, but I can not find even man manual for
> snprintf(3) on AIX.
>
> I'm frustrated I wasted a few hours to read some PDFs and searching
> but I can not
> find any official document about snprintf(3).
> I feel it's impossible to support such platforms...
AIX man pages "group" printf() functions together on one page.
During a quick search I found a man page for AIX 4.3.3 (which is roughly
1997), and also for AIX 7.2. So the core function is there (in libc.a).
I do not have any systems older than AIX 5.3 - and a much too simplified
program (printf(), sprintf(), snprintf() all support the same formatting
arguments.
In the documentation I do not see any reference to %z... support
(although I do see support for vectors using %v...).
As to XLC and c99, etc.. FYI: when called as "cc" the compiler behavior
is "pre-c99", whatever that may be. For strict c99 you call it as c99.
I call it as xlc and xlc_r to get c99 and some other extensions by
default. The only thing you need remember is that XLC supports, for
years, various standards - including c99. Just not, by default, if
called as "cc".
Further, (imho) it is not the compiler that "supports" a particular
printf() format - rather the compiler verifies the syntax, does the work
for the call - but the actual support is provided by libc.a - which is
maintained by core AIX - not the compiler developer/maintainers.
OK - a too simple program - run on AIX 5.3 - seems to indicate that XLC
(version 11, so quite old!) accepts "%zd".
If someone would be kind enough to mail me a better example of what
needs to be verfied - I am happy to compile and publish the results.
root@x065:[/data/prj/aixtools/tests]cat printf-test.c
#include
main()
{
printf("Hello World - testing for %%zd support\n");
printf("%%zd of 1001 == %zd\n", 1001);
printf("\nTest complete\n");
}
oot@x065:[/data/prj/aixtools/tests]./a.out
Hello World - testing for %zd support
%zd of 1001 == 1001
Test complete
fyi: AIX 4.3
https://sites.ualberta.ca/dept/chemeng/AIX-43/share/man/info/C/a_doc_lib/libs/basetrf2/snprintf.htm
and AIX 7.2
https://www.ibm.com/support/knowledgecenter/ssw_aix_72/p_bostechref/printf.html
> Except AIX, I believe all platforms supports size_t and %zd because
> it's very basic
> C99 feature.
>
> Regards,
> --
> Inada Naoki
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/O7H4FBLDQBHSKGSEJQ2TU7IRNKUAPJDV/
signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/O55OVT5ORYQGBGVTJXIGQMXDO4D3F5Y4/
[Python-Dev] Re: Is "%zd" format is portable now?
Thank you for confining it!
Currently, Python defines PY_FORMAT_SIZE_T as:
#ifndef PY_FORMAT_SIZE_T
# if SIZEOF_SIZE_T == SIZEOF_INT && !defined(__APPLE__)
# define PY_FORMAT_SIZE_T ""
# elif SIZEOF_SIZE_T == SIZEOF_LONG
# define PY_FORMAT_SIZE_T "l"
# elif defined(MS_WINDOWS)
# define PY_FORMAT_SIZE_T "I"
# else
# error "This platform's pyconfig.h needs to define PY_FORMAT_SIZE_T"
# endif
#endif
https://github.com/python/cpython/blob/1213123005d9f94bb5027c0a5256ea4d3e97b61d/Include/pyport.h#L158-L168
This can be changed to this:
#ifndef PY_FORMAT_SIZE_T
/* "z" is defined C99 and portable enough. We can use "%zd" instead of
"%" PY_FORMAT_SIZE_T "d" for now.
*/
# define PY_FORMAT_SIZE_T "z"
#endif
On Mon, Aug 5, 2019 at 6:05 PM Michael wrote:
>
> OK - a too simple program - run on AIX 5.3 - seems to indicate that XLC
> (version 11, so quite old!) accepts "%zd".
>
> If someone would be kind enough to mail me a better example of what
> needs to be verfied - I am happy to compile and publish the results.
>
> root@x065:[/data/prj/aixtools/tests]cat printf-test.c
> #include
>
> main()
> {
> printf("Hello World - testing for %%zd support\n");
> printf("%%zd of 1001 == %zd\n", 1001);
> printf("\nTest complete\n");
> }
>
> oot@x065:[/data/prj/aixtools/tests]./a.out
> Hello World - testing for %zd support
> %zd of 1001 == 1001
>
> Test complete
>
> fyi: AIX 4.3
> https://sites.ualberta.ca/dept/chemeng/AIX-43/share/man/info/C/a_doc_lib/libs/basetrf2/snprintf.htm
>
> and AIX 7.2
> https://www.ibm.com/support/knowledgecenter/ssw_aix_72/p_bostechref/printf.html
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/UIIERFFTJIVQMOOZTZDLAILAAXCU7XSK/
[Python-Dev] AIX XL C knows/supports C99: was Re: Re: Is "%zd" format is portable now?
On 01/08/2019 15:14, Victor Stinner wrote: > For example, xlc C compiler seems to be commonly used on AIX. I don't > know how is its C99 support. FYI - this is from the XL C "compiler" reference document for V-10, with copyright set in 2008. Just an excerpt - c99 is supported. Just have to say CC=c99 or CC=xlc or one of the other variants. If more documentation is desired - just let me know. Michael Standards and specifications XL C is designed to support the following standards and specifications. You can refer to these standards for precise definitions of some of the features found in this information. * Information Technology – Programming languages – C, ISO/IEC 9899:1990, also known as C89. * Information Technology – Programming languages – C, ISO/IEC 9899:1999, also known as C99. signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/4PMTNVUS6I4UVUTFLOVJIIG6VXGUETML/
[Python-Dev] Re: What to do about invalid escape sequences
El lun., 5 de ago. de 2019 a la(s) 01:25, escribió: > > We should revisit what we want to do (if anything) about invalid escape > sequences. > > 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. What about allowing in 3.8 to from __future__ import this SyntaxWarning (so anybody can start kicking own code's tires), then 3.9 could make it a real SyntaxWarning, and 4.0 (3.10?) make it a SyntaxError? Of course, in a year or so we could decide to delay the last two steps even more... Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org.ar/ Twitter: @facundobatista ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/S62JZC6TSJHBGX4IDWF7XATDQ6HV2YVH/
[Python-Dev] Re: What to do about invalid escape sequences
On Mon, 5 Aug 2019 at 15:44, Facundo Batista wrote: > > El lun., 5 de ago. de 2019 a la(s) 01:25, > escribió: > > > > We should revisit what we want to do (if anything) about invalid escape > > sequences. > > > > 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. > > What about allowing in 3.8 to from __future__ import this > SyntaxWarning (so anybody can start kicking own code's tires), then > 3.9 could make it a real SyntaxWarning, and 4.0 (3.10?) make it a > SyntaxError? Do existing linters flag suspicious/incorrect use of escapes? Could (or should) they? I suspect that a future import will be used by a lot fewer projects than would benefit from this being flagged by linters. Hmm, it looks like linters do flag this: pycodestyle (used by flake8) - https://pep8.readthedocs.io/en/latest/intro.html#error-codes pylint - https://pylint.readthedocs.io/en/latest/technical_reference/features.html#string-checker-messages This begs the question why libraries haven't already fixed this :-( > Of course, in a year or so we could decide to delay the last two steps > even more... It's way too easy to simply get into a cycle of repeatedly delaying something like this. IMO the only point in delaying the switch to a SyntaxWarning would be if there were a way to encourage libraries to fix the problem in the extra time before the switch occurred (to minimise the effect on end users). But from the look of it, that's not going to happen - even linter warnings don't seem to make much difference there :-( So I don't see that a delay (or a future import) would actually help much. But I still suspect that we're in for a painful period where users get warnings from libraries that haven't been fixed. All of the above ignores the question of whether we should make invalid escapes generate a (visible) warning. I've seen enough errors caused by the "false positives" (\U or \n in Windows filenames, for example) that I'm inclined to be strict (even though I accept that strictness hits "false negatives" rather than "false positives"). And I really don't see why it's so hard to fix code - use raw strings for docstrings, and for Windows filenames, and always double backslashes in "simple" strings unless you know you mean to use an escape. And use a linter to check when you make a typo! Paul ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/G5EPORSHHEQVQ767II4CWHTXYUGYL4CW/
[Python-Dev] Re: What to do about invalid escape sequences
On 04Aug2019 2122, [email protected] wrote: We should revisit what we want to do (if anything) about invalid escape sequences. 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. 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. 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'? 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. I broadly agree that the warning is very annoying, particularly when it comes from third-party packages (I see it from some of pip's vendored dependencies all the time), though I do also see many people bitten by FileNotFoundError because of a '\n' in their filename. Raymond - a question if I may. How often do you see these occurring from docstrings, compared to regular strings? I feel like I only ever see the irrelevant warnings being raised from docstrings, so if others confirm this perhaps there's a way we could suppress the warnings where the string is the entire expression? Cheers, Steve ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/DWIKKGAAL2FH7BULZWGP5AHZZ3LXAL53/
[Python-Dev] Re: What to do about invalid escape sequences
Thanks for looking at other languages do. It gives some hope that this won't end-up being a usability fiasco. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/OM3W7ABSARYDMUIEIGYUYAUSRVHLZ6T5/
[Python-Dev] Re: What to do about invalid escape sequences
> I broadly agree that the warning is very annoying, particularly > when it comes from third-party packages (I see it from some > of pip's vendored dependencies all the time), The same here as well. The other annoyance is that it pops up during live demos, student teaching sessions, and during ipython data analysis in a way that becomes a distractor and makes Python look and feel like it is broken. I haven't found a since case where it improved the user experience. > though I do also see many people bitten by > FileNotFoundError because of a '\n' in their filename. Yes, I've seen that as well. Unfortunately, the syntax warning or error doesn't detect that case. It only complains about invalid sequences which weren't the actual problem we were trying to solve. The new warning soon-to-be error breaks code that currently works but is otherwise innocuous. > Raymond - a question if I may. How often do you see these > occurring from docstrings, compared to regular strings? About half. 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 would stand-out front and center. But if people don't use the beta in earnest, we won't have confirmation until it is too late. We really don't have to go this path. Arguably, the implicit conversion of '\latex' to '\\latex' is a feature that has existed for three decades, and now we're deciding to turn it off to define existing practices as errors. I don't think any commercial product manager would allow this to occur without a lot of end user testing. Raymond P.S. In the world of C compilers, I suspect that if the relatively new compiler warnings were treated as errors, the breakage would be widespread. Presumably that's why they haven't gone down this road. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/DH63MEQWGGJRMCDRC57F33DR7HH7HDIT/
[Python-Dev] Re: What to do about invalid escape sequences
End-user experience isn't something that can just be argued away. Steve and I are reporting a recurring annoyance. The point of a beta release is to elicit these kinds of reports so they can be addressed before it is too late. ISTM you are choosing not to believe the early feedback and don't want to provide a mitigation. This decision reverses 25+ years of Python practice and is the software equivalent of telling users "you're holding it wrong". Instead of an awareness campaign to use the silent-by-default warnings, we're going directly towards breaking working code. That seems pretty user hostile to me. Chris's language survey one shows only language, Lua, that treated this an error. For compiled languages that emit warnings, the end-user will never see those warning so there is no end-user consequence. In our case though, end-users will see the messages and may not have an ability to do anything about it. 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 their code even if it was working just fine. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/D4ETYYRD4RB37BFZ35STKTDKVT7WH3E2/
[Python-Dev] Re: What to do about invalid escape sequences
On Tue, Aug 6, 2019 at 11:48 AM wrote: > > End-user experience isn't something that can just be argued away. Steve and > I are reporting a recurring annoyance. The point of a beta release is to > elicit these kinds of reports so they can be addressed before it is too late. > ISTM you are choosing not to believe the early feedback and don't want to > provide a mitigation. > > This decision reverses 25+ years of Python practice and is the software > equivalent of telling users "you're holding it wrong". Instead of an > awareness campaign to use the silent-by-default warnings, we're going > directly towards breaking working code. That seems pretty user hostile to me. > > Chris's language survey one shows only language, Lua, that treated this an > error. For compiled languages that emit warnings, the end-user will never > see those warning so there is no end-user consequence. In our case though, > end-users will see the messages and may not have an ability to do anything > about it. > But my (tiny) survey also found that most languages treat "asdf\qwer" as the same as "asdfqwer", not "asdf\\qwer". So if you're going to use that data to guide you, then Python has been flat-out wrong for those 25+ years. IMO Python's approach of inserting the backslashes was on par with allowing b"asdf" and u"asdf" to compare equal. In one common case, it magically does the right thing; but then it leads to data-dependent bugs elsewhere (eg "C:\Program Files" works but "C:\Users" doesn't). The ONLY reason this is causing pain is that there are fragile programs out there that currently happen to work, but might easily break at any time. Having tried to remotely diagnose bugs in my students' code, I would be *much* happier with an immediate error that tells them what's going wrong. One of the hardest things to debug (even for an expert, never mind about a novice) is the situation where an insignificant change completely breaks your code - "all I did was rename the file and change the open() call". The price is that there are some noisy errors when code is probably buggy. ChrisA ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/YE6FTDX35FYVHVLMJ2U3SCVJBY3GGMTJ/
[Python-Dev] Re: What to do about invalid escape sequences
On 05/08/2019 06:22, [email protected] 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 signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/54MBQXAKGCFNM2KSNSVS6HDAQQSERCMY/
