New submission from Batuhan Taskaya :
- Better error messages with punctuation
- Py_UNREACHABLE() for unreachable states
- Removal of several 'unused' and 'undocumented (in Zephyr ASDL spec) built-in
types.
--
components: Interpreter Core
messages: 368235
nosy: BT
Change by Batuhan Taskaya :
--
keywords: +patch
pull_requests: +19268
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19952
___
Python tracker
<https://bugs.python.org/issu
Batuhan Taskaya added the comment:
> You just read my thoughts. That's what I was going to do tonight. ;)
:) Awesome. Well I'll plan to continue this; @pablogsal and I was discussing
the idea of extracting _ast.AST subclasses to python level (which would save a
lot of time for
Batuhan Taskaya added the comment:
Currently working on implementing some items from this TODO
https://github.com/eliben/asdl_parser/blob/master/TODO
--
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
> I was also thinking about getting rid of "string" nodes and just use Constant
> for those. Having the strings raw make the AST inconsistent because nodes
> that are 'strings' do not have line numbers and other metadata,
Batuhan Taskaya added the comment:
Oh, I confuse with it identifier. IMHO replacing identifier with Constant would
infer position in some cases.
--
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
A real world example would be tools like `unimport`, that try to remove a
certain part of import by looking start/end column offsets. Before (lib2to3),
it was using tokens to manipulate source, and what I can tell is that having
position information on
Batuhan Taskaya added the comment:
Hey Raymond, can you give me your feedback on asdl.png (the screenshot of new
theme)?
--
Added file: https://bugs.python.org/file49133/asdl.png
___
Python tracker
<https://bugs.python.org/issue40
Change by Batuhan Taskaya :
--
pull_requests: +19282
pull_request: https://github.com/python/cpython/pull/19967
___
Python tracker
<https://bugs.python.org/issue40
Change by Batuhan Taskaya :
--
pull_requests: +19283
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19968
___
Python tracker
<https://bugs.python.org/issu
Batuhan Taskaya added the comment:
Unfortunately there aren't many `bold` type tokens I can use, so I had to
change color of module . If you wish I can make both class names and
`Python` bold, or keep it in this way.
--
Added file: https://bugs.python.org/file49134/asdl
Batuhan Taskaya added the comment:
(by the way, I did not push this change. I'll push it when you think it is
ready)
--
___
Python tracker
<https://bugs.python.org/is
Batuhan Taskaya added the comment:
Attaching 2 different styles python_bold.png (module is bold) and
asdl_no_style.png (module has no style)
--
Added file: https://bugs.python.org/file49135/python_bold.png
___
Python tracker
<ht
Change by Batuhan Taskaya :
Added file: https://bugs.python.org/file49136/asdl_no_style.png
___
Python tracker
<https://bugs.python.org/issue40517>
___
___
Python-bug
Batuhan Taskaya added the comment:
> I tried both a laptop and desktop and slightly prefer unbolded. How about a
> darker blue?
Sorry but I have no control over styles. They are pre-defined, I only change
the token type and pygments handles the rest of it. I dont know if such a
Batuhan Taskaya added the comment:
I've found a bold dark blue, which I guess suits both your and @terry.reedy
recommendations. How does bold_dark_blue.png looks?
--
Added file: https://bugs.python.org/file49138/bold_dark_blue.png
___
P
Batuhan Taskaya added the comment:
I've updated PR 17715 in order to point out exact field that error happened.
Also it now only shows type
>>> import ast
>>> expr_without_lineno_but_ok =
>>> ast.Expression(body=ast.BinOp(left=ast.Num(n=2), rig
Batuhan Taskaya added the comment:
I've updated the PR with bold_dark_blue.png changes.
--
___
Python tracker
<https://bugs.python.org/issue40517>
___
___
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue40546>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
Next is using asdl_int_seq for all simple sum types, and not for only cmpop.
Looks like it is hardcoded to use it, and I plan to refactor this in a way that
might save some time in python implementation of classes (also it will solve
this bug). For not
Batuhan Taskaya added the comment:
Thank you all for your reviews for styling, also I have to thank
https://github.com/CyberSaxosTiGER for his external reviews on the color scheme.
--
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
Any news about this? Should we revert the commit for 3.9?
--
___
Python tracker
<https://bugs.python.org/issue40244>
___
___
New submission from Batuhan Taskaya :
>>> dbm.open("/tmp/x.db", "n").close()
>>> from pathlib import Path
>>> tmp = Path("/tmp")
>>> dbm.open(tmp / "x.db", "n").close()
Traceback (most recent call last):
Fi
Batuhan Taskaya added the comment:
@rhettinger can you clarify how does this arguments act on argv? Should they be
hidden like the first argument, or should they remain visible as a passing
argument?
$ python -c 'import sys;print(sys.argv)'
['-c&
Change by Batuhan Taskaya :
--
pull_requests: +19354
pull_request: https://github.com/python/cpython/pull/20045
___
Python tracker
<https://bugs.python.org/issue39
Batuhan Taskaya added the comment:
See issue 39562
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue40604>
___
___
Python-bugs-list mailin
Batuhan Taskaya added the comment:
current:
>>> import time
>>> import time
>>> time.get_clock_info('thread_time')
namespace(adjustable=False,
implementation='clock_gettime(CLOCK_THREAD_CPUTIME_ID)', monotonic=True,
resolution=0.01)
>>
Batuhan Taskaya added the comment:
Should we mention about AIX support in availability section @vstinner?
https://docs.python.org/3/library/time.html#time.thread_time
--
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
> "Availability: Windows, Linux, Unix systems supporting
> CLOCK_THREAD_CPUTIME_ID." covers AIX.
That was my thought too, thanks again!
--
___
Python tracker
<https://bugs.py
Change by Batuhan Taskaya :
--
pull_requests: +19438
pull_request: https://github.com/python/cpython/pull/20133
___
Python tracker
<https://bugs.python.org/issue38
Change by Batuhan Taskaya :
--
pull_requests: +19439
pull_request: https://github.com/python/cpython/pull/20134
___
Python tracker
<https://bugs.python.org/issue38
Change by Batuhan Taskaya :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Batuhan Taskaya :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Batuhan Taskaya added the comment:
@RobHammann it should be resolved now, please feel free to re-open issue if you
get into trouble (I manually tested on solaris)
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Change by Batuhan Taskaya :
--
pull_requests: +19455
pull_request: https://github.com/python/cpython/pull/20152
___
Python tracker
<https://bugs.python.org/issue38
New submission from Batuhan Taskaya :
>>> from __future__ import annotations
>>> a: Type[int, str]
>>> b: Type[(int, str, *types)]
>>> __annotations__
{'a': 'Type[int, str]', 'b': 'Type[int, str, *types]'}
>>>
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue40662>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
keywords: +patch
pull_requests: +19459
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20156
___
Python tracker
<https://bugs.python.org/issu
Batuhan Taskaya added the comment:
$ python3.8
Python 3.8.0+ (heads/3.8:b9e5547f58, Nov 28 2019, 19:18:03)
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__
Change by Batuhan Taskaya :
--
components: +Interpreter Core
type: -> behavior
versions: +Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issu
Change by Batuhan Taskaya :
--
pull_requests: +19492
pull_request: https://github.com/python/cpython/pull/20191
___
Python tracker
<https://bugs.python.org/issue40
Change by Batuhan Taskaya :
--
pull_requests: +19493
pull_request: https://github.com/python/cpython/pull/20192
___
Python tracker
<https://bugs.python.org/issue40
Change by Batuhan Taskaya :
--
pull_requests: +19494
pull_request: https://github.com/python/cpython/pull/20193
___
Python tracker
<https://bugs.python.org/issue40
Batuhan Taskaya added the comment:
One thing to add, the proposed implementation also optimizes extended slices
(mostly used in scientific stacks) such as [:, 1].
--
___
Python tracker
<https://bugs.python.org/issue42
Batuhan Taskaya added the comment:
> By leaving slices unhashable, and accounting for their presence in
> code.__hash__, we get both the performance improvement and full backwards
> compatibility.
I thought about using code.__hash__ in the first place, but the compiler's
un
Batuhan Taskaya added the comment:
> I have to say that I feel that this will complicate things too much. Part of
> the appeal of this change is how straightforward and maintainable is.
> Fiddling with code objects lowers the watermark.
Agreed. And I'd go for either making s
Batuhan Taskaya added the comment:
Would it require a substantial amount of changes? If so, I don't think this is
a critical optimization since nearly-all of class definitions happens on the
module level and evaluated on the import time only once.
--
nosy: +BTa
Batuhan Taskaya added the comment:
> For instance, we have such code:
But what about this, what would the bytecode will look like in this case (where
the annotations don't exactly follow each other?)
a: int
T = TypeVar('T')
b: T
b1: Gen[T]
X = TypeVar('X')
c:
Change by Batuhan Taskaya :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue42525>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue42116>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
I don't see the point of augmenting the ast.parse, since we already have
variants of proper CST implementations outside the core python. Such as
github.com/davidhalter/parso/ or LibCST.
Also for basic refactorings, it is so easy to use tokens fo
Batuhan Taskaya added the comment:
> Every piece of code that uses either lib2to3 or a parser derived from it
> (including parso and LibCST) will eventually not be able to upgrade the
> parser because PEG can handle grammars that LL(k) can't.
Since these projects are external
Batuhan Taskaya added the comment:
> Parsing support for `f(**mapping)` support is indeed still missing.
>
> as lib2to3 is pending deprecation at this point, i'm not going to work on
> this. anyone is welcome to pick it up. modifying the lib2to3 grammar, and
> any rela
Batuhan Taskaya added the comment:
> Usually literal_eval() is used with short one-line input. For what large
> documents do you use it?
I kind of agree with Serhiy on this, nearly every use case I've encountered was
simple, single-line expression. Though, by seeing Irit's p
Batuhan Taskaya added the comment:
> I would be happy to update and fix it instead if you think it's better that
> way. Please let me know, it will be great to see my first submission being
> treated.
Yes, please. That seems mo
Change by Batuhan Taskaya :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue42561>
___
___
Python-bugs-list
Batuhan Taskaya added the comment:
This is a duplicate of issue 28964
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue42561>
___
___
Pytho
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue42611>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue42609>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
I don't have anything to add to this beside the name choice is safe and won't
clash with anything (but honestly I would prefer it to be discussed on the ML
before implementing something after 3 years). I checked a limited dataset to
search for
Batuhan Taskaya added the comment:
I'm +0 on this (even though we only had 2 users wanting this, the
implementation seems very trivial). @serhiy.storchaka, @pablogsal any opinions?
--
keywords: +gsoc -patch
nosy: +pablogsal
___
Python tr
Change by Batuhan Taskaya :
--
keywords: +patch -gsoc
___
Python tracker
<https://bugs.python.org/issue28964>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue42693>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue42246>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Batuhan Taskaya :
Since the annotations are processed just like all other expressions in the
symbol table, the generated entries for functions etc. This would result with
def foo():
for number in range(5):
foo: (yield number)
return number
foo
Batuhan Taskaya added the comment:
> It's been a while, I've lost context for this idea. What problem are you
> trying to solve here? Are there issues where people have reported problems
> that this would allow them to solve?
Context: https://github.com/python
Batuhan Taskaya added the comment:
This is another side effect of processing annotations (at the symbol table
construction stage) (and I would assume there are a few more cases like this);
def foo():
outer_var = 1
def bar():
inner_var: outer_var = T
return bar
Batuhan Taskaya added the comment:
> So I don't feel as strongly about that.
Just to note, since I believe the solution for all this might be the same (not
processing annotations at all, since they will be compiled to strings in the
later stage). If we go down on that route, it
Batuhan Taskaya added the comment:
New changeset eee1c7745ab4eb4f75153e71aaa2a62018b7625a by Batuhan Taskaya in
branch 'master':
bpo-41960: Add globalns and localns parameters to inspect.signature and
Signature.from_callable (GH-22583)
https://github.com/python/cpyt
Change by Batuhan Taskaya :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Batuhan Taskaya added the comment:
> I propose to close that gap, and establish an API which would allow to parse
> token stream (iterable) into an AST. An initial implementation for CPython
> can (and likely should) be naive, making a loop thru surface program
> representation
Batuhan Taskaya added the comment:
> That's exactly the implementation in the patch now submitted against this
> issue. But that's the patch for CPython, the motive of the proposal here is
> to establish a standard API call for *Python*, which different implementation
Batuhan Taskaya added the comment:
Thank you for your patch though!
--
___
Python tracker
<https://bugs.python.org/issue42729>
___
___
Python-bugs-list mailin
New submission from Batuhan Taskaya :
PEP 526 classifies everything but simple, unparenthesized names (a.b, (a),
a[b]) as complex targets. The way the we handle annotations for them right now
is, doing literally nothing but evaluating every part of it (just pushing the
name to the stack, and
Batuhan Taskaya added the comment:
I have a patch ready to go, but I'd prefer to block this issue until issue
42737 is resolved/decided.
--
___
Python tracker
<https://bugs.python.org/is
Batuhan Taskaya added the comment:
New changeset 586f3dbe15139cafb2a6ffb82cea146906561844 by Irit Katriel in
branch 'master':
bpo-28964: add line number of node (if available) to ast.literal_eval error
messages (GH-23677)
https://github.com/python/cpyt
Change by Batuhan Taskaya :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Batuhan Taskaya added the comment:
I concur with Terry.
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue42687>
___
___
Python-bugs-list m
New submission from Batuhan Taskaya :
Running test_asdl_parser raises a deprecation warning:
0:00:26 load avg: 1.05 [ 23/426] test_asdl_parser
:283: DeprecationWarning: the load_module() method
is deprecated and slated for removal in Python 3.12; use exec_module() instead
probably related
Change by Batuhan Taskaya :
--
keywords: +patch
pull_requests: +22799
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23952
___
Python tracker
<https://bugs.python.org/issu
Batuhan Taskaya added the comment:
> It will still perform run-time check which was an initial intention.
Well, at least from my personal perspective, I'd expect all annotations to
behave like strings regardless of their targets.
--
__
Batuhan Taskaya added the comment:
New changeset 0b281f94b9e5f117d774a1e4e834e797b2b21438 by Dong-hee Na in branch
'master':
bpo-42748: test_asdl_parser now uses exec_module instead of load_module (#23954)
https://github.com/python/cpython/commit/0b281f94b9e5f117d774a1e4e834e7
Batuhan Taskaya added the comment:
One thing to note here, currently Pablo and I are trying to bring annotation
unparsing from the compiler to the parser in issue 41967. If we do so, the
annotations won't cause any side effects on the symbol table generation.
--
nosy: +pabl
Batuhan Taskaya added the comment:
> Do we still need to represent annotation as a subtree in AST? Or make it just
> a string?
Possibly, we will just represent them as Constant()s. See issue 41967
--
___
Python tracker
<https://bugs.p
Batuhan Taskaya added the comment:
I think we should still evaluate the targets (even though the sole purpose of
this is just having a hint, the yield example seems serious), will update my
patch accordingly.
--
___
Python tracker
<ht
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue42754>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
We could possibly fold this at the AST optimizer, though I am not sure whether
this worths anything as an optimization since it is a real obscure pattern.
I've only found 2 occurrences (both from a test set on a relatively ~big
dataset of source
Change by Batuhan Taskaya :
--
Removed message: https://bugs.python.org/msg383911
___
Python tracker
<https://bugs.python.org/issue42754>
___
___
Python-bug
Batuhan Taskaya added the comment:
We could possibly fold this at the AST optimizer, though I am not sure whether
this worths anything as an optimization since it is a real obscure pattern.
I've only found 2 occurrences (both from the test suite of black) on a
relatively ~big datas
Batuhan Taskaya added the comment:
I've given this another shot, but even though I was able to create a patch that
preserved slices as (type(slice), start, stop, step) tuples in the
consts_cache, this final optimization prevented me to finalize it;
😃https://github.com/python/cpython
Batuhan Taskaya added the comment:
I also agree with Raymond's opinion, and from the point that it didn't get much
attention I'd assume not many people need it. So count me as -1
--
nosy: +BTaskaya
___
Python tracker
<https
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue42837>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
Well even though I still don't understand 'how this issue is different than
issue42725', I don't think you actually fix the symbol table;
see this one: https://bugs.python.org/msg383659
Annotations still have side effects on the symbo
Batuhan Taskaya added the comment:
It is actually much easier now, considering that we are operating on the AST
instead of the token stream. You probably only have to add a new field to
Function/Class classes for end_lineno and access .end_lineno attribute here
just like how we do for
Change by Batuhan Taskaya :
--
nosy: +BTaskaya
___
Python tracker
<https://bugs.python.org/issue42927>
___
___
Python-bugs-list mailing list
Unsubscribe:
Batuhan Taskaya added the comment:
> The use of nonlocal variables in an annotation will be a syntax error in
> Python 3.10
What is the reasoning for forbidding nonlocal variables
(https://bugs.python.org/msg383659), can't we just treat them like regular
variables and leave t
Change by Batuhan Taskaya :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.9
___
Python tracker
<https://bugs.python.or
Batuhan Taskaya added the comment:
New changeset 15bd9efd01e44087664e78bf766865a6d2e06626 by Anthony Sottile in
branch 'master':
bpo-43014: Improve performance of tokenize.tokenize by 20-30%
https://github.com/python/cpython/commit/15bd9efd01e44087664e78bf766865a6d2e06626
-
Change by Batuhan Taskaya :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Batuhan Taskaya added the comment:
> @BTaskaya, do you think you'll have time to open a PR with your AST validator
> this weekend? It looks good to me (assuming tests pass).
Unfortunately not. I believe it still lacks tests for invalid cases, but other
than that should work. If
601 - 700 of 891 matches
Mail list logo
