Pablo Galindo Salgado added the comment:
Oh, wait. This looks incorrect:
https://github.com/pganssle/zoneinfo/blob/07ec80ad5dc7e7e4b4f861ddbb61a9b71e9f27c7/lib/zoneinfo_module.c#L619-L621
That
#ifndef ATLEAST_37
should be
#ifdef ATLEAST_37
Change by Pablo Galindo Salgado :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue42697>
___
___
Python-bugs-list mailing list
Unsubscribe:
Pablo Galindo Salgado added the comment:
I am quite sure that is the problem. I opened
https://github.com/pganssle/zoneinfo/pull/97 to correct this in the backport.
The standard library versions are ok.
Brandt, if you agree that this is indeed the problem, let's close this as "
Change by Pablo Galindo Salgado :
--
assignee: -> pablogsal
priority: release blocker ->
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyt
Pablo Galindo Salgado added the comment:
This is a recurring feature request (I have heard people asking for this a
couple of times) and is simple enough to do, so I am fine with this. Unless
Serhiy has some concern, I would go forward
Pablo Galindo Salgado added the comment:
I am with Lysandros and Batuhan. The parser is considerably coupled with the C
tokenizer and the only way to reuse *the parser* is to make flexible enough to
receive a token stream of Python objects as input and that can not only have a
performance
Pablo Galindo Salgado added the comment:
Isn't this the same as the problem described in
https://bugs.python.org/issue42164 ?
--
___
Python tracker
<https://bugs.python.org/is
Change by Pablo Galindo Salgado :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Pablo Galindo Salgado added the comment:
41010184880151d6ae02a226dbacc796e5c90d11 introduced some reference leaks:
https://buildbot.python.org/all/#/builders/384/builds/136
41010184880151d6ae02a226dbacc796e5c90d11 is the first bad commit
commit 41010184880151d6ae02a226dbacc796e5c90d11
Author
Pablo Galindo Salgado added the comment:
New changeset abba83b4b91f78dc556dc0b7700ecb46cba22c01 by Erlend Egeberg
Aasland in branch 'master':
bpo-42755: Fix sqlite3.Connection.backup docs (GH-23965)
https://github.com/python/cpython/commit/abba83b4b91f78dc556dc0b7700ecb
Change by Pablo Galindo Salgado :
--
nosy: -miss-islington
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +22824
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23979
___
Python tracker
<https://bugs.python.org/issu
Pablo Galindo Salgado added the comment:
I have added a draft PR on how the idea would look like so we can discuss with
a specific proposal.
--
___
Python tracker
<https://bugs.python.org/issue42
Pablo Galindo Salgado added the comment:
> This is a similar case. I am -1 for this optimization.
Yeah, I concur. One of the major drawbacks of this is that the normal case
where this happens involves a Load():
z = "something"
x = ["a", *z, "b"]
I see almo
Pablo Galindo Salgado added the comment:
> An optimized Python should always be built with LTO.
In MacOS is quite challenging to activate LTO, so normally optimized builds are
only done with PGO. Also in Windows I am not sure is possible to use LTO. Same
for many other platfo
Pablo Galindo Salgado added the comment:
>Wow, this is amazing. I just found that this is now faster than slots.
Not only that: is even faster than the highly-tuned namedtuple access
descriptors that used to be the faster access to an attribute:
3.9 results
---
17.6
Change by Pablo Galindo Salgado :
--
resolution: not a bug ->
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue40631>
___
___
Pyth
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +22854
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/24014
___
Python tracker
<https://bugs.python.org/issu
Change by Pablo Galindo Salgado :
--
pull_requests: +22855
pull_request: https://github.com/python/cpython/pull/24015
___
Python tracker
<https://bugs.python.org/issue40
Pablo Galindo Salgado added the comment:
> I'll work on finding out when this got messed up and fix it.
Apparently is
commit bca701403253379409dece03053dbd739c0bd059 (HEAD)
Author: Lysandros Nikolaou
Date: Tue Oct 27 00:42:04 2020 +0200
bpo-42123: Run the parser two times
Change by Pablo Galindo Salgado :
--
pull_requests: +22859
pull_request: https://github.com/python/cpython/pull/24019
___
Python tracker
<https://bugs.python.org/issue40
Pablo Galindo Salgado added the comment:
New changeset b5711c940f70af89f2b4cf081a3fcd83924f3ae7 by Jason R. Coombs in
branch 'master':
bpo-37193: Remove thread objects which finished process its request (GH-23127)
https://github.com/python/cpyt
Change by Pablo Galindo Salgado :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +22900
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24067
___
Python tracker
<https://bugs.python.org/issu
Pablo Galindo Salgado added the comment:
Seems that I also found this weird behaviour in the old parser:
import ast
code = """\
x = (
'PERL_MM_OPT', (
f'wat'
f'INSTALL-BASE={shlex.quote(venv)} '
f'w
Pablo Galindo Salgado added the comment:
New changeset bd2728b1e8a99ba8f8c2d481f88aeb99b8b8360f by Pablo Galindo in
branch 'master':
bpo-42806: Fix ast locations of f-strings inside parentheses (GH-24067)
https://github.com/python/cpython/commit/bd2728b1e8a99ba8f8c2d481f88aeb
Change by Pablo Galindo Salgado :
--
pull_requests: +22902
pull_request: https://github.com/python/cpython/pull/24069
___
Python tracker
<https://bugs.python.org/issue42
Change by Pablo Galindo Salgado :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Pablo Galindo Salgado added the comment:
New changeset bfc413ce4fa37ccb889757388102c7755e057bf5 by Pablo Galindo in
branch '3.9':
[3.9] bpo-42806: Fix ast locations of f-strings inside parentheses (GH-24067)
(GH-24069)
https://github.com/python/cpyt
Pablo Galindo Salgado added the comment:
Adding extra checks to PyErr_SetExcInfo doesn't have a lot of value because is
already out of of contract. If you pass an invalid object (let's say a list) to
any of the specific APIs (like PyDict_GetItem) it will crash anyway. We could
Change by Pablo Galindo Salgado :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Pablo Galindo Salgado :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Pablo Galindo Salgado added the comment:
Bisecting points at this commit as the culprit:
28b75c80dcc1e17ed3ac1c69362bf8dc164b760a is the first bad commit
commit 28b75c80dcc1e17ed3ac1c69362bf8dc164b760a
Author: Mark Shannon
Date: Wed Dec 23 11:43:10 2020 +
bpo-42246: Don&#
Pablo Galindo Salgado added the comment:
There is something wrong elsewhere as well because even if reverting that
commit fix the problem:
❯ git reset --hard upstream/master
HEAD is now at bd2728b1e8 bpo-42806: Fix ast locations of f-strings inside
parentheses (GH-24067)
~/github/python
Change by Pablo Galindo Salgado :
--
pull_requests: +22903
pull_request: https://github.com/python/cpython/pull/24070
___
Python tracker
<https://bugs.python.org/issue42
Pablo Galindo Salgado added the comment:
New changeset 9e8fe1986cb4205fb9f883c89b9d5d76a9847e0b by Pablo Galindo in
branch 'master':
bpo-42093: Tweak the what's new message about the new LOAD_ATTR opcode cache
(GH-24070)
https://github.com/python
Pablo Galindo Salgado added the comment:
This change seems to broke some buildbots. For instance:
https://buildbot.python.org/all/#/builders/119/builds/153
==
ERROR: test_colors_funcs (test.test_curses.TestCurses
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +22936
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24107
___
Python tracker
<https://bugs.python.org/issu
Pablo Galindo Salgado added the comment:
> Thanks! Do you have any plans for further inline caches?
Yeah, we are experimenting with some ideas here:
https://bugs.python.org/issue42115.
> I was wondering if we could reverse the situation for slots again by adding
> slots suppo
Pablo Galindo Salgado added the comment:
Thanks a lot Serhiy for the fantastic work!
--
___
Python tracker
<https://bugs.python.org/issue42681>
___
___
Pytho
Pablo Galindo Salgado added the comment:
I subscribe that but is also a matter of what are the optimizations with higher
ratio impact/(cost+complexity). Caching the function pointers on binary
operations or (better IMHO) comparisons is likely a good candidate
Pablo Galindo Salgado added the comment:
Agreed. In that regard the most standard thing that we have is the
pyperformance suite, which are almost all macro benchmarks. Is also what is
displayed in speed.python.org
--
___
Python tracker
<ht
New submission from Pablo Galindo Salgado :
Consider this file:
```
x = (
```
The error that we get is:
❯ python ../a.py
File "/home/pablogsal/github/python/master/../a.py", line 6
^
SyntaxError: unexpected EOF while parsin
This is quite uninformative of the actual problem
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +22988
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24161
___
Python tracker
<https://bugs.python.org/issu
Change by Pablo Galindo Salgado :
--
nosy: +lys.nikolaou
stage: patch review ->
___
Python tracker
<https://bugs.python.org/issue42864>
___
___
Python-
Change by Pablo Galindo Salgado :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue42899>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Pablo Galindo Salgado :
--
priority: high -> release blocker
___
Python tracker
<https://bugs.python.org/issue42899>
___
___
Python-bugs-list mai
Pablo Galindo Salgado added the comment:
> Pablo, are you OK closing this without a 3.8 backport?
I would be supportive, but we should check with Łukasz as he is the release
manager of 3.8
--
___
Python tracker
<https://bugs.python.org/issu
Pablo Galindo Salgado added the comment:
I will try to run today the pyperformance test suite to see if there is any
impact on standard attribute access
--
___
Python tracker
<https://bugs.python.org/issue42
Pablo Galindo Salgado added the comment:
These are the results:
venv ❯ python -m pyperf compare_to json_old/* -G --min-speed=2 --table
+-+--+--+
| Benchmark | 2021-01-14_09-40-master
Pablo Galindo Salgado added the comment:
So it seems that everything is in the noise range except the "float" benchmark
that is 1.11x faster
--
___
Python tracker
<https://bugs.python.o
Pablo Galindo Salgado added the comment:
Some microbenchmarks:
CURRENT MASTER:
Variable and attribute read access:
4.5 ns read_local
5.8 ns read_nonlocal
7.8 ns read_global
7.8 ns read_builtin
21.2 ns read_classvar_from_class
19.1 ns
Pablo Galindo Salgado added the comment:
> This is a great result, IMO. I'm +1 to merge this.
Same here. It would be good if Inada-san could confirm the benchmarks.
> Can you add a new one `read_slots`?
That should be "read_instancevar_slots". Or you refe
Pablo Galindo Salgado added the comment:
New changeset e5fe509054183bed9aef42c92da8407d339e8af8 by Lysandros Nikolaou in
branch 'master':
bpo-42827: Fix crash on SyntaxError in multiline expressions (GH-24140)
https://github.com/python/cpython/commit/e5fe509054183bed9aef42c92da840
Pablo Galindo Salgado added the comment:
> What is the next step?
I would say just finishing the PR (making sure that we do not miss some arcane
edge case) and updating the what's new for 3.10 :)
--
___
Python tracker
<https://bugs
Pablo Galindo Salgado added the comment:
New changeset d6d6371447357c9c69b0936573977a3e60f2 by Pablo Galindo in
branch 'master':
bpo-42864: Improve error messages regarding unclosed parentheses (GH-24161)
https://github.com/python/cpython/commit/d6d6371447357c9c69b0936573
Change by Pablo Galindo Salgado :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Pablo Galindo Salgado :
--
pull_requests: +23091
pull_request: https://github.com/python/cpython/pull/24266
___
Python tracker
<https://bugs.python.org/issue42
Pablo Galindo Salgado added the comment:
New changeset ae7d3cd980fae6b9a9778c0ccd162b93035ad33e by Pablo Galindo in
branch 'master':
bpo-42864: Fix compiler warning in the tokenizer with the new paren stack for
column numbers (GH-24266)
https://github.com/python/cpyt
New submission from Pablo Galindo Salgado :
We currently say:
Traceback (most recent call last):
File "/Users/pgalindo3/github/python/master/lel.py", line 5, in
A().foo(1,2)
TypeError: foo() takes 2 positional arguments but 3 were given
but we should say:
Traceback (most r
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +23095
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24272
___
Python tracker
<https://bugs.python.org/issu
Pablo Galindo Salgado added the comment:
> Can it be related to the commit a44ce6c9f725d336aea51a946b42769f29fed613 of
> this issue?
Quite likely. @mattip, can you investigate?
--
___
Python tracker
<https://bugs.python.org/i
Change by Pablo Galindo Salgado :
--
pull_requests: +23096
pull_request: https://github.com/python/cpython/pull/24273
___
Python tracker
<https://bugs.python.org/issue42
Pablo Galindo Salgado added the comment:
> I don't think this makes sense. How do you know there's a missing 'self'?
> Surely it's just as likely that there is indeed an extra argument. Especially
> if A.foo is defined by a library (stdib or 3rd party).
I u
Pablo Galindo Salgado added the comment:
> Seems that that guess will be wrong in most cases.
Maybe I am missing something. Could you list some cases where this will give
the wrong advice?
--
___
Python tracker
<https://bugs.pyth
Pablo Galindo Salgado added the comment:
> Do you also exclude class and static methods?
Yup, there is a test in the PR for that IIRC
>I still worry that this might confuse users when a library for some reason
>uses a different name than 'self'.
That's a good point
Pablo Galindo Salgado added the comment:
> Guido already listed them. Library functions, static and class methods,
PR 24272 will work on all those cases.
> and names like slf and _self (used either in local classes and wrapper
> functions to avoid conflict with the self paramet
Pablo Galindo Salgado added the comment:
Seems that this problem was introduced by
e5fe509054183bed9aef42c92da8407d339e8af8
--
___
Python tracker
<https://bugs.python.org/issue42
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +23102
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24279
___
Python tracker
<https://bugs.python.org/issu
Pablo Galindo Salgado added the comment:
Of course, being said all this, if the general consensus is that is not worth
the trouble, I am happy to retract the PR :)
--
___
Python tracker
<https://bugs.python.org/issue42
Pablo Galindo Salgado added the comment:
Thanks, everyone for your valuable comments and for explaining your concerns!
I will close the PR as it seems that there is no clear consensus that will be a
win after balancing the problems.
--
___
Python
Change by Pablo Galindo Salgado :
--
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Pablo Galindo Salgado :
Instead of displaying a generic syntax error:
Python 3.8.6 (default, Oct 10 2020, 18:31:21)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> fo
Change by Pablo Galindo Salgado :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue42997>
___
___
Python-bugs-list mailing list
Unsub
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +23113
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24292
___
Python tracker
<https://bugs.python.org/issu
Pablo Galindo Salgado added the comment:
There are several ways to implement this:
In PR24292 I implemented this idea by adding a new element to the grammar:
'&&'. This allows to hard-expect a token: if the token is not there the parsing
hard-fails immediately without tr
Change by Pablo Galindo Salgado :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue42997>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Pablo Galindo Salgado :
--
pull_requests: +23115
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24293
___
Python tracker
<https://bugs.python.org/issu
Pablo Galindo Salgado added the comment:
PR 24293 implements the second idea (only new rules and no new machinery)
--
___
Python tracker
<https://bugs.python.org/issue42
Pablo Galindo Salgado added the comment:
> About SIGSEGV logs, one option is to use ASAN_OPTIONS="handle_segv=0".
Opened https://github.com/python/buildmaster-config/pull/222
--
___
Python tracker
<https://bugs.pytho
Change by Pablo Galindo Salgado :
--
nosy: +pablogsal
nosy_count: 4.0 -> 5.0
pull_requests: +23132
pull_request: https://github.com/python/cpython/pull/24313
___
Python tracker
<https://bugs.python.org/issu
New submission from Pablo Galindo Salgado :
I have seen this confusion many users over the years. Instead of showing:
❯ python -c '[x,z for x,y in something]'
File "", line 1
[x,z for x,y in something]
^
SyntaxError: invalid syntax
We can show:
❯ ./python
Change by Pablo Galindo Salgado :
--
keywords: +patch
pull_requests: +23133
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24314
___
Python tracker
<https://bugs.python.org/issu
Change by Pablo Galindo Salgado :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue43017>
___
___
Python-bugs-list mailing list
Unsub
Change by Pablo Galindo Salgado :
--
priority: normal -> release blocker
___
Python tracker
<https://bugs.python.org/issue42986>
___
___
Python-bugs-list mai
Pablo Galindo Salgado added the comment:
> See also issue1634034.
The problem with issue1634034 is that is not anymore possible without manual
changes to the grammar with the PEG parser (or new infrastructure). The new
parser does not have a defined concept of "i expected this token
Pablo Galindo Salgado added the comment:
> It's basically a positive lookahead with a cut, but the extra feature that it
> raises a SyntaxError, right?
Yeah, but the cut is "absolute" (because of the syntax Error). IIRC the normal
cut only
Pablo Galindo Salgado added the comment:
I am -1 exposing the C-API of the tokenizer. For the new parser several
modifications of the C tokenizer had to be done and some of them modify
existing behaviour slightly. I don't want to corner ourselves in a place where
we cannot make improve
Change by Pablo Galindo Salgado :
--
Removed message: https://bugs.python.org/msg385782
___
Python tracker
<https://bugs.python.org/issue42115>
___
___
Python-bug
Pablo Galindo Salgado added the comment:
> I'm interested in it because the `tokenize` module is painfully slow
I assumed, but I don't feel confortable exposing the built-in one.
--
___
Python tracker
<https://bugs.pyth
Pablo Galindo Salgado added the comment:
> I assumed, but I don't feel confortable exposing the built-in one.
As an example of the situation, I want to avoid: every time we change anything
in the AST because of internal details we have many complains and pressure from
tool authors
Pablo Galindo Salgado added the comment:
For reimplementing Lib/tokenize.py we don't need to publicly expose anything in
the C-API. We can have a private _tokenize module with uses whatever you need
and then you use that _tokenize module in the tokenize.py file to reimplement
the
Pablo Galindo Salgado added the comment:
> private api sounds fine too -- I thought it was necessary to implement the
> module (as it needs external linkage) but if it isn't then even better
We can make it builtin the same way we do for the _ast module, or we can have a
new m
Pablo Galindo Salgado added the comment:
> Either works for me, would you be able to point me to the starting bits as to
> how `_ast` becomes builtin?
https://github.com/python/cpython/blob/master/Python/Python-ast.c#L10075-L10079
and
https://github.com/python/cpytho
Pablo Galindo Salgado added the comment:
> It might also make sense to build new tokenize.py apis avoiding the
> `readline()` api -- I always found it painful to work with
Then we would need to maintain the old Python APIs + the new ones using the
module? What you are proposing seem
Pablo Galindo Salgado added the comment:
I have built a draft of how the changes required to make what you describe, in
case you want to finish them:
https://github.com/pablogsal/cpython/tree/tokenizer_mod
--
___
Python tracker
<ht
Pablo Galindo Salgado added the comment:
Problems that you are going to find:
* The c tokenizer throws syntax errors while the tokenizer module does not. For
example:
❯ python -c "1_"
File "", line 1
1_
^
SyntaxError: invalid decimal literal
❯ python -m token
Change by Pablo Galindo Salgado :
--
pull_requests: +23199
pull_request: https://github.com/python/cpython/pull/24383
___
Python tracker
<https://bugs.python.org/issue42
Pablo Galindo Salgado added the comment:
> What am I missing? Why is the hash of the name needed?
To speed up the call to get the method from the dictionary using
_PyDict_GetItem_KnownHash. The reason I was not caching the method is that as
you mention there could still be an overrid
Pablo Galindo Salgado added the comment:
I am attaching to this issue a patch with PR 23503 restricted to only classes
without dict. I can measure a speedup but is super small (5%) in a function
that keeps calling a method for a builtin:
def foo(obj):
for _ in range(1):
res
2701 - 2800 of 4563 matches
Mail list logo
