Lysandros Nikolaou added the comment:
That's right, but the SyntaxError message is somewhat confusing. At least the
fact that the SyntaxError message is some for both of
def a():
def b():
nonlocal x
and
def a():
nonlocal x
seems a bit misleading
Lysandros Nikolaou added the comment:
I feel that I wasn't clear at all in my previous responses, so let me try to
have another go at explaining how I see this:
We have two distinct problems, that are totally unrelated to one another:
1) nonlocal should raise when it's not in a nested
Lysandros Nikolaou added the comment:
> From what I understand, "checking for two or more hanging INDENTS" and,
> "hardcoding a check for nonlocal SyntaxErrors in codeop._maybe_compile" are
> two different solutions, right? If yes, do we have an answer to
Lysandros Nikolaou added the comment:
Thanks, Victor!
The fix is merged, so I'm closing this again.
--
___
Python tracker
<https://bugs.python.org/issue41
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Lysandros Nikolaou added the comment:
> If I understand correctly, Nick is talking about modifying the different
> iterations for different errors in codeop no?
I was talking about msg200936, where Nick proposed to just hardcode a check for
nonlocal SyntaxErrors in codeop._maybe_c
Lysandros Nikolaou added the comment:
> What do either of you think? Can the new parser handle it better?
Pablo, correct me if I'm wrong, but I think that the parser has nothing to do
with this. It's not the parser that produces this SyntaxError, it's some later
compilation phase (I gu
Change by Lysandros Nikolaou :
--
pull_requests: +20366
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/21212
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Lysandros Nikolaou :
--
pull_requests: +20340
pull_request: https://github.com/python/cpython/pull/21184
___
Python tracker
<https://bugs.python.org/issue41
Change by Lysandros Nikolaou :
--
pull_requests: +20339
pull_request: https://github.com/python/cpython/pull/21183
___
Python tracker
<https://bugs.python.org/issue41
Lysandros Nikolaou added the comment:
Should we maybe backport this to 3.9 as well?
--
___
Python tracker
<https://bugs.python.org/issue41084>
___
___
Python-bug
Lysandros Nikolaou added the comment:
Ok, I've opened a PR. Should be backport this to previous versions as well?
--
___
Python tracker
<https://bugs.python.org/issue41
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +20331
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21173
___
Python tracker
<https://bugs.python.org/issu
New submission from Lysandros Nikolaou :
The f-string parser uses the raw allocator in various places. We had a very
very brief discussion about this with Pablo and he suggested to change the new
parser and the hand-written f-string parser to use the pymalloc allocator.
Eric
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Lysandros Nikolaou :
--
pull_requests: +20330
pull_request: https://github.com/python/cpython/pull/21172
___
Python tracker
<https://bugs.python.org/issue41
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +20320
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21160
___
Python tracker
<https://bugs.python.org/issu
New submission from Lysandros Nikolaou :
Brandt found this out while testing his implementation of the `match`
statement. When a list or tuple are followed by a colon without an annotation,
the old parser used to say "invalid syntax", while the new parser considers
this an
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +20250
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21084
___
Python tracker
<https://bugs.python.org/issu
Lysandros Nikolaou added the comment:
> My only reservation would be: if the parsing of f-strings is moved into the
> parser, would it be possible to maintain the error new messages?
Probably without a single change.
--
___
Python tracker
New submission from Lysandros Nikolaou :
It's relatively easy to identify if a SyntaxError occurs when parsing an
fstring expression or not. The idea is to slightly change the error message to
start with "f-string: " when it does (in the same way in which SyntaxError
messages ar
Change by Lysandros Nikolaou :
--
title: Pre-feed the parser with the f-string location -> Pre-feed the parser
with the f-string expression location
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +20225
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21054
___
Python tracker
<https://bugs.python.org/issu
New submission from Lysandros Nikolaou :
Inspired by bpo-41064, I sat down to try and find problems with f-string
locations in the new parser. I was able to come up with a way to compute the
locations of the f-string expressions that I think is more consistent and
allows us to delete all
Lysandros Nikolaou added the comment:
Thanks Victor for the catch! I've opened a PR that deprecates PyNode_Compile in
3.9.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +20207
pull_request: https://github.com/python/cpython/pull/21036
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Lysandros Nikolaou :
--
pull_requests: +20196
pull_request: https://github.com/python/cpython/pull/21024
___
Python tracker
<https://bugs.python.org/issue41
Lysandros Nikolaou added the comment:
Thanks for the report, Steve. I've now opened a PR that should fix this.
--
___
Python tracker
<https://bugs.python.org/issue41
Change by Lysandros Nikolaou :
--
assignee: -> lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue41060>
___
___
Python-bugs-list mailing list
Un
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +20192
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21020
___
Python tracker
<https://bugs.python.org/issu
Lysandros Nikolaou added the comment:
On it.
--
___
Python tracker
<https://bugs.python.org/issue41060>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Lysandros Nikolaou :
--
pull_requests: +20190
pull_request: https://github.com/python/cpython/pull/21016
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +20186
pull_request: https://github.com/python/cpython/pull/21012
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +20179
pull_request: https://github.com/python/cpython/pull/21005
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
I'm currently testing a commit that removes all these files on my fork, before
I push it upstream. A question that I'm not 100% sure about is if we can
already remove the symbol module. I guess it's okay since it got deprecated in
3.9 (bpo-40759
Lysandros Nikolaou added the comment:
All parts of the implementation are now in. New issues should be opened for any
potential bugs.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracke
Change by Lysandros Nikolaou :
--
pull_requests: +20150
pull_request: https://github.com/python/cpython/pull/20973
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +20148
pull_request: https://github.com/python/cpython/pull/20970
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +20146
pull_request: https://github.com/python/cpython/pull/20968
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
> WIll make a PR soon
No need. Already got something ready.
--
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +20071
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20888
___
Python tracker
<https://bugs.python.org/issu
Lysandros Nikolaou added the comment:
I keep doing something wrong. I hope it is clean by now what the difference is.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
nosy: +gvanrossum, pablogsal
___
Python tracker
<https://bugs.python.org/issue40985>
___
___
Python-bugs-list mailing list
Unsub
Lysandros Nikolaou added the comment:
Copying and pasting the example messed the formatting up. Here it is again.
[16:49:16] lysnikolaou:cpython git:(master*) $ cat t.py
x = 6\%
[16:49:23
New submission from Lysandros Nikolaou :
While investigating bpo-40958, the following came up:
When a file ends with a line that contains a line continuation character the
text of the emitted SyntaxError is empty, contrary to the old parser, where the
error text contained the text
Lysandros Nikolaou added the comment:
> +Py_ssize_t linesize = PyUnicode_GET_LENGTH(line);
This line is wrong though, since PyUnicode_GET_LENGTH returns the length in
code points and PyUnicode_DecodeUTF8 expects the number of bytes. For non-ascii
input this would push the caret furt
Lysandros Nikolaou added the comment:
> Can you run the test suite before/after of pyflakes to make sure we don't
> introduce any regression to double check? If everything looks fine, open a PR
> :)
The exact same errors before and after! I'll wait on the PR though till someone
ha
Lysandros Nikolaou added the comment:
I'm guessing that some parts of the conversion code were only there to
circumvent issues in displaying the error messages that weren't pegen's fault.
These were fixed by Guido in GH-20072, so I think we can delete some of them.
For example, this patch
Lysandros Nikolaou added the comment:
> What happens with:
>>> "Ṕýţĥòñ" +
Exact same thing. The offset is 16 at the start and gets decreased to 15 in the
line I linked to in my previous post. And then col_offset gets converted to
col_number which is 9, which se
Lysandros Nikolaou added the comment:
> Note that although we could just exit if the length of the line is smaller
> than the column offset before calling
> https://github.com/python/cpython/blob/master/Parser/pegen.c#L148 (I assume
> that is the problem) is more important to un
Lysandros Nikolaou added the comment:
Is the only way to get gcc-10.1 to build from source? Because currently my
internet connection is too slow to get all of gcc downloaded and `apt install
gcc-10` installs 10.0.1, which I'm getting totally unrelated erros
Lysandros Nikolaou added the comment:
> Lysandros, are you using a debug build? The assert() won't trigger if you
> don't have run configure with --with-pydebug.
BTW I'm not talking about the assert not triggering. I'm only saying that
ASAN/UBSAN do not report an error when running
Lysandros Nikolaou added the comment:
I now configured Python with ./configure --with-pydebug
--with-address-sanitizer --with-undefined-behavior-sanitizer.
--
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
Let me try that. I'm currently using gcc 9.3.
--
___
Python tracker
<https://bugs.python.org/issue40958>
___
___
Python-bug
Lysandros Nikolaou added the comment:
Running Pablo's examples in the REPL does not reproduce the errors either:
➜ cpython git:(master) ✗
LSAN_OPTIONS="suppressions=asan-suppression.txt,print_suppressions=0" ./python
Modules/posixmodule.c:14682:9: runtime e
Lysandros Nikolaou added the comment:
I cannot reproduce this on my Ubuntu 20.04:
➜ cpython git:(master) ✗
LSAN_OPTIONS="suppressions=asan-suppression.txt,print_suppressions=0" ./python
-m test -v test_eof
Modules/posixmodule.c:14682:9: runtime error: left shift of 34 by 26 plac
Lysandros Nikolaou added the comment:
Agreed. For that I'd probably need the input Christian is getting the error
with. I'm currently trying things out, but haven't gotten the error yet.
--
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
> Lysandros, could you take a look?
Yup, I'm on it.
--
___
Python tracker
<https://bugs.python.org/issue40958>
___
_
Lysandros Nikolaou added the comment:
> This change broke this buildbot:
GH-20802 fixes this breakage.
--
___
Python tracker
<https://bugs.python.org/issu
Lysandros Nikolaou added the comment:
> Lysandros can you modify PR 20802 to remove it?
Yup!
--
___
Python tracker
<https://bugs.python.org/issue40939>
___
_
Change by Lysandros Nikolaou :
--
pull_requests: +19998
pull_request: https://github.com/python/cpython/pull/20802
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
> I would personally would like to keep the easter egg, but I assume is better
> to rename it to "__peg_parser__".
Ok then! On it.
--
___
Python tracker
<https://bugs.py
Lysandros Nikolaou added the comment:
> Can we rename the keyword to "__peg_parser__"?
I guess we could just remove this, as soon as the old parser is out. We were
only using this to differentiate between the two parsers, when we were testing
enabling/disabling the old one. I c
Change by Lysandros Nikolaou :
--
pull_requests: +19996
pull_request: https://github.com/python/cpython/pull/20800
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +19967
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20769
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
nosy: -lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue30533>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lysandros Nikolaou added the comment:
Since GH-10367 is now merged, should we close this?
--
___
Python tracker
<https://bugs.python.org/issue22021>
___
___
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Lysandros Nikolaou added the comment:
This is limited to cases where the line continuation character is on an
otherwise empty line. For example this works correctly:
$ cat t.py
print("hello world")
print("hello world 2") \
print("hello world 3")
$ ./python.exe
Change by Lysandros Nikolaou :
--
nosy: +gvanrossum, pablogsal
___
Python tracker
<https://bugs.python.org/issue40880>
___
___
Python-bugs-list mailing list
Unsub
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Lysandros Nikolaou :
--
pull_requests: +19666
pull_request: https://github.com/python/cpython/pull/20404
___
Python tracker
<https://bugs.python.org/issue38
Change by Lysandros Nikolaou :
--
resolution: -> wont fix
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Lysandros Nikolaou :
--
pull_requests: +19664
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/20402
___
Python tracker
<https://bugs.python.org/issu
Change by Lysandros Nikolaou :
--
versions: +Python 3.10 -Python 3.8
___
Python tracker
<https://bugs.python.org/issue38964>
___
___
Python-bugs-list mailin
Change by Lysandros Nikolaou :
--
keywords: +patch
nosy: +lys.nikolaou
nosy_count: 4.0 -> 5.0
pull_requests: +19662
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20399
___
Python tracker
<https://bugs.p
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Lysandros Nikolaou :
--
nosy: +gvanrossum, lys.nikolaou, pablogsal
___
Python tracker
<https://bugs.python.org/issue40716>
___
___
Python-bugs-list m
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +19522
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20235
___
Python tracker
<https://bugs.python.org/issu
New submission from Lysandros Nikolaou :
All the scripts in Tools/peg_generator/scripts need to be updated, since they
mostly assume that ast.parse and compile use the old parser. We can use the
_peg_parser extension module instead, but it well need some enhancements so
that it also supports
Change by Lysandros Nikolaou :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue40614>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lysandros Nikolaou added the comment:
Fixed in GH-20072 and bpo-40612.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Lysandros Nikolaou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Lysandros Nikolaou :
--
pull_requests: +19484
pull_request: https://github.com/python/cpython/pull/20183
___
Python tracker
<https://bugs.python.org/issue40
Lysandros Nikolaou added the comment:
> Doc/Makefile uses a virtual environment to install Sphinx and Sphinx
> extensions. I suggest to do something similar.
I like this approach. Let me try it.
--
___
Python tracker
<https://bugs.p
Lysandros Nikolaou added the comment:
Because `make time` and all the related Makefile targets use the local built
Python in the cpython parent directory. In order to install it, one would have
to go through various steps, like installing openssl, configuring python with
ssl support
Change by Lysandros Nikolaou :
--
keywords: +patch
pull_requests: +19471
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20172
___
Python tracker
<https://bugs.python.org/issu
New submission from Lysandros Nikolaou :
Running the PEG Parser benchmarks requires having memory_profiler installed.
In Tools/peg_generator:
➜ peg_generator git:(master) make time_stdlib
../../python -m zipfile -e data/xxl.zip data
../../python scripts/benchmark.py --parser=cpython --target
Lysandros Nikolaou added the comment:
I'm not getting any compiler warnings on macOS (clang) and on Ubuntu (gcc) and
I can't find any related warnings on the Windows Github Actions logs either.
Could you maybe post a verbose log of test_peg_generator, Raymond
Change by Lysandros Nikolaou :
--
pull_requests: +19464
pull_request: https://github.com/python/cpython/pull/20165
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +19456
pull_request: https://github.com/python/cpython/pull/20153
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +19454
pull_request: https://github.com/python/cpython/pull/20151
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
pull_requests: +19413
pull_request: https://github.com/python/cpython/pull/20106
___
Python tracker
<https://bugs.python.org/issue40
Change by Lysandros Nikolaou :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Lysandros Nikolaou added the comment:
Whoops, false alarm.
It's just that we moved the check for invalid starred expressions to the
parser, while it previously was in the compiler.
╰─ ./python.exe -X oldparser
Python 3.9.0a6+ (heads/master-dirty:003708bcf8, May 15 2020, 15:08:21)
[Clang
101 - 200 of 352 matches
Mail list logo
