[issue12782] Multiple context expressions do not support parentheses for continuation across lines
thautwarm added the comment: Maybe you should close this. -- ___ Python tracker <https://bugs.python.org/issue12782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12782] Multiple context expressions do not support parentheses for continuation across lines
thautwarm added the comment:
I can confirm Guido's words, now parentheses for continuation across lines are
already supported.
Even without parentheses, multiline with items can be supported. I just
implemented it here:
https://github.com/thautwarm/cpython/blob/bpo-12782/Grammar/python.gram#L180-L187
from contextlib import contextmanager
@contextmanager
def f(x):
try:
yield x
finally:
pass
# Ok
with f('c') as a,
f('a') as b:
pass
# Ok
with f('c') as a,
f('a') as b,
f('a') as c:
pass
# ERROR
with f('c') as a,
f('a') as b,
f('a') as c:
x = 1 + 1
# message:
File "/home/thaut/github/cpython/../a.py", line 49
x = 1 + 1
^
IndentationError: unindent does not match any outer indentation
level
# ERROR
with f('c') as a,
f('a') as b,
f('a') as c:
x = 1 + 1
File "/home/thaut/github/cpython/../a.py", line 49
x = 1 + 1
IndentationError: unexpected indent
The grammar is:
with_stmt[stmt_ty]:
| ...
| 'with' a=(',' [NEWLINE ~ INDENT?]).with_item+ ':' tc=[TYPE_COMMENT]
NEWLINE b=statements DEDENT {
_Py_With(a, b, NEW_TYPE_COMMENT(p, tc), EXTRA) }
| ...
The restriction here is, since the second 'with_item', until the end of
'statements', the expression and statements have to keep the same indentation.
with item1,
item2,
...:
block
The indentation of 'item2', ..., 'block' should be the same.
This implementation leverages the new PEG and how the lexer deals with
indent/dedent.
--
___
Python tracker
<https://bugs.python.org/issue12782>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40289] "highlighting" how to get Python's Scripts directory in the documentation
Change by thautwarm : -- assignee: -> docs@python components: +Documentation nosy: +docs@python versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40289] "highlighting" how to get Python's Scripts directory in the documentation
New submission from thautwarm : Currently it's barely impossible for us to search about "How to get where Scripts directory/folder is". If we google this, we can only get answers about '__file__', which is far from the expectation. The correct information lies on - https://github.com/python/cpython/blob/master/Doc/install/index.rst - https://github.com/python/cpython/blob/master/Lib/sysconfig.py It's also not the first time I want to google this but this is the first time I got the answer, by dipping into the source code and searching in the codebase. I'd hope we can directly mention the phrase "Python Scripts directory" in the documentation of 'sysconfig' module. -- messages: 366480 nosy: thautwarm priority: normal severity: normal status: open title: "highlighting" how to get Python's Scripts directory in the documentation ___ Python tracker <https://bugs.python.org/issue40289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32352] `inspect.getfullargspec` doesn't work fine for some builtin callable objects
Change by thautwarm : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue32352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39677] 3.6+ documentation for MAKE_FUNCTION
Change by thautwarm : -- pull_requests: +17930 pull_request: https://github.com/python/cpython/pull/18550 ___ Python tracker <https://bugs.python.org/issue39677> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39677] 3.6+ documentation for MAKE_FUNCTION
Change by thautwarm : -- keywords: +patch pull_requests: +17929 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/18549 ___ Python tracker <https://bugs.python.org/issue39677> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39677] 3.6+ documentation for MAKE_FUNCTION
thautwarm added the comment: Okay, I'll make a PR. It's okay because users will always check docs of version 3 instead of a specific version like 3.6. -- ___ Python tracker <https://bugs.python.org/issue39677> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39677] 3.6+ documentation for MAKE_FUNCTION
New submission from thautwarm : LINK: https://docs.python.org/3.6/library/dis.html?highlight=bytecode#opcode-MAKE_FUNCTION To avoid being confusing, MAKE_FUNCTION(argc) shall be MAKE_FUNCTION(flag), since 3.6 the operand of MAKE_FUNCTION never means `argcount`. -- assignee: docs@python components: Documentation messages: 362208 nosy: docs@python, thautwarm priority: normal severity: normal status: open title: 3.6+ documentation for MAKE_FUNCTION type: enhancement versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue39677> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34850] Emit a syntax warning for "is" with a literal
thautwarm added the comment:
Thanks.
However, unfortunately, this warning seems impossible to suppress.
Use following example:
import warnings
warnings.filterwarnings('ignore')
warnings.warn(SyntaxWarning("test"))
def f(x):
return x is 5
print(f(5))
I succeeded in suppressing my own SyntaxWarning("test") , but the output is
still:
python a.py
a.py:7: SyntaxWarning: "is" with a literal. Did you mean "=="?
return x is 5
True
--
___
Python tracker
<https://bugs.python.org/issue34850>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34850] Emit a syntax warning for "is" with a literal
thautwarm added the comment: What if using identity equality on integer literals is intended? I'm now trying to speed up the generated code via the integer interning mechanism told by https://docs.python.org/3/c-api/long.html#c.PyLong_FromLong . I think it okay to not complain when the operand of `is` or `is not` is an integer between -5 and 256. -- nosy: +thautwarm ___ Python tracker <https://bugs.python.org/issue34850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35632] support unparse for Suite ast
New submission from thautwarm : Although `Suite` is not an actual AST used in CPython, it's quite useful when performing some code analysis. `Suite` is a sequence of statements which could be used to represent a block whose context inherits from outside block's. Also, the document said it's useful in Jython. I wonder if we could support `unparse` for Suite through making a tiny modification to https://github.com/python/cpython/blob/master/Tools/parser/unparse.py def _Suite(self, tree): for stmt in tree.body: self.dispatch(stmt) -- components: Demos and Tools messages: 332845 nosy: thautwarm priority: normal severity: normal status: open title: support unparse for Suite ast type: enhancement versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35001] ImportFrom level cannot be optional
thautwarm added the comment: Firstly, allowing to construct ImportFrom without `level` specified could be the result of referring Python-asdl. Secondly, in C level, `level` is always an integer. Last but not the least, when you can access `level` from an ImportFrom AST, it must be an integer, not None. -- ___ Python tracker <https://bugs.python.org/issue35001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12782] Multiple context expressions do not support parentheses for continuation across lines
thautwarm added the comment:
How about:
with_stmt: 'with' (with_items | '(' with_items ')') ':' suite
ignored: INDENT | NEWLINE | DEDENT
with_items: with_item (ignored* ',' ignored* with_item)*
--
nosy: +thautwarm
___
Python tracker
<https://bugs.python.org/issue12782>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35001] ImportFrom level cannot be optional
thautwarm added the comment: @Anthony > I don't think mypy has an annotation for "sometimes has an attribute" Yes.. The annotation for an attribute that **maybe exist** cannot be expressed by mypy.. -- ___ Python tracker <https://bugs.python.org/issue35001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35001] ImportFrom level cannot be optional
thautwarm added the comment: Hi, Serhiy, for Python-asdl has made `level` able to optional, certainly we could construct an ImportFrom AST without giving `level`. Moreover, this might evidence that `level` cannot be optional in fact: https://github.com/python/cpython/blob/8e73ad38ab7d218b9ef8976032865928dfad00f1/Python/compile.c#L2918 -- ___ Python tracker <https://bugs.python.org/issue35001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35001] ImportFrom level cannot be optional
New submission from thautwarm :
This issue is found from a type hinting problem:
```
class ImportFrom(stmt): class ImportFrom(stmt):
module = ... # type: Optional[_identifier] module = ... # type:
Optional[_identifier]
names = ... # type: typing.List[alias] names = ... # type:
typing.List[alias]
level = ... # type: Optional[int]
```
As we can see that `level` here is optional, and it's strange.
I tried `ast.parse` on both Python 3.5/3.6, and found that None of `from a
import *`, `from .a import *`, `from ..a import *` and other regular cases
result into an ImportFrom AST whose `level` is None.
Then I went to Python-asdl:
https://github.com/python/cpython/blob/137b0632dccb992ca11e9445142fb33a29c33a51/Parser/Python.asdl#L44
and got
ImportFrom(identifier? module, alias* names, int? level)
It seems like a bug. To validate it, I went to
https://github.com/python/cpython/blob/97cf0828727ac2a269c89c5aa09570a69a22c83c/Python/ast.c#L3311
and got
static stmt_ty
ast_for_import_stmt(struct compiling *c, const node *n){
int idx, ndots = 0;
...
return ImportFrom(modname, aliases, ndots, lineno, col_offset,
c->c_arena);
...
}
It seems that no reason for `level` being None.
If it's really a bug, IMO it could be also an example that type hinting helps
to error detection :-)
--
assignee: docs@python
components: Documentation
messages: 327840
nosy: docs@python, thautwarm
priority: normal
severity: normal
status: open
title: ImportFrom level cannot be optional
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue35001>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34953] Implement `mmap.mmap.__repr__`
thautwarm added the comment: I think it depends on the use case. If `repr` wouldn't be invoked except debugging,some IO operations might not be that bad. I'm to make some adjustments to avoid displaying the contents if nothing evidence that IO operations is not bad. -- ___ Python tracker <https://bugs.python.org/issue34953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34953] Implement `mmap.mmap.__repr__`
thautwarm added the comment: @Ram Rachum Yes yes yes, actually the entire contents will be truncated when its length is bigger than a specific integer(now it's 50). For we use `...` to represent the ignored contents, `start ... end` could also be called *entire_contents* :-) -- ___ Python tracker <https://bugs.python.org/issue34953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34953] Implement `mmap.mmap.__repr__`
Change by thautwarm : -- keywords: +patch pull_requests: +9254 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34953] Implement `mmap.mmap.__repr__`
thautwarm added the comment: How about this: ``` # opened # closed ``` -- nosy: +thautwarm ___ Python tracker <https://bugs.python.org/issue34953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34880] About the "assert" bytecode
thautwarm added the comment: Hi, Serhiy, there could be an another way to fix all this sort of problems IMO. We can figure out all the cases that implicitly require shadow builtins, and then change symtable visitor to add corresponding free variables with name mangling, for instance: 1. implicitly add free variable ".AssertionError" ``` def f(): assert 1 ``` where ".AssertionError" is a name-mangled free variable and is assigned once the module is executed. The same to `StopAsyncIteration`, `TypeError`, `__build_class__` and so on. -- ___ Python tracker <https://bugs.python.org/issue34880> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34880] About the "assert" bytecode
thautwarm added the comment:
Reply to this:
> How is that different from every other case of shadowing a builtin?
>
> len = 45
> print(len("hello world"))
```
AssertionError = 42
assert 1 != 2
```
`assert` implicitly invokes `AssertionError`, while `len` does that explicitly.
That is to say, simply changing a global variable breaks the work of a keyword.
Another difference is that shadow builtins could be resumed in the
nested functions without something like `globals()` or `exec(..., {})`, while
you cannot perform this to the breakage of `assert`:
```
len = 1
def g():
from builtins import len
return len([1, 2, 3])
g() # => 3
AssertionError = +1
def f():
from builtins import AssertionError
assert False
f() # bm
```
--
___
Python tracker
<https://bugs.python.org/issue34880>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34880] About the "assert" bytecode
thautwarm added the comment: If we could generate `LOAD_CONST` instructions for `assert` statements, any prospective dangers could be avoided. ``` from dis import dis @dis def f(): assert x 3 0 LOAD_GLOBAL 0 (x) 2 POP_JUMP_IF_TRUE 8 4 LOAD_GLOBAL 1 (AssertionError) 6 RAISE_VARARGS1 >>8 LOAD_CONST 0 (None) 10 RETURN_VALUE ``` -- ___ Python tracker <https://bugs.python.org/issue34880> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34880] About the "assert" bytecode
thautwarm added the comment: Steven, this problem is quite interesting because it just allows users to cause fatal errors without any invalid operations. ``` AssertionError = 1 assert 1 == 2, 2 --- TypeError: 'int' object is not callable ``` It's better to deal with it seriously. -- nosy: +thautwarm ___ Python tracker <https://bugs.python.org/issue34880> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34845] allow exprlist as the iterators of comprehensions to be consistent with for statements
thautwarm added the comment: Well, sorry for that. -- ___ Python tracker <https://bugs.python.org/issue34845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34845] allow exprlist as the iterators of comprehensions to be consistent with for statements
Change by thautwarm : -- components: +Interpreter Core type: -> behavior versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue34845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34845] allow exprlist as the iterators of comprehensions to be consistent with for statements
New submission from thautwarm : Currently we can use `exprlist` as the iterator in a `for` statement: ``` for i in 1, 2,: print(i) 1 2 ``` However, when it comes to comprehension expressions: ``` [i for i in 1, 2] SyntaxError: invalid syntax ``` I know there might be some reason that leads to the absence of the consistency between `for` expression and statement, but IMO until now it could be better to allow `exprlist` to be the iterator of comprehensions. I'm not sure whether our community has noticed this problem so I'm to propose it here. A crucial benefit from this change is that we can avoid the ambiguity when a comprehension is accepted as function parameter. ``` f(for i in [1, 2, 3], 1, 2) ``` We now get a SyntaxError when writing such codes, but people who know this syntax might think the parameters can be distinguished from each other, but it's still not allowed. Allowing `exprlist` to be the iterator slot of a comprehension would be a rational solution. If `f(for i in [1, 2, 3], 1, 2)` is equivalent to `f(for i ([1, 2, 3], 1, 2))`, it will be natural to restrict the number of parameters to be just 1 when the parameter is a comprehension. You can slightly accept this workaround and try following examples: ``` f(for i in 1,) f(for i in 1, for j in 2, 3,) f(for i in 1, 2 if cond(i) for j in 3, for k in 4,) ``` Obviously, in each of above cases, the number of parameters is 1, just because a `exprlist` could the iterator of a comprehension. The disadvantage of this change is, there is not too many related use cases, for any `[expr for target in iter_elem1, iter_elem2, ...]` could be altered as `[expr for target in (iter_elem1, iter_elem2, ...)]`. Meanwhile, that might not be true when it comes to someone works frequently with interactive python. Finally, I have finished this implementation at https://github.com/thautwarm/cpython/tree/exprlist-in-comprehensions, and I do want to make contributions to cpython projects. If most of you feel comfortable with this change, may I make a PR next? -- messages: 326692 nosy: gvanrossum, serhiy.storchaka, thautwarm, yselivanov priority: normal severity: normal status: open title: allow exprlist as the iterators of comprehensions to be consistent with for statements ___ Python tracker <https://bugs.python.org/issue34845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32892] Remove specific constant AST types in favor of ast.Constant
thautwarm added the comment: Thank you, Serhiy. I learned python ast through ast.parse and pretty print, which prevented me from knowing this useful one. In fact, I wonder if we could support more species of constant values accepted by ast.Constant? -- ___ Python tracker <https://bugs.python.org/issue32892> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32892] Remove specific constant AST types in favor of ast.Constant
thautwarm added the comment: I'm in favor of this idea for prospective extensions that could be implemented through this brand-new ast.Constant. Actually I used to expect a more general ast.Constant when I was manipulating ASTs half a year ago, at that time my job is to make staging functions that take some user-defined types as constants(in these scenes, these types are definitely immutable and permanent) to gain performance improvements and avoid redundant allocations, and what I exactly wanted is such an ast.Constant. -- nosy: +thautwarm ___ Python tracker <https://bugs.python.org/issue32892> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32352] `inspect.getfullargspec` doesn't work fine for some builtin callable objects
thautwarm added the comment: Maybe a few adjustments to this one? -- ___ Python tracker <https://bugs.python.org/issue32352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32352] `inspect.getfullargspec` doesn't work fine for some builtin callable objects
New submission from thautwarm <yaoxiansa...@gmail.com>: It's quite confusing to me that `inspect.getfullargspec` crashed when it was applied on some builtin callable objects. ``` for each in __builtin__.__dict__: try: obj = getattr(__builtin__, each) if not callable(obj): continue inspect.getfullargspec(obj) except Exception as e: print(each, e) ``` Here are the results: ``` __build_class__ unsupported callable __import__ unsupported callable dir unsupported callable getattr unsupported callable iter unsupported callable max unsupported callable min unsupported callable next unsupported callable print unsupported callable round unsupported callable vars unsupported callable bool unsupported callable bytearray unsupported callable bytes unsupported callable classmethod unsupported callable complex unsupported callable dict unsupported callable enumerate unsupported callable filter unsupported callable float unsupported callable frozenset unsupported callable property unsupported callable int unsupported callable list unsupported callable map unsupported callable range unsupported callable reversed unsupported callable set unsupported callable slice unsupported callable staticmethod unsupported callable str unsupported callable super unsupported callable tuple unsupported callable type unsupported callable zip unsupported callable BaseException unsupported callable Exception unsupported callable TypeError unsupported callable StopAsyncIteration unsupported callable StopIteration unsupported callable GeneratorExit unsupported callable SystemExit unsupported callable KeyboardInterrupt unsupported callable ImportError unsupported callable ModuleNotFoundError unsupported callable OSError unsupported callable EnvironmentError unsupported callable IOError unsupported callable WindowsError unsupported callable EOFError unsupported callable RuntimeError unsupported callable RecursionError unsupported callable NotImplementedError unsupported callable NameError unsupported callable UnboundLocalError unsupported callable AttributeError unsupported callable SyntaxError unsupported callable IndentationError unsupported callable TabError unsupported callable LookupError unsupported callable IndexError unsupported callable KeyError unsupported callable ValueError unsupported callable UnicodeError unsupported callable UnicodeEncodeError unsupported callable UnicodeDecodeError unsupported callable UnicodeTranslateError unsupported callable AssertionError unsupported callable ArithmeticError unsupported callable FloatingPointError unsupported callable OverflowError unsupported callable ZeroDivisionError unsupported callable SystemError unsupported callable ReferenceError unsupported callable BufferError unsupported callable MemoryError unsupported callable Warning unsupported callable UserWarning unsupported callable DeprecationWarning unsupported callable PendingDeprecationWarning unsupported callable SyntaxWarning unsupported callable RuntimeWarning unsupported callable FutureWarning unsupported callable ImportWarning unsupported callable UnicodeWarning unsupported callable BytesWarning unsupported callable ResourceWarning unsupported callable ConnectionError unsupported callable BlockingIOError unsupported callable BrokenPipeError unsupported callable ChildProcessError unsupported callable ConnectionAbortedError unsupported callable ConnectionRefusedError unsupported callable ConnectionResetError unsupported callable FileExistsError unsupported callable FileNotFoundError unsupported callable IsADirectoryError unsupported callable NotADirectoryError unsupported callable InterruptedError unsupported callable PermissionError unsupported callable ProcessLookupError unsupported callable TimeoutError unsupported callable ``` -- components: Library (Lib) messages: 308488 nosy: thautwarm priority: normal severity: normal status: open title: `inspect.getfullargspec` doesn't work fine for some builtin callable objects type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
