Change by Guido van Rossum :
--
pull_requests: +19022
pull_request: https://github.com/python/cpython/pull/19704
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
New changeset 0e80b561d442769631d66f1cc8813ac30f97378e by Guido van Rossum in
branch 'master':
bpo-40334: Add What's New sections for PEP 617 and PEP 585 (GH-19704)
https://github.com/python/cpython/commit/0e80b561d442769631d66f1cc
Guido van Rossum added the comment:
In commit 0e80b561d442769631d66f1cc8813ac30f97378e a What's New section was
added.
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
@Anthony: Presumably some of these will be unavoidable. I see you have
PYPY-specific checks in your code already.
You could also help by sending us the test programs and the different output
produced by the old and the new parser. You could either create
Guido van Rossum added the comment:
Maybe it could return (Ellipsis, Any) in that case. The most general form of
Callable is Callable[..., Any] and that's that get_args() returns for that.
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
Agreed, that's better!
--
___
Python tracker
<https://bugs.python.org/issue40398>
___
___
Python-bugs-list mailing list
Guido van Rossum added the comment:
I declare this not a bug.
The docs do not promise that the Futures being returned are the *same* Futures
that were passed in. They are not. They are (or at least may be) new Futures
that represent the same event. Since Futures, when used as dict keys, use
Guido van Rossum added the comment:
Reopening so as to give the OP one more chance to state their case. They wrote:
"""
You've immediately closed the issue so I couldn't even reply to it,
Unfortunately, it doesn't return a Future object at all, so technically yo
Guido van Rossum added the comment:
Oh, you're right. The docstring correctly says this. :-(
Do you have the power to submit a PR? I think it should just say that the
return values are coroutines (which is what it does). @Yury what do you think?
--
resolution: not
Guido van Rossum added the comment:
Good catch. Is there a reasonable fix?
--
___
Python tracker
<https://bugs.python.org/issue40408>
___
___
Python-bugs-list m
Guido van Rossum added the comment:
@phr: examples welcome! The bigger and nastier, the better. This *should* all
be speedy but it wouldn't hurt to check.
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
Looks reasonable.
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue40291>
___
___
Python-bugs-list m
Change by Guido van Rossum :
--
pull_requests: +19100
pull_request: https://github.com/python/cpython/pull/19780
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
Personally I don't think that `else"stuff"` should become a syntax error. It's
no different from other edge cases where for some reason the space seems
optional, like `1and 2`.
--
___
Py
Guido van Rossum added the comment:
Please work this out in the PR between the two of you, Kyle and Bar.
--
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
If it's all handled by the tokenizer, how come it's different in the new
parser?
Anyway, it seems we really have to support what the old parser supported
here. I don't know exactly what rules it uses. Maybe only look for a string
quote follow
Guido van Rossum added the comment:
Thanks, good luck using this!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
New changeset 138a9b9c2a394f30f222c23391f9515a7df9d809 by Vlad Serebrennikov in
branch 'master':
bpo-40389: Improve repr of typing.Optional (#19714)
https://github.com/python/cpython/commit/138a9b9c2a394f30f222c23391f9515a7df9d809
-
Change by Guido van Rossum :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue40389>
___
___
Pyth
Guido van Rossum added the comment:
It's typically not up to the core devs to pick a winning third party library;
we tend to recommend libraries that are already essentially category winners,
like requests. In a sense pointing to LibCST *and* parso is redundant because
LibCST buil
Guido van Rossum added the comment:
A "What's New" entry would go into Doc/whatsnew/3.9.rst and is much more
visible to users looking for exciting bits in the new release (the NEWS file is
very large, see e.g.
https://docs.python.org/3/whatsnew/changelog.html#changelog.
The
Guido van Rossum added the comment:
IIRC PendingDeprecationError does not mean that the decision hasn't been made
yet. It just means it's less urgent for folks to worry about. I believe we tend
to change PendingDeprecationError to DeprecationError in the last release
before so
Guido van Rossum added the comment:
New changeset c001c09e9059ba04bc088349cd87a1374dc0754f by Guido van Rossum in
branch 'master':
bpo-40334: Support type comments (GH-19780)
https://github.com/python/cpython/commit/c001c09e9059ba04bc088349cd87a1
Guido van Rossum added the comment:
New changeset 2514a632fb7d37be24c2059d0e286d35600f9795 by Chris Jerdonek in
branch 'master':
bpo-29587: Enable implicit exception chaining with gen.throw() (GH-19811)
https://github.com/python/cpython/commit/2514a632fb7d37be24c2059d0e286d
Guido van Rossum added the comment:
Example 1 is now fixed too by Chris Jerdonek's PR 19811. Thanks Chris!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
Guido van Rossum added the comment:
Oh, no! Buildbot failures. Help?!
--
___
Python tracker
<https://bugs.python.org/issue29587>
___
___
Python-bugs-list mailin
Change by Guido van Rossum :
--
resolution: fixed ->
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue29587>
___
___
Python-bugs-
Guido van Rossum added the comment:
Could it be running out of memory due to excessive chaining of tracebacks?
(And yes, it's 3.9 only.)
--
___
Python tracker
<https://bugs.python.org/is
Change by Guido van Rossum :
--
pull_requests: +19148
pull_request: https://github.com/python/cpython/pull/19828
___
Python tracker
<https://bugs.python.org/issue40
Change by Guido van Rossum :
--
pull_requests: +19150
pull_request: https://github.com/python/cpython/pull/19830
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
New changeset 3e0a6f37dfdd595be737baae00ec0e036a912615 by Lysandros Nikolaou in
branch 'master':
bpo-40334: Add support for feature_version in new PEG parser (GH-19827)
https://github.com/python/cpython/commit/3e0a6f37dfdd595be737baae00ec0e
Guido van Rossum added the comment:
New changeset ea7297cf8f1aad4df8921a3d81a75118511afe77 by Pablo Galindo in
branch 'master':
bpo-40334: unskip test_function_type in test_unparse with the new parser
(GH-19837)
https://github.com/python/cpyt
Guido van Rossum added the comment:
New changeset d955241469c18c946924dba79c18a9ef200391ad by Pablo Galindo in
branch 'master':
bpo-40334: Correct return value of func_type_comment (GH-19833)
https://github.com/python/cpython/commit/d955241469c18c946924dba79c18a9
Guido van Rossum added the comment:
@Serhiy is this fixed by PR 19720?
--
___
Python tracker
<https://bugs.python.org/issue40398>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Wow, thanks all! FWIW I agree that ideally things should work with a NULL
value...
--
--Guido (mobile)
--
___
Python tracker
<https://bugs.python.org/issue29
Guido van Rossum added the comment:
Easy issue: the Python.gram file still has a comment saying something like
# Simplified grammar
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Guido van Rossum :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
Yeah, the fix will require a variant of types.GenericAlias that substitute's
type variables in lists.
--
___
Python tracker
<https://bugs.python.org/is
Change by Guido van Rossum :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
New changeset 9d74658f0a6e8a9b8d6dcf199dda886f35c6ad68 by Joel Rosdahl in
branch 'master':
bpo-40499: Mention that asyncio.wait() needs a non-empty aws set (GH-19900)
https://github.com/python/cpython/commit/9d74658f0a6e8a9b8d6dcf199dda88
Guido van Rossum added the comment:
New changeset 9d74658f0a6e8a9b8d6dcf199dda886f35c6ad68 by Joel Rosdahl in
branch 'master':
bpo-40499: Mention that asyncio.wait() needs a non-empty aws set (GH-19900)
https://github.com/python/cpython/commit/9d74658f0a6e8a9b8d6dcf199dda88
Guido van Rossum added the comment:
New changeset 9d74658f0a6e8a9b8d6dcf199dda886f35c6ad68 by Joel Rosdahl in
branch 'master':
bpo-40499: Mention that asyncio.wait() needs a non-empty aws set (GH-19900)
https://github.com/python/cpython/commit/9d74658f0a6e8a9b8d6dcf199dda88
Guido van Rossum added the comment:
Hm, I am indeed torn. ISTM a subclass just for Callable is slightly better.
--
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
I don't understand why the traceback module is implicated. It just formats the
information in the SyntaxError object, same as the builtin printing for syntax
errors. The key difference is always in what line/column/text is put in the
SyntaxError obje
Guido van Rossum added the comment:
For example:
raise SyntaxError("message", ("", 1, 3, "text"))
Traceback (most recent call last):
File "", line 1, in
File "", line 1
text
^
SyntaxError: message
>>>
(I can't
Guido van Rossum added the comment:
Aha! So the traceback module does have a difference.
First, if the offset points inside the text, there's no difference:
>>> raise SyntaxError("message", ("", 1, 4, "text"))
Traceback (most recent call las
Guido van Rossum added the comment:
Hm, but there the old parser seems at fault: it points to the last space rather
than beyond it?
--
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
@Terry: Thanks for confirming the bug in the old parser.
Regarding whether column offsets should be 0-based or 1-based: I agree with Tk,
but my hand was forced for SyntaxError: we found that it was already using
1-based offsets and we found correct
Guido van Rossum added the comment:
@Serhiy can you look at this? A possible fix might be:
diff --git a/Lib/typing.py b/Lib/typing.py
index 681ab6d21e..adcef1e82b 100644
--- a/Lib/typing.py
+++ b/Lib/typing.py
@@ -701,7 +701,8 @@ class _GenericAlias(_BaseGenericAlias, _root=True
Guido van Rossum added the comment:
I think I have a shorter repro, not involving unions:
from typing import *
T = TypeVar("T")
S = TypeVar("S")
U = TypeVar("U")
class A(Generic[T]): ...
class B(Generic[T]): ...
class C(Generic[T, S]): ...
print(C[A[U], B[int]][
Guido van Rossum added the comment:
New changeset ac7a92cc0a821699df48bc2e30a02c25d6338f78 by Pablo Galindo in
branch 'master':
bpo-40334: Avoid collisions between parser variables and grammar variables
(GH-19987)
https://github.com/python/cpyt
Guido van Rossum added the comment:
FWIW I propose that we add another Misc/NEWS for the same issue summarizing
what happened between alpha6 and beta1. (A lot!)
--
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
I recommend taking this to a user forum or list. I see no but in typing.py here.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
Let's analyze this here rather than in issue40334 (which is getting top-heavy
:-).
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
It definitely has its reasons -- there are pernicious edge cases. Probably
revealed by the tests.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Guido van Rossum :
--
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue40585>
___
___
Python-bugs-list mai
Change by Guido van Rossum :
--
stage: patch review -> resolved
___
Python tracker
<https://bugs.python.org/issue40585>
___
___
Python-bugs-list mai
Guido van Rossum added the comment:
Okay, let's reopen.
@Matthias, can you clarify your example? What's load()? And what does df?? do?
--
status: closed -> open
___
Python tracker
<https://bugs.pytho
Guido van Rossum added the comment:
Can you all please decide which issue to use?
--
___
Python tracker
<https://bugs.python.org/issue40257>
___
___
Python-bug
Guido van Rossum added the comment:
I would carefully think about the meaning of that line and see if there are
other permutations, e.g. min(Len(blah), offset - 1) ?
It would,be nice to specify what we need here from both parsers and from both
code chunks for error printing
Guido van Rossum added the comment:
New changeset 27c0d9b54abaa4112d5a317b8aa78b39ad60a808 by Shantanu in branch
'master':
bpo-40334: produce specialized errors for invalid del targets (GH-19911)
https://github.com/python/cpython/commit/27c0d9b54abaa4112d5a317b8aa78b
Guido van Rossum added the comment:
I'm making this a release blocker -- please everybody come to an agreement or
ask on python-dev.
--
priority: normal -> release blocker
resolution: fixed -> remind
___
Python tracker
<https://b
Guido van Rossum added the comment:
Hmm... The errors get long, and by focusing only on keywords they can be
misleading. E.g.
>>> from x import a b c
File "", line 1
from x import a b c
^
SyntaxError: Invalid syntax. Expected one of: as
>&g
Guido van Rossum added the comment:
I had hoped that error labels would get us closer to error recovery, but it
appears that is still quite elusive. :-(
--
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
In response to my PEG blogs last year someone showed me an entirely different
algorithm, based on first looking for matching parentheses (and other matching
things), then for operators by priority, and so on. The approach was designed
with C in mind but
Guido van Rossum added the comment:
New changeset f3a5b7ada0c951f317dbd307de4b410e58d3e1b3 by Batuhan Taskaya in
branch 'master':
bpo-39481: remove generic classes from ipaddress/mmap (GH-20045)
https://github.com/python/cpython/commit/f3a5b7ada0c951f317dbd307de4b41
New submission from Guido van Rossum :
The traceback module formats several edge cases of SyntaxError different than
CPython's default formatting.
- There's an off-by-one error if the column offset (printed as a caret) points
past the last character (example: 'a +='). T
Change by Guido van Rossum :
--
keywords: +patch
pull_requests: +19378
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20072
___
Python tracker
<https://bugs.python.org/issu
Guido van Rossum added the comment:
I feel it should. At the very least, a decision should be made on how to move
forward.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Guido van Rossum :
--
nosy: +lys.nikolaou, pablogsal
___
Python tracker
<https://bugs.python.org/issue40619>
___
___
Python-bugs-list mailing list
Unsub
New submission from Guido van Rossum :
Example:
>>> compile("pass\n(1+)\npass", "", "exec")
Traceback (most recent call last):
File "", line 1, in
File "", line 2
(1+)
pass
^
SyntaxError: invalid syntax
>>>
Guido van Rossum added the comment:
My current PR does not strip trailing whitespace. It only strips a single
trailing newline (since this is usually but not always present, and we don't
want to its presence to cause an extra blank line, nor do we want its absence
to cause the text lin
Guido van Rossum added the comment:
(And, to be clear, I don't *want* to strip trailing spaces.)
--
___
Python tracker
<https://bugs.python.org/is
New submission from Guido van Rossum :
This seems due to some new check in pegen:
>>> try:
... pass
... except E as a.b:
... pass
...
Bus error: 10
--
messages: 368860
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
stage: needs patch
sta
Guido van Rossum added the comment:
Oh, looks like https://github.com/python/cpython/pull/20083 fixes it.
--
keywords: +patch
message_count: 1.0 -> 2.0
pull_requests: +19397
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull
Guido van Rossum added the comment:
Sorry!
--
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder: -> PEG Parser: Invalid targets for augassign and except succeed
___
Python tracker
<https://
Guido van Rossum added the comment:
We should run the tests with the old parser in at least one build.
--
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
How costly is PyErr_Occurred()? That worries me most, otherwise I’d accept this
right away.
--
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
I see almost no time difference for 'make time_stdlib': before 3.471, after
3.451. But I see a serious difference for 'make time_compile': before 3.474,
after 4.996. That's over 40% slower (on the extreme case, xxl.py).
I
Change by Guido van Rossum :
--
keywords: +patch
pull_requests: +19462
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/20159
___
Python tracker
<https://bugs.python.org/issu
Change by Guido van Rossum :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
Can you submit a PR and CC me?
--
___
Python tracker
<https://bugs.python.org/issue13601>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Zac: The reproducer here apparently uses a long string of weird accented
characters. I'm not sure how to generalize from that to other things that
Hyothes* could find. But maybe this helps:
https://github.com/python/cpython/pull/20106#issueco
Guido van Rossum added the comment:
Why not just install it?
--
___
Python tracker
<https://bugs.python.org/issue40669>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Unfortunately, I do not understand enough about how Hypothes* works to be
helpful here, other than by offering encouragement. (And please don't try to
educate me. I have too many other things.
Guido van Rossum added the comment:
Soon nobody will remember to look at the memory stats at all. But I will review.
--
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
Okay, deferring the blocker. But I'll still land Lysandros' fix ASAP.
--
priority: release blocker -> deferred blocker
___
Python tracker
<https://bugs.pytho
Guido van Rossum added the comment:
Too bad nobody took any action here after the positive outcome of the
discussion at the summit.
--
components: +Interpreter Core -Library (Lib)
stage: -> needs patch
type: -> behavior
versions: -Pyth
Guido van Rossum added the comment:
New changeset 44ca05afc89c9967f5dbc6c3ad89fc298c460e93 by Irit Katriel in
branch 'master':
bpo-42474: test TracebackException comparison to non-equal instances (GH-23522)
https://github.com/python/cpython/commit/44ca05afc89c9967f5dbc6c3ad89fc
Guido van Rossum added the comment:
For background, see
https://github.com/iritkatriel/cpython/pull/3#issuecomment-734640036 -- it
seems the link to exc_traceback was added with little concern for the original
design of TracebackExceptionGroup.
The question is, can we get rid of it, even
Guido van Rossum added the comment:
Irit, can you,do the manual backports?
--
___
Python tracker
<https://bugs.python.org/issue42474>
___
___
Python-bugs-list m
Guido van Rossum added the comment:
Now that I've seen and reviewed KJ's implementation using _PosArgs, I am
worried about it, as it looks quite complicated. @Shantanu, do we really need
to worry that Callable[P, R] could be ambiguous? If P is a ParamSpec, wouldn't
Call
Guido van Rossum added the comment:
New changeset 586bdd1add2ca7236e3096ab7167862cf17f0939 by Irit Katriel in
branch '3.9':
[3.9] bpo-42474: test TracebackException comparison to non-equal instances
(GH-23557)
https://github.com/python/cpython/commit/586bdd1add2ca7236e3096ab716786
Guido van Rossum added the comment:
New changeset d82e08d185d52086f4d921c08b853c76c80bebbe by Irit Katriel in
branch '3.8':
[3.8] bpo-42474: test TracebackException comparison to non-equal instances
(GH-23558)
https://github.com/python/cpython/commit/d82e08d185d52086f4d921c08b853c
Guido van Rossum added the comment:
Thanks!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
Hm, I wonder if there's a typo here in pythonrun.c:
/* For use in Py_LIMITED_API */
#undef Py_CompileString
PyObject *
PyCompileString(const char *str, const char *filename, int start)
{
return Py_CompileStringFlags(str, filename, start,
Guido van Rossum added the comment:
Wait, is the OP maybe that there’s a difference between typeshed an the stdlib
typing.py?
--
___
Python tracker
<https://bugs.python.org/issue38
Guido van Rossum added the comment:
Oh, this looks like I copied the wrong idiom. Good catch!
--
___
Python tracker
<https://bugs.python.org/issue42576>
___
___
Guido van Rossum added the comment:
Thanks for the quick fix!
--
___
Python tracker
<https://bugs.python.org/issue42576>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Looking for another reviewer.
--
___
Python tracker
<https://bugs.python.org/issue42059>
___
___
Python-bugs-list mailin
2501 - 2600 of 5533 matches
Mail list logo
