[issue42128] Structural Pattern Matching (PEP 634)
Change by Saiyang Gou : -- nosy: +gousaiyang nosy_count: 12.0 -> 13.0 pull_requests: +24335 pull_request: https://github.com/python/cpython/pull/25642 ___ Python tracker <https://bugs.python.org/issue42128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default in Python 3.11
Change by Saiyang Gou : -- pull_requests: +24318 pull_request: https://github.com/python/cpython/pull/25602 ___ Python tracker <https://bugs.python.org/issue38605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38692] add a pidfd child process watcher
Change by Saiyang Gou : -- nosy: +gousaiyang nosy_count: 10.0 -> 11.0 pull_requests: +24233 pull_request: https://github.com/python/cpython/pull/25515 ___ Python tracker <https://bugs.python.org/issue38692> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28724] Add method send_io, recv_io to the socket module.
Change by Saiyang Gou : -- nosy: +gousaiyang nosy_count: 7.0 -> 8.0 pull_requests: +24232 pull_request: https://github.com/python/cpython/pull/22608 ___ Python tracker <https://bugs.python.org/issue28724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42737] PEP 563: drop annotations for complex assign targets
Change by Saiyang Gou : -- pull_requests: +24229 pull_request: https://github.com/python/cpython/pull/25511 ___ Python tracker <https://bugs.python.org/issue42737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43893] typing.get_type_hints does not accept type annotations with leading whitespaces
Saiyang Gou added the comment: I think it might be a good idea to just strip leading spaces and tabs for `compile(x, ..., 'eval')` if we want consistent behavior. `compile` might be used in more locations in the whole Python source tree apart from `typing.get_type_hints`. Technically the only behavior difference between `eval(x)` and `compile(x, ..., 'eval')` (when `x` is a string) should be that the latter one does not execute the generated byte code. -- nosy: +gousaiyang ___ Python tracker <https://bugs.python.org/issue43893> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42737] PEP 563: drop annotations for complex assign targets
Saiyang Gou added the comment:
I think we can just skip evaluating annotations for complex targets when in
module or class scope (they are not stored anyway). The point of PEP 563 is to
suppress any evaluation of annotations (regardless of position) at definition
time, while type checkers can still analyze them as usual.
This is the current behavior (ever since 3.7, with `from __future__ import
annotations`):
Python 3.10.0a7 (default, Apr 6 2021, 17:59:12) [GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 1
>>> x.y: print('evaluated in module')
evaluated in module
>>> class A:
... u = 2
... u.v: print('evaluated in class')
...
evaluated in class
And I think they should become no-ops at run-time (as if the annotations were
wrapped in string form).
--
nosy: +gousaiyang
___
Python tracker
<https://bugs.python.org/issue42737>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36540] PEP 570: Python Positional-Only Parameters
Change by Saiyang Gou : -- pull_requests: +23996 pull_request: https://github.com/python/cpython/pull/25260 ___ Python tracker <https://bugs.python.org/issue36540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36540] PEP 570: Python Positional-Only Parameters
Change by Saiyang Gou : -- pull_requests: +23995 pull_request: https://github.com/python/cpython/pull/25259 ___ Python tracker <https://bugs.python.org/issue36540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43756] About updating audit events when function gains new arguments
Saiyang Gou added the comment: And one more question, should we ever remove an old version of event when we add a new version of it? A function whose signature got repeatedly changed may result in several versions of audit event raised together on a single operation, which is probably not good for performance. But removing the old event will make those hooks which are not written to handle the new version of the event unable to receive the old event at all, which doesn't look good. -- ___ Python tracker <https://bugs.python.org/issue43756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43756] About updating audit events when function gains new arguments
Change by Saiyang Gou : -- keywords: +patch pull_requests: +23977 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25239 ___ Python tracker <https://bugs.python.org/issue43756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default in Python 3.10
Change by Saiyang Gou : -- nosy: +gousaiyang nosy_count: 11.0 -> 12.0 pull_requests: +23974 pull_request: https://github.com/python/cpython/pull/25236 ___ Python tracker <https://bugs.python.org/issue38605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36540] PEP 570: Python Positional-Only Parameters
Change by Saiyang Gou : -- nosy: +gousaiyang nosy_count: 6.0 -> 7.0 pull_requests: +23973 pull_request: https://github.com/python/cpython/pull/25235 ___ Python tracker <https://bugs.python.org/issue36540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43472] [security][subinterpreters] Add auditing hooks to subinterpreter module
Saiyang Gou added the comment: One problem is the naming of audit events. Actually I didn't even notice that `_xxsubinterpreters` was already there since Python 3.8, because PEP 554 is still in draft status as for now. Looks like `_xxsubinterpreters` is an internal low-level interface to subinterpreters (and probably only meant for testing purposes for now), while PEP 554 will bring a high-level interface `interpreters` for users. Naming the audit events as `interpreters.*` will be more readable, although the `interpreters` module doesn't actually exist today. -- nosy: +gousaiyang ___ Python tracker <https://bugs.python.org/issue43472> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43756] About updating audit events when function gains new arguments
New submission from Saiyang Gou :
I'm not sure what to do when a function already being audited gains new
arguments which are also worth auditing. For example, issue 38144 brings new
`root_dir` and `dir_fd` arguments to `glob.glob`. Currently `glob.glob` is
already audited, with `(pathname, recursive)` as the event schema. However, the
new `root_dir` and `dir_fd` arguments are important context for the glob
operation and is also worth collecting into the event (as a comparison, `os.*`
audit events already include `dir_fd`). The problem is how to incorporate the
new arguments.
- Solution 1: Add new arguments to the existing event schema (on feature
releases). In this ways, hooks expecting an arg tuple of the original length
will be broken. Hooks taking arguments by subscripts (e.g. `pathname =
args[0]`) may still work if we only append new arguments to the end of the
event schema and never insert arguments in the middle.
- Solution 2: Add a new audit event. In this `glob` case, we add a new event
which might be called `glob.glob.v2` or `glob.glob.3_10` or some other way.
This will make sure the event schema is always fixed across different feature
releases. But hooks may need to correctly handle all "versions" of events (e.g.
do some thing like `if event.startswith('glob.glob')` instead of `if event ==
'glob.glob'`).
I guess more audited functions may gain new arguments in the future so this
problem is unavoidable. I would like some suggestions from Steve. Thanks!
--
messages: 390386
nosy: gousaiyang, steve.dower
priority: normal
severity: normal
status: open
title: About updating audit events when function gains new arguments
___
Python tracker
<https://bugs.python.org/issue43756>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39702] PEP 614: Relaxing Grammar Restrictions On Decorators
Change by Saiyang Gou : -- nosy: +gousaiyang nosy_count: 3.0 -> 4.0 pull_requests: +23971 pull_request: https://github.com/python/cpython/pull/25234 ___ Python tracker <https://bugs.python.org/issue39702> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43755] lambda expression no longer valid at comp_if in Python 3.9
Change by Saiyang Gou : -- keywords: +patch pull_requests: +23968 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25231 ___ Python tracker <https://bugs.python.org/issue43755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43755] lambda expression no longer valid at comp_if in Python 3.9
Saiyang Gou added the comment: I'll work on it soon. -- ___ Python tracker <https://bugs.python.org/issue43755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43755] lambda expression no longer valid at comp_if in Python 3.9
Saiyang Gou added the comment: OK I didn't find this duplicate issue. After reading that, I think we should update the documentation (https://docs.python.org/3/reference/expressions.html). `comp_if ::= "if" expression_nocond [comp_iter]` can become `comp_if ::= "if" or_test [comp_iter]`, and all `nocond` stuffs can be removed. -- ___ Python tracker <https://bugs.python.org/issue43755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43755] lambda expression no longer valid at comp_if in Python 3.9
New submission from Saiyang Gou : According to the documentation, a lambda expression at the `comp_if` position of a comprehension is allowed (can be parsed as `lambda_expr_nocond`). But this seems broken in Python 3.9 PEG parser. Example: user@host:/$ python3.8 Python 3.8.9 (default, Apr 3 2021, 01:00:00) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> [x for x in range(10) if lambda: 1] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> user@host:/$ python3.9 Python 3.9.3 (default, Apr 3 2021, 00:51:37) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> [x for x in range(10) if lambda: 1] File "", line 1 [x for x in range(10) if lambda: 1] ^ SyntaxError: invalid syntax -- messages: 390369 nosy: gousaiyang priority: normal severity: normal status: open title: lambda expression no longer valid at comp_if in Python 3.9 type: behavior versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43439] [security] Add audit events on GC functions giving access to all Python objects
Saiyang Gou added the comment: In addition to the consistency with existing audit hook signatures, there may also be another benefit of wrapping it with a tuple of length 1. If gc.get_referrers or gc.get_referents happens to gain a new keyword-only argument in the future, we may need to add the new argument to the hook args. Extending the `(objs,)` tuple to `(objs, new_kwarg)` is a bit more elegant than appending the `new_kwarg` to the end of the `objs` tuple itself (considering a hook function which tries to be compatible with both the old and the new signature). -- ___ Python tracker <https://bugs.python.org/issue43439> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43439] [security] Add audit events on GC functions giving access to all Python objects
Saiyang Gou added the comment: There is a minor issue here. For gc.get_referrers and gc.get_referents, probably the format code for PySys_Audit should be "(O)" instead of "O". Typically the tuple `args` passed to the hook functions are fixed-length as described in the audit events table. Here `objs` itself is a tuple (containing variable-length arguments) and directly passed to the audit hook with being wrapped by another layer of tuple. If the hook function is to receive a variable-length tuple, probably the documentation should be updated to mention this. -- nosy: +gousaiyang ___ Python tracker <https://bugs.python.org/issue43439> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43438] [doc] sys.addaudithook() documentation should be more explicit on its limitations
Saiyang Gou added the comment: > Please also keep in mind that sys.addaudithook() does **not** add a global > hook. The function adds a per-interpreter hook. Yes, I'm aware of this. And this should be better documented. When I was playing around with audit hooks and reading the source code, I see hooks written in Python (added via sys.addaudithook) are per-interpreter (stored in a Python list object as part of per-interpreter state) while hooks written in C (added via PySys_AddAuditHook) are global (stored in a C linked list). C hooks are more robust. The Python hooks are not inherited in a child process created via multiprocessing when the start method is "spawn" or "forkserver" (not "fork") since they are per-interpreter. I'm not sure whether we should audit the creation of new processes/threads via multiprocessing/threading modules (and also creation of sub-interpreters when PEP 554 gets accepted). -- ___ Python tracker <https://bugs.python.org/issue43438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43438] [doc] sys.addaudithook() documentation should be more explicit on its limitations
Saiyang Gou added the comment:
We understand that audit hooks should not be used to build a sandbox with
Python. It is natural for audit hooks to appear in CTF challenges though, as
many CTF challenges intentionally try to use a wrong way to secure a system
(and let players prove it wrong).
With that being said, audit hooks should still be robust, even for logging
purposes. We are no trying to prevent all kinds of malicious behaviors, but we
want to detect them *as much as possible*. If audit hooks can be easily removed
while triggering very few seemingly non-sensitive audit events (in this CTF
challenge, only "import gc" is triggered, which probably looks "no so
suspicious"), this allows attackers to hide details of further malicious
behavior without being audited, which violated the motivation of audit hooks
(to increase security transparency).
The recent gc patch introduced new events which will make the attack in that
CTF challenge look more suspicious. But probably it is still better to harden
the current data structure used to store per interpreter audit hooks. If an
attacker happens to gain a reference to the list holding the hooks (although
I'm not sure how that will still be possible without using `gc`), they can
easily remove the hooks at the Python language level. Probably a Python tuple
is already better than a Python list to store the hooks, since tuples are
immutable at the language level. Although that means we should build new a
tuple each time a new hook is added.
If the hook itself is fragile (e.g. a hook written in Python which relies on
global variables), it is a user fault. But if the hook function itself is good,
it shouldn't be too easy to remove. Any successful attempts to remove the hook
must have already "pwned" the Python interpreter (i.e. gained arbitrary memory
read/write or native code execution ability), either by using ctypes, by
open('/proc/self/mem'), by crafting bytecode (which triggers code.__new__) or
importing modules written in native code. (Overwriting hook.__code__ triggers
object.__setattr__.)
--
nosy: +gousaiyang
___
Python tracker
<https://bugs.python.org/issue43438>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43281] Walrus comprehension rebind checking behavior
New submission from Saiyang Gou : # test PEP 572 disallows walrus use cases such as `[(i := 1) for i in [1]]`, because `for i` implies that `i` is local to the comprehension but `(i := 1)` implies that `i` is "exported", which is a contradiction. However, I noticed the following behavior both in 3.8 and 3.9: >>> [(a := 1) for a, (*b, c[d+e::f(g)], h.i) in [1]] File "", line 1 SyntaxError: assignment expression cannot rebind comprehension iteration variable 'a' >>> [(b := 1) for a, (*b, c[d+e::f(g)], h.i) in [1]] File "", line 1 SyntaxError: assignment expression cannot rebind comprehension iteration variable 'b' >>> [(c := 1) for a, (*b, c[d+e::f(g)], h.i) in [1]] File "", line 1 SyntaxError: assignment expression cannot rebind comprehension iteration variable 'c' >>> [(d := 1) for a, (*b, c[d+e::f(g)], h.i) in [1]] File "", line 1 SyntaxError: assignment expression cannot rebind comprehension iteration variable 'd' >>> [(e := 1) for a, (*b, c[d+e::f(g)], h.i) in [1]] File "", line 1 SyntaxError: assignment expression cannot rebind comprehension iteration variable 'e' >>> [(f := 1) for a, (*b, c[d+e::f(g)], h.i) in [1]] File "", line 1 SyntaxError: assignment expression cannot rebind comprehension iteration variable 'f' >>> [(g := 1) for a, (*b, c[d+e::f(g)], h.i) in [1]] File "", line 1 SyntaxError: assignment expression cannot rebind comprehension iteration variable 'g' >>> [(h := 1) for a, (*b, c[d+e::f(g)], h.i) in [1]] File "", line 1 SyntaxError: assignment expression cannot rebind comprehension iteration variable 'h' >>> [(i := 1) for a, (*b, c[d+e::f(g)], h.i) in [1]] Traceback (most recent call last): File "", line 1, in File "", line 1, in TypeError: cannot unpack non-iterable int object Among all of these assignment expressions, only the assignment to `i` (attribute name) is allowed. However, in my understanding, only `a` and `b` should be disallowed for assignment. This comprehension example only creates two new variables, `a` and `b`, which are local to the comprehension. Assignment expressions assigning to `c`, `d`, `e`, `f`, `g` and `h` should be allowed. `c` and `h` are already in the outer scope. `d`, `e`, `f` and `g` are just names inside the expression in the subscript part. They are not "comprehension iteration variables" and not local to the comprehension. The same behavior is also observed when detecting inner loop variable rebinding outer loop assignment expression targets: >>> [i for i in range(5) if (j := 0) for k[j + 1] in range(5)] File "", line 1 SyntaxError: comprehension inner loop cannot rebind assignment expression target 'j' -- messages: 387433 nosy: gousaiyang priority: normal severity: normal status: open title: Walrus comprehension rebind checking behavior type: behavior versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43281> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr
Saiyang Gou added the comment: Also the current behavior allows `(*x), y = 1` assignment. If `(*x)` is to be totally disallowed, `(*x), y = 1` should also be rejected. -- ___ Python tracker <https://bugs.python.org/issue40631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40631] PEG Parser: Cannot used starred expression in parenthesised expr
Saiyang Gou added the comment: Well, there is actually a bug: root@f1b4a742d8fc:/# python3.9 Python 3.9.1 (default, Dec 8 2020, 03:24:52) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> x = [1, 2] >>> y = 3 >>> *x, y (1, 2, 3) >>> (*x), y File "", line 1 (*x), y ^ SyntaxError: can't use starred expression here root@f1b4a742d8fc:/# python3.8 Python 3.8.6 (default, Oct 6 2020, 03:22:36) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> x = [1, 2] >>> y = 3 >>> *x, y (1, 2, 3) >>> (*x), y (1, 2, 3) This is different from the previous message where the starred expression is "alone" (and thus invalid). Since this bug happens in 3.9 but not in 3.8, it might be due to the PEG parser. Also, root@f1b4a742d8fc:/# python3.9 Python 3.9.1 (default, Dec 8 2020, 03:24:52) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> del *x File "", line 1 del *x ^ SyntaxError: cannot delete starred >>> del (*x) File "", line 1 del (*x) ^ SyntaxError: can't use starred expression here The latter case should also report "SyntaxError: cannot delete starred". -- nosy: +gousaiyang ___ Python tracker <https://bugs.python.org/issue40631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39567] Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()
Saiyang Gou added the comment: Should we backport this to 3.8? I believe that we should either backport this to 3.8 or document that these audit events are new in 3.9. -- nosy: +gousaiyang ___ Python tracker <https://bugs.python.org/issue39567> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)
Change by Saiyang Gou : -- pull_requests: +21604 pull_request: https://github.com/python/cpython/pull/22624 ___ Python tracker <https://bugs.python.org/issue39481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39481] Implement PEP 585 (Type Hinting Generics In Standard Collections)
Change by Saiyang Gou : -- nosy: +gousaiyang nosy_count: 6.0 -> 7.0 pull_requests: +21599 pull_request: https://github.com/python/cpython/pull/22619 ___ Python tracker <https://bugs.python.org/issue39481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41192] Some audit events are undocumented
Saiyang Gou added the comment: Hi Steve. If you had time could you review PR 21308, PR 21310 and PR 21322? Thanks! -- ___ Python tracker <https://bugs.python.org/issue41192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41897] ast.parse in Python 3.9 does not produce SyntaxError for assignment to __debug__
New submission from Saiyang Gou :
ast.parse in Python 3.9 does not produce SyntaxError for assignment to
__debug__:
```
>>> import ast
>>> ast.dump(ast.parse('__debug__ = 0'))
"Module(body=[Assign(targets=[Name(id='__debug__', ctx=Store())],
value=Constant(value=0))], type_ignores=[])"
>>> exec('__debug__ = 0')
Traceback (most recent call last):
File "", line 1, in
File "", line 1
SyntaxError: cannot assign to __debug__
```
In Python 3.8 a SyntaxError was properly raised. Probably this is due to the
new PEG parser.
--
components: Library (Lib)
messages: 377717
nosy: gousaiyang
priority: normal
severity: normal
status: open
title: ast.parse in Python 3.9 does not produce SyntaxError for assignment to
__debug__
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue41897>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41887] ast.literal_eval does not accept strings with leading whitespaces
New submission from Saiyang Gou :
`ast.literal_eval` does not accept code with leading whitespaces, while `eval`
accepts them, which is an inconsistency.
```
>>> import ast
>>> eval(' 1')
1
>>> ast.literal_eval(' 1')
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.9/ast.py", line 62, in literal_eval
node_or_string = parse(node_or_string, mode='eval')
File "/usr/local/lib/python3.9/ast.py", line 50, in parse
return compile(source, filename, mode, flags,
File "", line 1
1
IndentationError: unexpected indent
```
--
components: Library (Lib)
messages: 377687
nosy: gousaiyang
priority: normal
severity: normal
status: open
title: ast.literal_eval does not accept strings with leading whitespaces
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue41887>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39184] Many command execution functions are not raising auditing events
Saiyang Gou added the comment: Since the original problem (command execution functions missing audit events) is already solved, we can close this issue now. Further discussions on additional audit hooks (e.g. for the networking modules) could go to issue 37363. -- ___ Python tracker <https://bugs.python.org/issue39184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39184] Many command execution functions are not raising auditing events
Change by Saiyang Gou : -- pull_requests: +20473 pull_request: https://github.com/python/cpython/pull/21322 ___ Python tracker <https://bugs.python.org/issue39184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37363] Additional PEP578 hooks
Change by Saiyang Gou : -- nosy: +gousaiyang nosy_count: 4.0 -> 5.0 pull_requests: +20472 pull_request: https://github.com/python/cpython/pull/21321 ___ Python tracker <https://bugs.python.org/issue37363> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41192] Some audit events are undocumented
Change by Saiyang Gou : -- pull_requests: +20462 pull_request: https://github.com/python/cpython/pull/21310 ___ Python tracker <https://bugs.python.org/issue41192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41192] Some audit events are undocumented
Saiyang Gou added the comment: I've created PR 21308 for this. BTW, is issue 39567 (`os.walk`, `os.fwalk`, `pathlib.Path.glob` and `pathlib.Path.rglob`) intentionally not backported to 3.8? -- ___ Python tracker <https://bugs.python.org/issue41192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41192] Some audit events are undocumented
Change by Saiyang Gou : -- keywords: +patch pull_requests: +20460 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21308 ___ Python tracker <https://bugs.python.org/issue41192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41192] Some audit events are undocumented
Saiyang Gou added the comment: Update: `os.walk`, `os.fwalk`, `pathlib.Path.glob` and `pathlib.Path.rglob` are added and documented in 3.9. -- ___ Python tracker <https://bugs.python.org/issue41192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41192] Some audit events are undocumented
New submission from Saiyang Gou : Currently the following audit events are not documented on docs.python.org: - _winapi.CreateFile - _winapi.CreateJunction - _winapi.CreateNamedPipe - _winapi.CreatePipe - _winapi.CreateProcess - _winapi.OpenProcess - _winapi.TerminateProcess - ctypes.PyObj_FromPtr - object.__getattr__ - object.__setattr__ - object.__delattr__ - function.__new__ - setopencodehook - builtins.id - os.walk - os.fwalk - pathlib.Path.glob - pathlib.Path.rglob I'm going to create a PR to add them to the documentation. However, for `_winapi` events and `ctypes.PyObj_FromPtr`, I cannot find corresponding sections in the documentation to put the `audit-event` rst directive. How should we document them and make them show up in the audit events table? -- assignee: docs@python components: Documentation messages: 372806 nosy: docs@python, gousaiyang priority: normal severity: normal status: open title: Some audit events are undocumented type: enhancement versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40265] argparse.Namespace __repr__ does not handle reserved keywords
Saiyang Gou added the comment:
> The primary function of the Namespace class is to hold valid attributes and
> to allow the dot operator to access those attributes.
I acknowledge this. Invalid attribute names are not useful in production.
However, some crazy people like me would define arguments like these, producing
an repr string that does not round-trip:
>>> from argparse import ArgumentParser
>>> parser = ArgumentParser()
>>> parser.add_argument('-8')
>>> parser.add_argument('-@')
>>> parser.add_argument('--return')
>>> parser.parse_args(['-8', 'y', '-@', 'a.com', '--return', 'foo'])
Namespace(return='foo', **{'8': 'y', '@': 'a.com'})
(I know I can use the `dest` argument to define an alternative name to store in
the namespace.)
The reason why I open this issue is that I see issue 24360 already tried to
improve the repr string for invalid names by using the `isidentifier` check.
(Which is almost "as unuseful as this issue" for production use, since repr is
almost only used for development instead of production.) The original author
thought the improvement was enough to be round-trippable but missed the special
case of keywords, and my patch will fix this.
--
___
Python tracker
<https://bugs.python.org/issue40265>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40265] argparse.Namespace __repr__ does not handle reserved keywords
New submission from Saiyang Gou :
It is generally a convention to design the repr string such that
`eval(repr(obj))` can reproduce the object. Issue 24360 handles the special
situation when arg name passed to `argparse.Namespace` is not a valid
identifier:
>>> from argparse import Namespace
>>> Namespace(**{')': 3})
Namespace(**{')': 3})
However there is one more corner case to handle: the arg name could be a
reserved keyword.
>>> Namespace(**{'return': 3})
Namespace(return=3)
>>> Namespace(return=3)
File "", line 1
Namespace(return=3)
^
SyntaxError: invalid syntax
I noticed that the documentation of `str.isidentifier` tells me to also check
for keywords with `keyword.iskeyword`. However `__debug__` is not considered a
keyword by `keyword.iskeyword`, but cannot be assigned to:
>>> keyword.iskeyword('__debug__')
False
>>> Namespace(**{'__debug__':3})
Namespace(__debug__=3)
>>> Namespace(__debug__=3)
File "", line 1
SyntaxError: cannot assign to __debug__
I propose to enhance the arg name check in `argparse._AttributeHolder` from `if
name.isidentifier():` to `if name.isidentifier() and not
keyword.iskeyword(name) and name != '__debug__:'` to fix this. However this may
slow down the argparse library since it will need to `import keyword` at the
beginning, and `__repr__` will also be slower due to the added arg name checks.
By the way, when I came across issue 39076, I noticed that
`types.SimpleNamespace` is not considering this problem at all:
>>> types.SimpleNamespace(**{')': 1, 'return': 2})
namespace()=1, return=2)
--
components: Library (Lib)
messages: 366265
nosy: gousaiyang
priority: normal
severity: normal
status: open
title: argparse.Namespace __repr__ does not handle reserved keywords
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue40265>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39184] Many command execution functions are not raising auditing events
Saiyang Gou added the comment: Thanks for your review! PR 18407 is for the second list. For now I haven't added audit hooks for the http, socketserver and xmlrpc modules because they look a bit complex. There seems to be so many classes and methods to hook, we may need to find good places to hook (similar to what has been done on ftplib, imaplib, nntplib, poplib, smtplib, telnetlib and urllib). -- ___ Python tracker <https://bugs.python.org/issue39184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39184] Many command execution functions are not raising auditing events
Change by Saiyang Gou : -- pull_requests: +17782 pull_request: https://github.com/python/cpython/pull/18407 ___ Python tracker <https://bugs.python.org/issue39184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39184] Many command execution functions are not raising auditing events
Saiyang Gou added the comment: I have made PR 17824 to add auditing events for the command execution functions mentioned above. After a review on other related Python modules, I think maybe the following functions can also be audited, but a discussion may be required to determine whether they are necessary (whether these actions are sensitive enough to record, and performance trade off). - os.getenv/putenv/unsetenv - os.getcwd/chdir - os.chown/chmod - os.stat/access - os.link/symlink - os.rename/renames/replace - os.mkdir/mkdirs - os.remove/removedirs/rmdir/unlink (`shutil.rmtree` is already audited) - os.add_dll_directory - os.fork - os.kill/killpg - os.path.exists/isfile/isdir/... - signal.pthread_kill - shutil.copy* (`shutil.copytree` is already audited) - shutil.move - shutil.chown - shutil.unpack_archive (`shutil.make_archive` is already audited) - resource.prlimit - file operations in `msvcrt` - functions in `fcntl`, `syslog` - many high level networking modules such as `http.client/server`, `socketserver`, `xmlrpc` (the low-level `socket` calls are already audited) -- ___ Python tracker <https://bugs.python.org/issue39184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39184] Many command execution functions are not raising auditing events
Change by Saiyang Gou : -- keywords: +patch pull_requests: +17252 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17824 ___ Python tracker <https://bugs.python.org/issue39184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39184] Many command execution functions are not raising auditing events
New submission from Saiyang Gou : Similar to `os.system` (which is already raising auditing event), the following functions are also capable of command execution, so they also need auditing: - os.execl - os.execle - os.execlp - os.execlpe - os.execv - os.execve - os.execvp - os.execvpe - os.posix_spawn - os.posix_spawnp - os.spawnl - os.spawnle - os.spawnlp - os.spawnlpe - os.spawnv - os.spawnve - os.spawnvp - os.spawnvpe - os.startfile - pty.spawn By the way, since `os.listdir`, `shutil.copytree` and `shutil.rmtree` are already being audited, is it necessary to audit file operations in the `os` module like `os.remove`? -- messages: 359177 nosy: Saiyang Gou priority: normal severity: normal status: open title: Many command execution functions are not raising auditing events type: security versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
