New submission from Lysandros Nikolaou :
The new PEG parser fails when a parenthesised expression with a single child (a
group) contains a starred expression. Example:
╰─ ./python.exe
Python 3.9.0a6+ (heads/master-dirty:4a12d12186, May 15 2020, 14:53:45)
[Clang 11.0.0 (clang-1100.0.33.8
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Lysandros Nikolaou added the comment:
Understood.
--
___
Python tracker
<https://bugs.python.org/issue40612>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lysandros Nikolaou added the comment:
Agreed on everything.
One thing I don't really understand is if you propose to also strip trailing
whitespace. Does "limit the offset to just past the end of the source text"
include whitespace or not?
For example, the linked PR does
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +19387
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20083
___
Python tracker
<https://bugs.python.org/issu
New submission from Lysandros Nikolaou :
Tuples and lists, which are invalid augmented assignment targets, currently get
successfully parsed, without failing.
➜ cpython git:(targets-fix) ✗ ./python -X oldparser
Python 3.9.0a6+ (heads/master-dirty:75cd8e48c6, May 14 2020, 03:01
Change by Lysandros Nikolaou :
--
pull_requests: +19359
pull_request: https://github.com/python/cpython/pull/20050
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
I also concur with Guido here. I have played around with other languages and I
dislike getting a long list of expected tokens, that are not helpful, if not
actually confusing sometimes.
I think that the current generic SyntaxError description together
Lysandros Nikolaou added the comment:
Guido:
> I wonder if this is the fix we're looking for?
I think this is the most sensible thing to do, yes. I guess, we also have to
change both parsers to match this behaviour, right?
--
___
Python trac
Change by Lysandros Nikolaou :
--
pull_requests: +19315
pull_request: https://github.com/python/cpython/pull/20003
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
> Hm, but there the old parser seems at fault: it points to the last space
> rather than beyond it?
Both parsers seem to have the same behaviour, when parsing files. I just found
out that even the new parser points to the `|` if there is not tr
Lysandros Nikolaou added the comment:
That's because we're not checking for errors after a loop is done. Pushing a
fix.
--
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
> But if the col_offset points way past the text, what should happen? The
> clipping there seems reasonable.
Note that if a file is being parsed and not a string the behaviour is this:
╰─ cat -e t.py
x = 1 | 2 |$
╰─ ./python.exe t.py
File &
Lysandros Nikolaou added the comment:
Guido:
> I don't understand why the traceback module is implicated.
The traceback module is implicated, because it currently does not allow the
caret to point to a position after the error line.
In format_exception_only there is the following snip
Change by Lysandros Nikolaou :
--
title: Inconsistencies between pegen and traceback SyntaxErrors ->
Inconsistencies between PEG parser and traceback SyntaxErrors
___
Python tracker
<https://bugs.python.org/issu
New submission from Lysandros Nikolaou :
Since traceback is programmed to match the SyntaxErrors emitted by the old
parser, there are some inconsistencies between how it formats SyntaxErrors and
how the new parser does it. One example for such behaviour is the following:
New Parser
Change by Lysandros Nikolaou :
--
pull_requests: +19290
pull_request: https://github.com/python/cpython/pull/19973
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +19279
pull_request: https://github.com/python/cpython/pull/19963
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +19278
pull_request: https://github.com/python/cpython/pull/19962
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
Ok, I'm closing this, after consulting with Guido.
--
resolution: -> wont fix
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Lysandros Nikolaou :
--
nosy: -lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue40426>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lysandros Nikolaou added the comment:
The revert is in. Now the question is if we want to take additional action to
address the original issue of this.
--
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
After Serhiy unlinked the linked PR, it did not happen again, so it may have
been an one-off hiccup. I updated the description GH-19888 nevertheless.
--
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
PRs keep getting linked to this issue under my name, without me doing anything.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +19201
pull_request: https://github.com/python/cpython/pull/19888
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
I opened a pull request with an invalid bpo issue number so I unlinked it. Then
a completely unrelated PR was is shown as linked by me, but I didn't do that.
Unlinking that as well.
--
___
Python tracker
Change by Lysandros Nikolaou :
--
pull_requests: -19200
___
Python tracker
<https://bugs.python.org/issue40426>
___
___
Python-bugs-list mailing list
Unsub
Change by Lysandros Nikolaou :
--
pull_requests: +19200
pull_request: https://github.com/python/cpython/pull/19888
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: -19198
___
Python tracker
<https://bugs.python.org/issue40426>
___
___
Python-bugs-list mailing list
Unsub
Change by Lysandros Nikolaou :
--
nosy: +lys.nikolaou
nosy_count: 3.0 -> 4.0
pull_requests: +19198
pull_request: https://github.com/python/cpython/pull/19888
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
pull_requests: +19199
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/19888
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
pull_requests: +19197
pull_request: https://github.com/python/cpython/pull/19887
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
This isn't related to this issue, but to bpo-40246. Please report it there as
well.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
type: resource usage -> enhancement
___
Python tracker
<https://bugs.python.org/issue40334>
___
___
Python-bugs-list mai
Change by Lysandros Nikolaou :
--
pull_requests: +19179
pull_request: https://github.com/python/cpython/pull/19865
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
Since this issue is now resolved, I'm closing it, after I consulted with
pablogsal.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Lysandros Nikolaou added the comment:
This has been fixed in 3.9.0a6 due to the new parser:
╰─ cat a.py
s = ("apricot "
"pineapple"
f"shallot{")
╰─ ./python.exe a.py
File "/Users/lysnikolaou/Repositories/cpython/a.py", line 3
f"shal
Change by Lysandros Nikolaou :
--
pull_requests: +19157
pull_request: https://github.com/python/cpython/pull/19839
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +19147
pull_request: https://github.com/python/cpython/pull/19827
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
What's also possible is to handle keywords at tokenizer level and return a
different token type for each one of them (like with async and await), which is
currently handled at parser level. This would enable us to allow reserved
keywords right before
Lysandros Nikolaou added the comment:
A possible solution would be to only emit a SyntaxError if the NAME directly
preceding a STRING token contains one of the valid string prefixes (either one
of 'f', 'r', 'u', 'b'). This would still output a nicer error message, but
would not break code
Lysandros Nikolaou added the comment:
On bpo-40334 @vstinner reported that this change broke some code in turtledemo.
The code looks like this:
print(dict(state=clear, bg="#d00" if clear else"#fca"))
Due to the absence of a space between `else` and `"`, the else ke
Change by Lysandros Nikolaou :
--
pull_requests: +19098
pull_request: https://github.com/python/cpython/pull/19778
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +19094
pull_request: https://github.com/python/cpython/pull/19774
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +19091
pull_request: https://github.com/python/cpython/pull/19771
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +19066
pull_request: https://github.com/python/cpython/pull/19744
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +19065
pull_request: https://github.com/python/cpython/pull/19743
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
> test_peg_generator leaks references.
This is now fixed.
--
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
pull_requests: +19014
pull_request: https://github.com/python/cpython/pull/19694
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
> Warning -- files was modified by test_peg_generator
> Before: []
> After: ['parse_d.cp39-win_amd64.pdb', 'vc140.pdb']
Currently working on this.
--
___
Python tracker
<https://bug
Change by Lysandros Nikolaou :
--
pull_requests: +18999
pull_request: https://github.com/python/cpython/pull/19675
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
I propose skipping test_peg_generator for now, so that we don't hold the alpha6
release. It actually only tests the generator and not the parser and since we
don't plan on adding new operators in the very near future, we can skip it and
fix it after
Lysandros Nikolaou added the comment:
> test_peg_generator emits compiler warnings
These are expected. Is this a problem?
--
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
pull_requests: +18991
pull_request: https://github.com/python/cpython/pull/19669
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue40334>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +18871
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19521
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue40267>
___
___
Python-bugs-list mailing list
Unsubscrib
Lysandros Nikolaou added the comment:
It seems that this is actually a bit bigger than this and it is not specific to
f-strings.
The error message *always* changes to `unexpected EOF while parsing` if there
is an error with the last character of the input and no newline follows
New submission from Lysandros Nikolaou :
There are cases, where the error message differs, when an expression is being
parsed inside an fstring. For example:
>>> f'{x+}'
File "", line 1
(x+)
^
SyntaxError: unexpected EOF while parsing
>>> (
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +18830
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19476
___
Python tracker
<https://bugs.python.org/issu
Lysandros Nikolaou added the comment:
I have working code that checks if there is a quotation mark right after an
identifier. Here is an example:
╰─ ./python
Python 3.9.0a5+ (heads/pegen-dirty:502dfb719e, Apr 11 2020, 14:43:12)
[GCC 9.2.1 20191008] on linux
Type "help", "copyr
Lysandros Nikolaou added the comment:
In my understanding of the C code that's what the C tokenizer is doing as well.
Here's the relevant snippet of the tokenizer
(https://github.com/python/cpython/blob/4b222c9491d1700e9bdd98e6889b8d0ea1c7321e/Parser/tokenizer.c#L1358):
When the tokenizer
Lysandros Nikolaou added the comment:
At the moment, if the prefix is invalid, it gets tokenized as a NAME node and
the string following is tokenized as a STRING node with no prefix.
╰─ echo "ur''" | ./python -m tokenize
1,0-1,2:NAME 'ur'
Lysandros Nikolaou added the comment:
After some investigating, I found out that this is happening because when we
execute `fur''` in the interactive interpreter there is an implicit newline,
which means that EOF does not get reached.
OTOH there is no newline when passing it as a string
Change by Lysandros Nikolaou :
--
nosy: +gvanrossum, pablogsal
___
Python tracker
<https://bugs.python.org/issue40246>
___
___
Python-bugs-list mailing list
Unsub
New submission from Lysandros Nikolaou :
While testing pegen, we found this out:
Python 3.9.0a5+ (heads/pegen:502dfb719e, Apr 10 2020, 20:57:05)
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more informat
Lysandros Nikolaou added the comment:
That's right. I'll do that then. Thanks for baring with me.
Should we update the docs to mentiom this or just close this issue?
On Sat, Feb 15, 2020, 22:33 Vinay Sajip wrote:
>
> Vinay Sajip added the comment:
>
> In general, people shoul
Lysandros Nikolaou added the comment:
You're right! That could be very confusing. But isn't this risk already there,
since this could happen if one runs `python3.8 -m venv venv` and then
`python3.7` with the venv activated?
--
___
Python tracker
Lysandros Nikolaou added the comment:
The thing is that some projects I've worked on, like pegen, include a Makefile
which uses `pythonX.Y` to choose the version and I have to change it to
`python` quite frequently.
I can't really figure out any way this could harm anyone, other than what
New submission from Lysandros Nikolaou :
At the moment running python -m venv venv or python3 -m venv venv creates a
virtual environment that does not contain a python. symlink,
which results in executing whatever the default python is when running i.e.
python. within an activated virtual
Lysandros Nikolaou added the comment:
Are you going to work on a patch then, Batuhan?
--
___
Python tracker
<https://bugs.python.org/issue39474>
___
___
Pytho
Change by Lysandros Nikolaou :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue39474>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Lysandros Nikolaou :
--
pull_requests: +17783
pull_request: https://github.com/python/cpython/pull/18408
___
Python tracker
<https://bugs.python.org/issue39
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +17781
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18405
___
Python tracker
<https://bugs.python.org/issu
New submission from Lysandros Nikolaou :
There is a problem with the end_col_offset of nested Attribute nodes in
decorators. For example, parsing
@a.b.c
def f(): pass
produces the following AST tree (part):
decorator_list=[
Attribute(
value=Attribute(
value=Name
Lysandros Nikolaou added the comment:
> Can I ask how pegen solved this problem? Did you move parsing of f-strings
> into the grammar?
No, we actually do a very similar thing to what ast.c does.
I think there is only one major difference between what pegen does and what
ast.c does
Lysandros Nikolaou added the comment:
Also note that for pegen this is a solved problem. If we decide to change the
parser, it may not be worth it to spend too much time on a universal solution.
--
___
Python tracker
<https://bugs.python.
New submission from Lysandros Nikolaou :
When concatenating f-strings, if there is an expression in any STRING node
other than the first, col_offset of the parsed expression has a wrong value.
For example, parsing f"hello" f"{world}" outputs the following AST:
Module(
Change by Lysandros Nikolaou :
--
title: Parsed expression has wrong line/col info when concatenating f-strings
-> Parsed expression has wrong col_offset when concatenating f-strings
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
pull_requests: +17320
pull_request: https://github.com/python/cpython/pull/17582
___
Python tracker
<https://bugs.python.org/issue16
Lysandros Nikolaou added the comment:
Do you think it is okay to just remove the call to copy_location?
--
___
Python tracker
<https://bugs.python.org/issue39
New submission from Lysandros Nikolaou :
A normal generator expression like (i for i in a) produces the following AST:
Module(
body=[
Expr(
value=GeneratorExp(
elt=Name(
id="i", ctx=Load(), lineno=1, col_offset=1, en
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +17113
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17645
___
Python tracker
<https://bugs.python.org/issu
New submission from Lysandros Nikolaou :
When a starred expression like *[0, 1] is parsed, the following AST gets
generated:
Module(
body=[
Expr(
value=Starred(
value=List(
elts=[
Constant
Change by Lysandros Nikolaou :
--
pull_requests: +17068
pull_request: https://github.com/python/cpython/pull/17596
___
Python tracker
<https://bugs.python.org/issue39
Lysandros Nikolaou added the comment:
There was a bug in my last PR, hopefully I will get a fix some time later today.
The bug is as follows: I only updated the asdl_seq_SET call for an elif without
an else, if an else is included then the behavior is like before.
After my last PR it looks
Change by Lysandros Nikolaou :
--
pull_requests: +17059
pull_request: https://github.com/python/cpython/pull/17585
___
Python tracker
<https://bugs.python.org/issue39
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +17056
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17582
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
title: Inconsistent lineno and col_offset info when parsing elif ->
Inconsistency with lineno and col_offset info when parsing elif
___
Python tracker
<https://bugs.python.org/issu
New submission from Lysandros Nikolaou :
While working on pegen, we came across an inconsistency on how line number and
column offset info is stored for (el)if nodes. When parsing a very simple
if-elif construct like
if a:
pass
elif b:
pass
the following parse tree gets generated
Lysandros Nikolaou added the comment:
Pinging for review.
--
___
Python tracker
<https://bugs.python.org/issue36182>
___
___
Python-bugs-list mailing list
Unsub
Lysandros Nikolaou added the comment:
Mariatta noted at
https://mail.python.org/archives/list/core-mentors...@python.org/message/KFIGNAGJKWQXCXG72VGIGGA3OCKUHOFC/
that these issues are not reserved and are now available for first-time
contributors.
--
nosy: +lys.nikolaou
Lysandros Nikolaou added the comment:
Mariatta noted at
https://mail.python.org/archives/list/core-mentors...@python.org/message/KFIGNAGJKWQXCXG72VGIGGA3OCKUHOFC/
that these issues are not reserved and are now available for first-time
contributors.
--
nosy: +lys.nikolaou
Lysandros Nikolaou added the comment:
This can be most likely be closed. In the last days I had some unrelated
problems with my mac and had to do a full format. After reinstalling macOS the
problem went away, so it must have been something specific to my previous state
of things
Lysandros Nikolaou added the comment:
@brettcannon, yeah I saw that, but there hasn't been any progress since
November. I'm still interested in this though. What would the correct workflow
be? Pushing commits to the same PR or opening a new one with a co-author
New submission from Lysandros Nikolaou :
Since recently, Homebrew refuses to link sqlite. Upon researching the whole
thing, I found out that this is now considered a feature of Homebrew and not a
bug. Thus homebrew users on macOS do not get the SQLite module installed by
default, because
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Lysandros Nikolaou added the comment:
Is anybody still working on this?
--
___
Python tracker
<https://bugs.python.org/issue35328>
___
___
Python-bugs-list m
Change by Lysandros Nikolaou :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue35328>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Lysandros Nikolaou :
--
resolution: -> duplicate
___
Python tracker
<https://bugs.python.org/issue36966>
___
___
Python-bugs-list mailing list
Un
201 - 300 of 352 matches
Mail list logo
