thautwarm added the comment:
Maybe you should close this.
--
___
Python tracker
<https://bugs.python.org/issue12782>
___
___
Python-bugs-list mailing list
Unsub
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
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/issu
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.
Change by thautwarm :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue32352>
___
___
Python-bugs-list
Change by thautwarm :
--
pull_requests: +17930
pull_request: https://github.com/python/cpython/pull/18550
___
Python tracker
<https://bugs.python.org/issue39
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/issu
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/issue39
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
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
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
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
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
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
<ht
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 tr
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
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
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
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
Change by thautwarm :
--
keywords: +patch
pull_requests: +9254
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34953>
___
___
Python-
thautwarm added the comment:
How about this:
```
# opened
# closed
```
--
nosy: +thautwarm
___
Python tracker
<https://bugs.python.org/issue34953>
___
___
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
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
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
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
thautwarm added the comment:
Well, sorry for that.
--
___
Python tracker
<https://bugs.python.org/issue34845>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by thautwarm :
--
components: +Interpreter Core
type: -> behavior
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issue34845>
___
_
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
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
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
thautwarm added the comment:
Maybe a few adjustments to this one?
--
___
Python tracker
<https://bugs.python.org/issue32352>
___
___
Python-bugs-list mailin
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 callab
32 matches
Mail list logo
