Lysandros Nikolaou added the comment:
I agree that A is probably the way to go.
--
___
Python tracker
<https://bugs.python.org/issue46289>
___
___
Python-bug
Lysandros Nikolaou added the comment:
I like the newest suggestion by @Jelle better as well.
--
___
Python tracker
<https://bugs.python.org/issue47129>
___
___
Lysandros Nikolaou added the comment:
We can change the wording to `cannot` in order for all of the error messages to
be consistent. Would you like to propose a PR, Andre?
--
___
Python tracker
<https://bugs.python.org/issue43
Lysandros Nikolaou added the comment:
I'm okay with this, unless someone has any input on why the alias node should
not have line/column info (and did not have it in the first place).
--
nosy: +BTaskaya, gvanrossum, lys.nikolaou, pabl
Lysandros Nikolaou added the comment:
New changeset 75a06f067bd0a2687312e5f8e78f9075be76ad3a by Matthew Suozzo in
branch 'master':
bpo-43798: Add source location attributes to alias (GH-25324)
https://github.com/python/cpython/commit/75a06f067bd0a2687312e5f8e78f90
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Lysandros Nikolaou added the comment:
Hi Ohad and thanks for filing a report.
This is not a problem with CPython and outside of our control. You'd have to
ask this question to the PyCharm linter team (unfortunately I don't know where
exactly you would be able to do that)
Lysandros Nikolaou added the comment:
New changeset aef1b58dc8889e1bebaddf1e30f67b63a1b20f90 by Akira Nonaka in
branch 'main':
bpo-44345: Fix 'generated by' comment in parser.c (GH-26615)
https://github.com/python/cpython/commit/aef1b58dc8889e1bebaddf1e30f67b63a1b20f
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Lysandros Nikolaou :
Three rules (targets, target and t_atom) in the grammar are unreachable. We
were using them at some point in the past, but we never removed them when we
replaced them with other rules.
--
assignee: lys.nikolaou
components: Parser
messages
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +25241
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26655
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
pull_requests: +25245
pull_request: https://github.com/python/cpython/pull/26659
___
Python tracker
<https://bugs.python.org/issue44
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Lysandros Nikolaou added the comment:
Oh, this is a difficult one.
It's caused by GH-27506 that was recently added to produce better errors for
things like `print('hello' if something)`, where the correct syntax is
`print('hello' if something else 'hi'
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
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
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 :
--
pull_requests: +17059
pull_request: https://github.com/python/cpython/pull/17585
___
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: +17068
pull_request: https://github.com/python/cpython/pull/17596
___
Python tracker
<https://bugs.python.org/issue39
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 :
--
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 :
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
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
Change by Lysandros Nikolaou :
--
pull_requests: +17320
pull_request: https://github.com/python/cpython/pull/17582
___
Python tracker
<https://bugs.python.org/issue16
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
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(
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.
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
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
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
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 :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue39474>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lysandros Nikolaou added the comment:
Are you going to work on a patch then, Batuhan?
--
___
Python tracker
<https://bugs.python.org/issue39474>
___
___
Pytho
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:
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
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?
--
___
Pyth
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, pe
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
Change by Lysandros Nikolaou :
--
nosy: +gvanrossum, pablogsal
___
Python tracker
<https://bugs.python.org/issue40246>
___
___
Python-bugs-list mailing list
Unsub
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 a
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 &#x
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
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
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
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
>
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. For
Change by Lysandros Nikolaou :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue40267>
___
___
Python-bugs-list mailing list
Unsubscrib
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 :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue40334>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Lysandros Nikolaou :
--
pull_requests: +18991
pull_request: https://github.com/python/cpython/pull/19669
___
Python tracker
<https://bugs.python.org/issue40
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
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
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:
> Warning -- files was modified by test_peg_generator
> Before: []
> After: ['parse_d.cp39-win_amd64.pdb', 'vc140.pdb']
Currently working on this.
--
___
Python trac
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:
> test_peg_generator leaks references.
This is now fixed.
--
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
pull_requests: +19065
pull_request: https://github.com/python/cpython/pull/19743
___
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: +19091
pull_request: https://github.com/python/cpython/pull/19771
___
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: +19098
pull_request: https://github.com/python/cpython/pull/19778
___
Python tracker
<https://bugs.python.org/issue40
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
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
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 bef
Change by Lysandros Nikolaou :
--
pull_requests: +19147
pull_request: https://github.com/python/cpython/pull/19827
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +19157
pull_request: https://github.com/python/cpython/pull/19839
___
Python tracker
<https://bugs.python.org/issue40
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
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.pyth
Change by Lysandros Nikolaou :
--
pull_requests: +19179
pull_request: https://github.com/python/cpython/pull/19865
___
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
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/is
Change by Lysandros Nikolaou :
--
pull_requests: +19197
pull_request: https://github.com/python/cpython/pull/19887
___
Python tracker
<https://bugs.python.org/issue40
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 :
--
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: -19198
___
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: -19200
___
Python tracker
<https://bugs.python.org/issue40426>
___
___
Python-bugs-list mailing list
Unsub
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 tr
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:
PRs keep getting linked to this issue under my name, without me doing anything.
--
___
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:
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
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:
Ok, I'm closing this, after consulting with Guido.
--
resolution: -> wont fix
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
Change by Lysandros Nikolaou :
--
pull_requests: +19278
pull_request: https://github.com/python/cpython/pull/19962
___
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: +19290
pull_request: https://github.com/python/cpython/pull/19973
___
Python tracker
<https://bugs.python.org/issue40
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 :
--
title: Inconsistencies between pegen and traceback SyntaxErrors ->
Inconsistencies between PEG parser and traceback SyntaxErrors
___
Python tracker
<https://bugs.python.org/issu
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 sn
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:
That's because we're not checking for errors after a loop is done. Pushing a
fix.
--
___
Python tracker
<https://bugs.python.o
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
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:
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
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
Change by Lysandros Nikolaou :
--
pull_requests: +19359
pull_request: https://github.com/python/cpython/pull/20050
___
Python tracker
<https://bugs.python.org/issue40
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 :
--
keywords: +patch
pull_requests: +19387
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20083
___
Python tracker
<https://bugs.python.org/issu
1 - 100 of 352 matches
Mail list logo
