Change by Batuhan Taskaya :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue44896>
___
___
Python-bugs-list mailing list
Unsubscrib
Batuhan Taskaya added the comment:
>From the first glance, this seems like a duplicate of bpo-44896.
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issu
Batuhan Taskaya added the comment:
ASDL technically allows it to be None though neither compiler nor ast.unparse
can work with it at this moment.
> FormattedValue(expr value, int? conversion, expr? format_spec)
https://github.com/python/cpython/blob/b127e70a8a682fe869c22ce04c379bd85a00d
Change by Batuhan Taskaya :
--
keywords: +patch
pull_requests: +28670
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30467
___
Python tracker
<https://bugs.python.org/issu
Batuhan Taskaya added the comment:
Should we backport this?
On Sat, Jan 8, 2022, 12:05 AM miss-islington wrote:
>
> miss-islington added the
> comment:
>
>
> New changeset d382f7ee0b98e4ab6ade9384268f25c06be462ad by Batuhan Taskaya
> in branch 'main':
Change by Batuhan Taskaya :
--
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.11 -Python 3.9
___
Python tracker
<https://bugs.python.org/i
Batuhan Taskaya added the comment:
The initial aim of the dis.Positions was to provide an interface like AST
nodes. So you could do
for instr in dis.Bytecode(source):
print("located in: ", instr.positions.lineno)
instead of
for instr in dis.Bytecode(source):
if instr
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
nosy_count: 3.0 -> 4.0
pull_requests: +28911
pull_request: https://github.com/python/cpython/pull/30720
___
Python tracker
<https://bugs.python.org/issu
Batuhan Taskaya added the comment:
New changeset 30fb6d073d9ca00dff8e4155c523cdfa63abab6b by Batuhan Taskaya in
branch 'main':
bpo-46441: Add a boilerplate to test syntax errors in interactive mode
(GH-30720)
https://github.com/python/cpython/commit/30fb6d073d9ca00dff8e4155c523cd
New submission from Batuhan Taskaya :
Superseeded by https://github.com/python/core-workflow/issues/425
--
resolution: -> later
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Batuhan Taskaya added the comment:
> Note that _PyArg_UnpackKeywordsWithVararg is defined with PyAPI_FUNC.
> Changing its argument spec is strictly a backwards incompatible change, IIUC.
AFAIK we have committed _PyArg_UnpackKeywordsWithVararg on 3.11 alpha, so I
think it should b
Batuhan Taskaya added the comment:
New changeset 1f715d5bd3bc9ff444e109b6bbd13011913681b1 by Nikita Sobolev in
branch 'main':
bpo-46483: change `PurePath.__class_getitem__` to return `GenericAlias`
(GH-30822)
https://github.com/python/cpython/commit/1f715d5bd3bc9ff444e109b6bbd130
Batuhan Taskaya added the comment:
New changeset 58f3d980989c7346ad792d464c1d749dcec6af63 by Nikita Sobolev in
branch 'main':
bpo-46422: use `dis.Positions` in `dis.Instruction` (GH-30716)
https://github.com/python/cpython/commit/58f3d980989c7346ad792d464c1d74
Batuhan Taskaya added the comment:
Technically, this is a bug on the fact that it breaks the only guarantee of
ast.unparse:
> Unparse an ast.AST object and generate a string with code that would produce
> an equivalent ast.AST object if parsed back with ast.parse().
But I am not
Batuhan Taskaya added the comment:
As Serhiy mentioned, this is a valid syntax.
--
nosy: +BTaskaya
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Batuhan Taskaya added the comment:
> It looks like calls in function arguments are ignored.
Please share a small, self-contained reproducer.
>From what I can assume by this message, the problem is that you are not
>calling self.generic_visit(node) on the first call you are handlin
Batuhan Taskaya added the comment:
Since this was already allowed in 3.9 and 3.10 stable relases, and since it is
consistent with the RHS of an assignment (something = *a, *b); I'd lean towards
keeping it (and maybe fixing the old parser's grammar to reflect that) and
docume
Change by Batuhan Taskaya :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Batuhan Taskaya added the comment:
New changeset 02815d939362d4093a95da650e7fbddabf147eb0 by Hakan Çelik in branch
'main':
bpo-29418: Add inspect.ismethodwrapper to whatsnew (GH-31377)
https://github.com/python/cpython/commit/02815d939362d4093a95da650e7fbddabf147eb0
-
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
nosy_count: 3.0 -> 4.0
pull_requests: +29968
pull_request: https://github.com/python/cpython/pull/19214
___
Python tracker
<https://bugs.python.org/issu
Change by Batuhan Taskaya :
--
pull_requests: -29968
___
Python tracker
<https://bugs.python.org/issue40001>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
nosy: -BTaskaya
___
Python tracker
<https://bugs.python.org/issue40001>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Batuhan Taskaya added the comment:
> This seams really inconsistent with the rest of the ast, where identifiers
> are always wrapped in a ast.Name object. The only other exception to this is
> ast.Attribute.
import ... as
from ... import ... as
try:
...
except ... as :
..
Batuhan Taskaya added the comment:
> @BTaskaya, do you have any interest in helping me iterate on new AST nodes?
Sure!
--
___
Python tracker
<https://bugs.python.org/issu
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue43521>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
The reason that we weren't support these cases was there were simply no way
achieve them by parsing code so we simply ignored (empty sets etc). Though
considering that you have a decent use case in hy, I'd agree that these small
additions
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue43563>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue43535>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
Hey @cleoold! Technically the second AST you gave is invalid (fun2),
considering that the FunctionType is not an expression;
mod = Module(stmt* body, type_ignore* type_ignores)
| FunctionType(expr* argtypes, expr returns)
expr = BoolOp
Batuhan Taskaya added the comment:
> @BTaskaya I've seen this in third party ides and type checker. For example
> they are referring to "Union[Callable[[], Union[int, str]], None]" as "() ->
> (int | str) | None" where there are parentheses around th
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue43684>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
If there is enough interest, I'd like to propose to this before the beta cut
--
___
Python tracker
<https://bugs.python.org/is
Batuhan Taskaya added the comment:
> I think I'd be okay if `foo[bar]: baz` and `foo.bar: baz` (etc.) didn't
> generate any bytecode at all. Is that what you're proposing here? If so, and
> assuming the code is reasonably straightforward, I'd say go ahead and ma
New submission from Batuhan Taskaya :
ASTs of case clauses for PEP 636 are not validated through PyAST_Validate right
now, which might crash the Python interpreter when compiling some trees that
doesn't hold the assumptions of the compiler.
--
assignee: BTaskaya
messages: 391469
Change by Batuhan Taskaya :
--
dependencies: +Make match patterns explicit in the AST
___
Python tracker
<https://bugs.python.org/issue43897>
___
___
Python-bug
Batuhan Taskaya added the comment:
> Batuhan, perhaps we should change the linked issue for your AST validator PR
> to this one. That way we can close the old catch-all PEP 634 implementation
> issue and keep the discussion focused here.
I think it might be better as a separate i
Change by Batuhan Taskaya :
--
keywords: +patch
pull_requests: +24213
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24771
___
Python tracker
<https://bugs.python.org/issu
Change by Batuhan Taskaya :
--
pull_requests: -23539
___
Python tracker
<https://bugs.python.org/issue42128>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
> Actually, I didn't see that there are still 2 open linked PRs. I'll wait
> until those are merged.
I've moved the AST validator to its own separate issue so feel free to close
this Brandt!
--
_
Change by Batuhan Taskaya :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue43897>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
> Batuhan, can you summarize the argument from the thread? What do you think
> yourself? Myself, I'm not sure either way, but it seems okay to remove the
> remnant bytecode.
I feel like we shouldn't generate code for these annotatio
Batuhan Taskaya added the comment:
> Hum, there seems to be an actual bug here: even with PEP 563, the annotations
> for "complex targets" are evaluated. For example:
Yes, that is what this issue is about. This bug only surfaced while doing other
stuff and PEP 563 being
Batuhan Taskaya added the comment:
> | MatchStar(identifier? target)
+1 on MatchStar(). Much more similiar to the existing node names, and also less
semantically-named.
> attributes (int lineno, int col_offset, int? end_lineno, int?
> end_col_offset)
I
Batuhan Taskaya added the comment:
I've posted an entry on python-dev to collect comments about how we should act
(whether just act them as strings on the symbol table or just forbid them
completely):
https://mail.python.org/archives/list/python-...@python.org/t
Batuhan Taskaya added the comment:
> Hopefully Batuhan has a recollection of what I am thinking of, there was some
> significant delay while we figured out what to do about some of these.
The major one that I'd recall is that inspect.signature() just uses whatever is
in __an
Batuhan Taskaya added the comment:
> This was easy in my 649 branch; walrus adds locals, and yield / yield from
> make it a generator. So the code raises an error if the generated
> annotations code object has locals or is a generator. I don't think I had to
> do an
Batuhan Taskaya added the comment:
> That can be done after the PEG grammar has accepted them
But wouldn't we still end up with maintaining a custom flag to see if we are in
annotation (e.g a: Something((yield) + 2)) and act upon that which would seem
to do a bit messy in the
Batuhan Taskaya added the comment:
New changeset 8cc3cfa8afab1651c4f6e9ba43a7ab7f10f64c32 by Batuhan Taskaya in
branch 'master':
bpo-42737: annotations with complex targets no longer causes any runtime
effects (GH-23952)
https://github.com/python/cpyt
Change by Batuhan Taskaya :
--
keywords: +patch
pull_requests: +24303
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25583
___
Python tracker
<https://bugs.python.org/issu
Change by Batuhan Taskaya :
--
resolution: -> postponed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Batuhan Taskaya added the comment:
Ah, seems like there is still one open PR. Keeping this up for that...
--
resolution: postponed ->
status: closed -> open
___
Python tracker
<https://bugs.python.org/i
Batuhan Taskaya added the comment:
Coverage runs are still failing on the master, and I think at least we should
do something like allow failure or other wise github will send notifications
for this flaky run.
--
nosy: +BTaskaya
___
Python
Batuhan Taskaya added the comment:
New changeset ad106c68eb00f5e4af2f937107baff6141948cee by Batuhan Taskaya in
branch 'master':
bpo-42725: Render annotations effectless on symbol table with PEP 563 (GH-25583)
https://github.com/python/cpython/commit/ad106c68eb00f5e4af2f937107baff
Batuhan Taskaya added the comment:
> Batuhan, can this issue be closed?
No, I still need to take care of what's new entry.
--
___
Python tracker
<https://bugs.python.org
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue43950>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Batuhan Taskaya :
Something that I've stumbled up while working on another patch is that, the
compiler doesn't revert the end_lineno and the end_col_offset attributes back
unlike regular lineno/col_offset. An example of this problem;
ar rcs libpython3.10d
Change by Batuhan Taskaya :
--
keywords: +patch
pull_requests: +24617
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25956
___
Python tracker
<https://bugs.python.org/issu
Batuhan Taskaya added the comment:
New changeset 13de28f17af02563cb8c6d0f6da3c178a4241ff3 by Miss Islington (bot)
in branch '3.10':
bpo-44063: set the missing end locations on the compiler (GH-25956) (#25972)
https://github.com/python/cpython/commit/13de28f17af02563cb8c6d0f6da3c1
Change by Batuhan Taskaya :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue44063>
___
___
Pyth
Change by Batuhan Taskaya :
--
pull_requests: +24630
pull_request: https://github.com/python/cpython/pull/25974
___
Python tracker
<https://bugs.python.org/issue42
Change by Batuhan Taskaya :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue42725>
___
___
Pyth
Change by Batuhan Taskaya :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue43417>
___
___
Pyth
New submission from Batuhan Taskaya :
Previously:
>>> import ast
>>> ast.unparse(ast.parse("lambda: 'hey!'"))
"lambda : 'hey!'"
Expected:
>>> import ast
>>> ast.unparse(ast.parse("lambda: 'hey!'&qu
Change by Batuhan Taskaya :
--
keywords: +patch
pull_requests: +24653
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26000
___
Python tracker
<https://bugs.python.org/issu
Batuhan Taskaya added the comment:
I've implemented a new revision that works without making slices hashable.
Updating PR 23496
--
___
Python tracker
<https://bugs.python.org/is
Change by Batuhan Taskaya :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue44081>
___
___
Pyth
New submission from Batuhan Taskaya :
This issue is for tracking possible places where we could generate better code
on ast.unparse (better as in more closely to what people are actually writing
than our naive implementation).
Examples;
>>> import ast
>>> ast.unparse(
Change by Batuhan Taskaya :
--
keywords: +patch
pull_requests: +24790
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26156
___
Python tracker
<https://bugs.python.org/issu
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue44187>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Batuhan Taskaya :
Since strings are immutable types, we could fold some operation on top of them.
Serhiy has done some work on issue 28307 regarding folding `str % args`
combination, which I think we can extend even further. One simple example that
I daily encounter is
Batuhan Taskaya added the comment:
> May I ask, is this going forward? I installed 3.11-dev, it's not there
> (though __future__ claims it should be). I understand if it isn't done yet,
> just want to know if there's risk it will be postponed again (or even give
Batuhan Taskaya added the comment:
> We should check on a real-world benchmark instead of a micro benchmark.
It is a pretty-targeted optimization, so I don't expect it to speed up the
macro benchmarks. Though that shouldn't be a blocker for small, targeted
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue44207>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
> 1. It can be a str subclass with an overridden __format__. In this case the
> result will be different.
Thanks! Though this should be possible to do, so not a blocker for suggestion
(if I am not missing something)
> 2. If it is a str subclass w
Change by Batuhan Taskaya :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue44273>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
I think this is a duplicate of issue 44273.
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue44
Change by Batuhan Taskaya :
--
components: +Interpreter Core -None
priority: low -> normal
title: Compiling evil ast crashes interpreter -> Compiling recursive Python
ASTs crash the interpreter
versions: +Python 3.11, Python 3.9
___
Python t
Change by Batuhan Taskaya :
--
pull_requests: +25116
pull_request: https://github.com/python/cpython/pull/26522
___
Python tracker
<https://bugs.python.org/issue11
New submission from Batuhan Taskaya :
import foo
def func():
return foo.bar()
The snippet above will generate the following code;
2 0 LOAD_GLOBAL 0 (foo)
2 LOAD_METHOD 1 (bar)
4 CALL_METHOD 0
6
Batuhan Taskaya added the comment:
@mark.shannon what do you think about doing this both for `import ` and
`from import `. It will definitely simplify the
implementation (no need to extra visitors or flags, just using the default
DEF_IMPORT one
https://github.com/isidentical/cpython
Batuhan Taskaya added the comment:
> Batuhan, can you take a look?
Yes.
--
___
Python tracker
<https://bugs.python.org/issue11105>
___
___
Python-bugs-lis
Change by Batuhan Taskaya :
--
nosy: +lukasz.langa
priority: normal -> release blocker
resolution: fixed ->
stage: resolved ->
status: closed -> open
___
Python tracker
<https://bugs.python
Batuhan Taskaya added the comment:
> The stack size for a window build is currently set to 2MB, which is usually
> lesser than *nix 8MB. So I think an easy solution is to increase the stack
> size for windows builds.
> I'm guessing release builds aren't affect
Change by Batuhan Taskaya :
--
pull_requests: +25137
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26550
___
Python tracker
<https://bugs.python.org/issu
Change by Batuhan Taskaya :
--
pull_requests: +25141
pull_request: https://github.com/python/cpython/pull/26554
___
Python tracker
<https://bugs.python.org/issue11
Batuhan Taskaya added the comment:
After playing with it for a couple hours and without much success of creating a
test environment (only using buildbots), I decided not to introduce hard
limits. Even though they make the original tests to pass, they don't solve the
problem overall and
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
nosy_count: 10.0 -> 11.0
pull_requests: +25148
pull_request: https://github.com/python/cpython/pull/26550
___
Python tracker
<https://bugs.python.org/issu
Batuhan Taskaya added the comment:
New changeset e58d762c1fb4ad5e021d016c80c2bc4513632d2f by Batuhan Taskaya in
branch 'main':
bpo-11105: reduce the recursion limit for tests (GH-26550)
https://github.com/python/cpython/commit/e58d762c1fb4ad5e021d016c80c2bc
Change by Batuhan Taskaya :
--
pull_requests: +25187
pull_request: https://github.com/python/cpython/pull/26604
___
Python tracker
<https://bugs.python.org/issue11
Change by Batuhan Taskaya :
--
pull_requests: +25188
pull_request: https://github.com/python/cpython/pull/26605
___
Python tracker
<https://bugs.python.org/issue11
Change by Batuhan Taskaya :
--
pull_requests: +25190
pull_request: https://github.com/python/cpython/pull/26607
___
Python tracker
<https://bugs.python.org/issue11
Batuhan Taskaya added the comment:
New changeset 8004c4570b1d1277ea8754e22b5eb60e63f5026c by Batuhan Taskaya in
branch 'main':
bpo-11105: document the new test.support.infinite_recursion context manager
(GH-26604)
https://github.com/python/cpyt
Batuhan Taskaya added the comment:
New changeset bd6f0d3eadfe5623657db6aeb69b94d21f86f4a0 by Batuhan Taskaya in
branch '3.10':
[3.10] bpo-11105: reduce the recursion limit for tests. (GH-26607)
https://github.com/python/cpython/commit/bd6f0d3eadfe5623657db6aeb69b94
Batuhan Taskaya added the comment:
New changeset 87f502231c6d5b04a4d8aa23fba24fcf5303aebb by Batuhan Taskaya in
branch '3.9':
[3.9] bpo-11105: reduce the recursion limit for tests. (GH-26605)
https://github.com/python/cpython/commit/87f502231c6d5b04a4d8aa23fba24f
Batuhan Taskaya added the comment:
The issue has been solved, all buildbots should now pass. Will continue to
monitor the situation. Thanks for the report @kj!
--
priority: release blocker ->
resolution: -> fixed
status: open ->
Change by Batuhan Taskaya :
--
stage: patch review -> resolved
status: pending -> closed
___
Python tracker
<https://bugs.python.org/issue11105>
___
___
Batuhan Taskaya added the comment:
Mark would you mind sharing your opinions on this:
https://bugs.python.org/issue44313 (should we still keep generating
LOAD_METHOD/CALL_METHOD for potential objects imported through `from x import
y`, or they also generate LOAD_ATTR/CALL_FUNCTION
Change by Batuhan Taskaya :
--
keywords: +patch
pull_requests: +25263
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26677
___
Python tracker
<https://bugs.python.org/issu
Batuhan Taskaya added the comment:
>From what I can share by my experience, this error happens soo much. So I'd
>love to see it.
For a more consistent message with others, maybe it could be something like
this;
SyntaxError: invalid syntax. Maybe you meant to use a different ty
1 - 100 of 652 matches
Mail list logo
