[issue36911] ast.parse outputs ast.Strs which do not differentiate between the ASCII codepoint 12 (literal new line) and the ASCII codepoints 134 and 156 ("\n")
Amber Brown added the comment: There's a difference between round-tripping back to the source text and correctly representing the text in the source, though. Since I'm using this module to perform static analysis of a Python module to retrieve class/function definitions and their docstrings to create API documentation, the string being the same as what it is in the file is important to me. -- ___ Python tracker <https://bugs.python.org/issue36911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36911] ast.parse outputs ast.Strs which do not differentiate between the ASCII codepoint 12 (literal new line) and the ASCII codepoints 134 and 156 ("\n")
New submission from Amber Brown : reproducing case: file.py: ``` """ Hello \n blah. """ ``` And then in a REPL (2.7 or 3+): ``` >>> import ast >>> f = ast.parse(open("test.py", 'rb').read()) >>> f <_ast.Module object at 0x7f609d0a4d68> >>> f.body[0] <_ast.Expr object at 0x7f609d0a4e10> >>> f.body[0].value <_ast.Str object at 0x7f609d02b780> >>> f.body[0].value.s '\nHello \n blah.\n' >>> repr(f.body[0].value.s) "'\\nHello \\n blah.\\n'" ``` Expected behaviour: ``` >>> repr(f.body[0].value.s) "'\\nHello n blah.\\n'" ``` -- components: Library (Lib) messages: 342417 nosy: hawkowl priority: normal severity: normal status: open title: ast.parse outputs ast.Strs which do not differentiate between the ASCII codepoint 12 (literal new line) and the ASCII codepoints 134 and 156 ("\n") versions: Python 2.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue36911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33497] cgi.parse_multipart does not have an associated "errors" parameter with its "encoding" parameter
Amber Brown <hawk...@atleastfornow.net> added the comment: This change mirrors the default in FieldStorage (which it calls). If it's not the best option, then it would need to be changed in FieldStorage too. (personally, I don't like strict because UnicodeDecodeErrors on untrusted user input kind of sucks, but also replace is kind of broken as well.) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33497> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33509] warnings.warn_explicit with module_globals=True raises a SystemError
New submission from Amber Brown <hawk...@atleastfornow.net>: Reproducible with: import warnings warnings.warn_explicit("msg", DeprecationWarning, "name", 1, module_globals=None) -- components: Interpreter Core messages: 316578 nosy: hawkowl priority: normal severity: normal status: open title: warnings.warn_explicit with module_globals=True raises a SystemError type: crash versions: Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33509> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33497] cgi.parse_multipart does not have an associated "errors" parameter with its "encoding" parameter
Change by Amber Brown <hawk...@atleastfornow.net>: -- keywords: +patch pull_requests: +6489 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33497> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33497] cgi.parse_multipart does not have an associated "errors" parameter with its "encoding" parameter
New submission from Amber Brown <hawk...@atleastfornow.net>: Lack of this parameter means that you may get an exception (if the incoming data is an invalid encoding) you can not get around. This causes Twisted to be unable to provide a compatible API on Python 3.7. -- messages: 316510 nosy: hawkowl priority: normal severity: normal status: open title: cgi.parse_multipart does not have an associated "errors" parameter with its "encoding" parameter type: behavior versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33497> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31742] Default to emitting FutureWarning for provisional APIs
Amber Brown <hawk...@atleastfornow.net> added the comment: > * asyncio & pathlib are already non-provisional, so wouldn't be affected. I was reading this and actually said "wait what I didn't know pathlib was provisional", and went back to check. The warning for it was grey next to a pair of yellow ones, no wonder I didn't see it. I guess we can all agree that the provisional warning should be modified to be more obvious, at least. What's required in doing that? Just editing what's there, or is there some form of template that is used? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31742] Default to emitting FutureWarning for provisional APIs
Amber Brown <hawk...@atleastfornow.net> added the comment: > What happened to "consenting adults"? Consent does not mean that by using Python, users fully consent to using modules that they may not be aware will, to paraphrase Donald, come back to bite them in the ass. Consent requires multiple things: - Acknowledgement of the benefits involved - Acknowledgement of the risks involved - Positive affirmation that these things are accepted. The spate of PyCon talks on provisional modules (the half dozen asyncio at PyCon US last year, and the 2-3+ asyncio talks at every conference I've been to since 2014) very much has given the community the first item, and as people have expressed interest in the benefits, acknowledge them. But, CPython does not like at all admitting clearly or explicitly the risks involved. From multiple discussions with Nick, an author of the provisional API PEP, it has come clear to me that the intended role of provisional software is to allow CPython to ship not-production-ready software for testing and API usability testing in an experimental capacity. How many people, from reading the single line in the docs (which, remember, is not the only path where people learned how to use asyncio in 3.4/3.5, and is absent from module documentation), did not know this? Upon discussing this issue with others, a few people admitted that they had no idea that provisional APIs existed, that asyncio was one, that typing is one, and they had no idea where to look to see if they were using a provisional module in their code or their dependencies. So, it appears that CPython is failing item #2 here, by not adequately informing users of the risks. Yes, the warning should be improved (and ought to be made bright red, not grey, and actually use the word "warning", not note), but we should also take a step to protect the users that may not learn about the module through official documentation, and in some cases, may never reference it. Only then can we confidently say that the user is potentially a "consenting adult". (Which is maybe interesting language to use nowadays considering Python's growth areas contain a lot of school-age education...) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31742] Default to emitting FutureWarning for provisional APIs
Amber Brown <hawk...@atleastfornow.net> added the comment: So you're proposing a coordinated effort across the half dozen, possibly more, test runners to enable some flags, so CPython doesn't log a single message, possibly two, that you're using unsupported experimental software with no backwards compatibility guarantee? I think the warnings control setting there could be a good solution for your "I don't care, don't show the warning" use case, but I also think explicit disabling per module is a better solution to recommend to users (since we might know that we're using typing, and we say "we are okay with using typing", but might not realise that we're silencing a new provisional module used by an updated library sometime in the future). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31742] Default to emitting FutureWarning for provisional APIs
Amber Brown <hawk...@atleastfornow.net> added the comment: What is the point of an opt-in warning, when the entire point of the proposed warning is letting people know that they may be using something they are not fully educated or informed about the ramifications of using? If you know to turn on the warning, you know to check the list of provisional modules, or know that provisional modules exist in the first place. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31742] Default to emitting FutureWarning for provisional APIs
Amber Brown <hawk...@atleastfornow.net> added the comment: Donald hits it on the head for me. As long as the code is not covered by the same API deprecation contract that the rest of the standard library is, it should make it obvious when attempting to use it. I can be relatively certain that a lot of people were not aware that the potential scope of asyncio changes included what it potentially could have, and I personally wasn't aware that typing was a provisional module (and got burnt by incompatible changes in 3.6). There was a small note in the docs, but when I was learning from cattrs's docs and not CPython's, how was I supposed to know? A warning is low cost, there's a way to switch it off, and it potentially informs users that they need to be aware of its provisional status, especially if it's a dependency of a dependency. -- nosy: +hawkowl ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com