[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")

2019-05-14 Thread Amber Brown


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")

2019-05-13 Thread Amber Brown


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

2018-05-15 Thread Amber Brown

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

2018-05-14 Thread Amber Brown

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

2018-05-14 Thread Amber Brown

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

2018-05-14 Thread Amber Brown

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

2017-10-11 Thread Amber Brown

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

2017-10-10 Thread Amber Brown

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

2017-10-10 Thread Amber Brown

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

2017-10-10 Thread Amber Brown

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

2017-10-09 Thread Amber Brown

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