Guido van Rossum added the comment:
Closing for lack of activity.
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue37604>
___
___
Python-bug
Guido van Rossum added the comment:
Closing for lack of activity.
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue37350>
___
___
Python-bug
Guido van Rossum added the comment:
Closing for lack of activity.
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue36586>
___
___
Python-bug
Change by Guido van Rossum :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue36586>
___
___
Python-bugs-list
Change by Guido van Rossum :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue37350>
___
___
Python-bugs-list
Change by Guido van Rossum :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue37604>
___
___
Python-bugs-list
Guido van Rossum added the comment:
Okay, so according to eryksun the fix requires C code. @graingert, are you
interested in developing such a fix? Or @eryksun do you have an idea on how to
fix it?
--
___
Python tracker
<https://bugs.python.
Guido van Rossum added the comment:
Thanks, I think this is the fix:
diff --git a/Modules/main.c b/Modules/main.c
index 4a76f4461b..3d1bbee3a0 100644
--- a/Modules/main.c
+++ b/Modules/main.c
@@ -288,6 +288,10 @@ pymain_run_module(const wchar_t *modname, int set_argv0)
return
Change by Guido van Rossum :
--
stage: patch review -> needs patch
versions: +Python 3.10
___
Python tracker
<https://bugs.python.org/issue41602>
___
___
Py
Guido van Rossum added the comment:
Why did you remove 3.10?
--
___
Python tracker
<https://bugs.python.org/issue41602>
___
___
Python-bugs-list mailin
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue35293>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Let’s do this.
--
___
Python tracker
<https://bugs.python.org/issue41810>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
> Would not be better to make MyPy supporting type(Ellipsis)? It would work
> also on Python versions older than 3.10.
That would be quite complicated. There is no place in annotations where a
function call is currently supported, so I'd prefe
Guido van Rossum added the comment:
I’m okay with adding those (even though NoneType might not work in mypy, given
the special-casing for None, per PEP 484).
--
___
Python tracker
<https://bugs.python.org/issue41
Guido van Rossum added the comment:
> In any case, I'm ok with adding `NoneType` and `NotImplementedType` to the PR.
Please do.
--
___
Python tracker
<https://bugs.python.org
Guido van Rossum added the comment:
Bas can you do some research to answer Eric's question? In theory it should be
possible to use git bisect to find it. I see it in 2.7 but not in 3.4. That's a
fairly large interval, alas.
--
___
Pyth
Guido van Rossum added the comment:
Thanks! Most of the deleted types *are* builtins (e.g. object, int). I assume
the reasoning was just that if you wanted the type you could just write
type(Ellipsis), type(None) etc.
But that's too dynamic for static checkers, so we want *some* stable
Change by Guido van Rossum :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
New changeset a68a2ad19c891faa891904b3da537911cc77df21 by Thomas Grainger in
branch 'master':
bpo-41602: raise SIGINT exit code on KeyboardInterrupt from pymain_run_module
(#21956)
https://github.com/python/cpyt
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 0d0e9fe2ffc1683758a1985ef6dedeef5ecafdbc by Bas van Beek in
branch 'master':
bpo-41810: Reintroduce `types.EllipsisType`, `.NoneType` &
`.NotImplementedType` (GH-22336)
https://github.com/python/
Guido van Rossum added the comment:
I propose not to fix this, since it is pointless (a lambda is always truthy).
We can call it out in What's New in 3.9 -- as a very small footnote. :-)
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
Okay, let's close this.
--
resolution: -> wont fix
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
Guido van Rossum added the comment:
This cannot be helped (unless we were to add an ugly sys._getframe() call to
get_type_hints(), which I don't want to do). The solution is to pass
`localns=locals()`, e.g.
get_type_hints(foo, None, locals())
or
get_type_hints(foo, localns=l
Guido van Rossum added the comment:
I've only seen it in test cases too -- that's one of the very few
situations where it makes sense to define a class inside a function.
(Creating a class is an expensive operation, so any function that expects
to be called more than once is better
Guido van Rossum added the comment:
We moved the check from the parser to the bytecode compiler. I don't think this
should be a problem. Kudos for noticing though! :-)
```
>>> compile("__debug__ = 1", "", "exec")
Traceback (most recent call las
Guido van Rossum added the comment:
Hm, I'm not sure. ast.literal_eval() does accept trailing whitespace, and
embedded whitespace.
```
>>> ast.literal_eval("- ( 1\n)\n")
-1
>>>
```
So I think it should start accepting leading whitespace too (but on
Guido van Rossum added the comment:
I agree that it's better to just close this issue, the patch is 7 years old.
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
Hm, I don't think PR 22469 is relevant to this issue?
--
___
Python tracker
<https://bugs.python.org/issue17490>
___
___
Guido van Rossum added the comment:
I'm going to ignore this issue until you two have reached agreement. I
recommend using some example code.
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
I still like to have a helper that recalculates the abstractness status of a
class after adding some new methods (or deleting some).
I would prefer the isinstance(cls, ABCMeta) check to be inside that helper, so
that you could call it unconditionally
Guido van Rossum added the comment:
[Terry]
> But why should not parsing remove indents for 'eval' mode?
I dunno, but it's been doing this since 1992, so I think it would be fragile to
change. The best thing therefore is to make ast.literal_eval(
Guido van Rossum added the comment:
Why would that require more code? That’s already how it worked. Maybe you
misunderstand what I tried to say?
--
___
Python tracker
<https://bugs.python.org/issue41
Guido van Rossum added the comment:
Ah, okay. I wasn't familiar with @total_ordering so I assumed differently.
Sorry for the continued misunderstanding.
Perhaps we should just leave it alone completely then, since ISTM that any
change to its implementation may cause subtle bu
Guido van Rossum added the comment:
Sure go right ahead.
--
___
Python tracker
<https://bugs.python.org/issue41923>
___
___
Python-bugs-list mailing list
Unsub
Guido van Rossum added the comment:
I don't think I remember what's so special about abstract_get_bases() to
disable the recursion check. Maybe this macro is always just a
micro-optimization? Then again it's hard to be sure, the behavior may depend on
the platform.
Pulling
Guido van Rossum added the comment:
Hm, you're effectively proposing to compute (or update) __abstractmethods__
lazily. There are a number of subtleties with that, e.g. __abstractmethods__ is
currently a frozenset, and a base class's __abstractmethods__ is used when
com
Guido van Rossum added the comment:
New changeset e799aa8b92c195735f379940acd9925961ad04ec by Batuhan Taskaya in
branch 'master':
bpo-41887: omit leading spaces/tabs on ast.literal_eval (#22469)
https://github.com/python/cpython/commit/e799aa8b92c195735f379940acd992
Guido van Rossum added the comment:
Closing. Let’s not backport.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
Yes, we could override ABCMeta.__setattr__ to do that. Though it seems this
class is considered performance sensitive (else why have Modules/_abc.c) we
would probably have to write it in C.--
--Guido (mobile
Guido van Rossum added the comment:
Possibly at some point in the future we can switch to using typing.Protocol,
which requires neither registration nor explicit subclassing (it's like
Hashable). This makes it easy for user code to define custom protocols as
needed. So if you need some
Guido van Rossum added the comment:
New changeset 8e1dd55e63d18d40e78d941fc9233d2c77bcd3de by Fidget-Spinner in
branch 'master':
bpo-41428: Documentation for PEP 604 (gh-22517)
https://github.com/python/cpython/commit/8e1dd55e63d18d40e78d941fc9233d2c77bcd3de
--
nosy: +
Change by Guido van Rossum :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Guido van Rossum :
--
assignee: gvanrossum -> rhettinger
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue26680>
___
___
Python-
Guido van Rossum added the comment:
Thanks all!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
New changeset bef7d299eb911086ea5a7ccf7a9da337e38a8491 by Ben Avrahami in
branch 'master':
bpo-41905: Add abc.update_abstractmethods() (GH-22485)
https://github.com/python/cpython/commit/bef7d299eb911086ea5a7ccf7a9da3
Guido van Rossum added the comment:
New changeset 044a1048ca93d466965afc027b91a5a9eb9ce23c by Batuhan Taskaya in
branch 'master':
bpo-38605: Make 'from __future__ import annotations' the default (GH-20434)
https://github.com/python/cpython/commit/044a1048ca93d466965a
Guido van Rossum added the comment:
I'm marking this fixed, but there are some subtle edge cases. That's what alpha
releases are for.
@BTaskaya, adding those arguments to various inspect functions sounds like a
nice thing to do. You could either open a new issue or just refe
Guido van Rossum added the comment:
What's the issue exactly with multi-line annotations? Is it that they can't be
parsed by eval()? Could that be fixed by replacing comments and newlines with
spaces? (Either in the parser or in get_type_hints() -- actually
ForwardRef._evaluat
Guido van Rossum added the comment:
Hm, this buffer thing is not what I had expected. I think it's a show-stopper
-- if we don't reproduce spaces exactly.
Maybe we should just buffer the entire input always?
A way to handle multi-line annotations would be to surround them with
p
Guido van Rossum added the comment:
I know the final result is the same (i.e. the AST is identical and the
string differs only in the use of whitespace). I just wonder why bother
changing this unless we reproduce the spaces in the string exactly
Guido van Rossum added the comment:
Okay, but doesn't *any* way of handling multi-line annotations spoil the
wins? We cannot declare those illegal. (Though we can switch to a different
way of representing those.)
--
___
Python tracker
&
Guido van Rossum added the comment:
> the string generated for multi line annotations [...] won't have spaces
> between characters.
Okay, though aren't there cases where spaces are necessary? E.g. between names
or between a name or keyword and a string or number.
Assumin
Guido van Rossum added the comment:
New changeset 4f3c25043d651a13c41cffcee703f7d5cb677cc7 by Mikhail Golubev in
branch 'master':
bpo-41923: PEP 613: Add TypeAlias to typing module (#22532)
https://github.com/python/cpython/commit/4f3c25043d651a13c41cffcee703f7
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:
Too bad. :-(
--
___
Python tracker
<https://bugs.python.org/issue41967>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Yup. Thanks for catching this!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
This behavior (only relevant with `from __future__ import annotations`) has
been around since @singledispatchmethod was introduced in 3.8, so I agree we
should treat it as a feature request.
In the meantime, maybe a workaround is to move the register call
Guido van Rossum added the comment:
Yes, let’s document __args__ and __origin__.
--
___
Python tracker
<https://bugs.python.org/issue40814>
___
___
Python-bug
Guido van Rossum added the comment:
New changeset 0ae216b11644b23511c6287a52e7d28aeb9f by Batuhan Taskaya in
branch 'master':
bpo-38605: bump the magic number for 'annotations' future (#22630)
https://github.com/python/cpython/commit/0ae216b11644b235
Guido van Rossum added the comment:
You can easily define that yourself if you need it, though honestly the utility
seems marginal.
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bug
Guido van Rossum added the comment:
Have you observed actual users getting confused by this? (E.g. StackOverflow or
mailing list posts.) I would assume that if you try to *do* anything with the
resulting object it's going to cause a traceback, and from there it's pretty
straight
Guido van Rossum added the comment:
New changeset 1c217652b690c184b43d8e2b6529a60a14e64328 by Saiyang Gou in branch
'3.9':
[3.9] bpo-39481: Fix duplicate SimpleQueue type in test_genericalias.py
(GH-22619) (#22624)
https://github.com/python/cpyt
Guido van Rossum added the comment:
That sentence has been a lie for a long time (from the start?).
Any type can define __getitem__ and get this behavior, though in this case it
is done through __class_getitem__ (PEP NNN).
--
___
Python tracker
Guido van Rossum added the comment:
Can you submit a PR to fix this? It looks like you already have a good
understanding of the root cause of the problem, so it should be easy to fix.
(Be sure to add a unit test.)
It can be backported to earlier Python versions that have typing.TypedDict
Guido van Rossum added the comment:
Whoops, sorry, didn't see that you already have a PR. I'll review it next week
during the core sprint.
--
___
Python tracker
<https://bugs.python.o
Guido van Rossum added the comment:
This may be irrelevant at this point, but trying to understand the original
reproducer, I wanted to add my 1c worth.
It seems Dennis' reproducer.py is roughly this:
(I'm renaming BIG//3 to K to simplify the math.)
aBaBBB
Guido van Rossum added the comment:
Right, so IIUC the *quadratic* portion of Dennis’ original reproducer, aBaBBB
with pattern BBB, except with more cowbell :-) acts the same.
--
___
Python tracker
<https://bugs.python.org/issue41
Guido van Rossum added the comment:
I'd say close it, the deprecation can be a separate issue (usually is) and I
don't think we need to backport such a minor docs issue to 3.8. The PR is old
enough that it made 3.9+3.10 I think (did you check?).
--
nosy: +
Guido van Rossum added the comment:
Whoops, never mind me. Irit can you friend me on Discourse?
--
___
Python tracker
<https://bugs.python.org/issue37
Guido van Rossum added the comment:
New changeset 7cdf30fff39ea97f403b5472096349998d190e30 by kj in branch 'master':
bpo-42010: [docs] Clarify subscription of types (GH-22822)
https://github.com/python/cpython/commit/7cdf30fff39ea97f403b5472096349
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:
I'm not against this, though I'm not sure it really buys us much (Any still has
to be imported from typing). Maybe you can submit a PR? Running the tests might
be informative.
--
___
Python track
Guido van Rossum added the comment:
All this needs is a PR filed against latest master that updates
Doc/whatsnew/3.9.rst and labeled with needs-backport-3.9.
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue41
Guido van Rossum added the comment:
Honestly I don't see it in the 3.9 branch either. It seems the whole section
mentioned in the closed PR doesn't exist anywhere. Maybe it was reverted for
some reason. Let's close this issue.
--
resolution: -> out of date
s
Guido van Rossum added the comment:
Hm, I guess my repo is out of date. Sorry. So it is in master? Let's fix it
there then.
--
resolution: out of date ->
stage: resolved -> needs patch
status: closed -> open
versions: +Python 3.10
Guido van Rossum added the comment:
There really shouldn't be any differences between that doc in the 3.9 and
master branch (with rare exceptions). Can you post a diff here between the two
so we can sort it out?
Also can you find the commit where it was added to the 3.9 b
Guido van Rossum added the comment:
Dong-hee, I recommend that you turn this into a 3rd party package on PyPI
yourself. That way your effort and code will live on!
--
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
Oh, I see. Łukasz (@ambv) prepared the 3.9.0 release and didn't merge his
changes into master yet.
I'll contact him.
--
nosy: +lukasz.langa
___
Python tracker
<https://bugs.python.o
Guido van Rossum added the comment:
Yeah, I'll see if I can reopen your PR and we can apply it to the 3.9 branch,
we'll then forward port it (if and when that's done).
--
___
Python tracker
<https://bugs.pyt
Guido van Rossum added the comment:
New changeset dc33f798139016961fba33b37c792c690399b2b6 by Weiliang Li in branch
'3.9':
bpo-41950: Typo in Python 3.9 what's new page (GH-22573)
https://github.com/python/cpython/commit/dc33f798139016961fba33b37
Guido van Rossum added the comment:
Thanks, merged, so closing.
I'll open a separate issue regarding the forward-porting of the 3.9 whatsnew.
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python t
New submission from Guido van Rossum :
We discovered in issue41950 that the whatsnew/3.9.rst files differ quite a bit
between 3.9 and master. IIUC this is (mostly) because Lukasz made a big pass
updating it on occasion of the 3.9.0 release, and he did that in the 3.9 branch:
https
Change by Guido van Rossum :
--
keywords: +patch
pull_requests: +21853
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22933
___
Python tracker
<https://bugs.python.org/issu
Guido van Rossum added the comment:
New changeset 805ef73ad0ac4a77f3764dd17dfc959d562ce627 by Terry Jan Reedy in
branch 'master':
bpo-42139: Update What's New 3.9 for master (#22936)
https://github.com/python/cpython/commit/805ef73ad0ac4a77f3764dd17
Guido van Rossum added the comment:
Terry did the same thing in https://bugs.python.org/issue42139.
--
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
You also need to forward-port https://bugs.python.org/issue41950.
--
___
Python tracker
<https://bugs.python.org/issue42
Guido van Rossum added the comment:
Never mind, I read the diff backwards. You're all good and you can close this.
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
Are you sure? Running Ezio's titletest.py, I get this output (note that the UCD
major version is in the double digits so the test for that misfires :-).
titletest.py: Please set your PYTHONIOENCODING envariable to utf8
WARNING: Your old UCD is out of
Guido van Rossum added the comment:
> The documentation for `typing.overload` says in a non-stub file the last
> definition shouldn't be typed.
Incorrect. It doesn't say it shouldn't be *typed*, it says it shouldn't be
*decorated with @overload*, which is a differ
Change by Guido van Rossum :
--
resolution: -> not a bug
___
Python tracker
<https://bugs.python.org/issue42169>
___
___
Python-bugs-list mailing list
Un
Guido van Rossum added the comment:
New changeset 4173320920706b49a004b8d7108e8984e3fc by kj in branch 'master':
bpo-41805: Documentation for PEP 585 (GH-22615)
https://github.com/python/cpython/commit/4173320920706b49a004b8d7108e8984e3fc
--
nosy: +
Guido van Rossum added the comment:
Thanks Ken Ji! Are you planning more doc patches?
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
If you feel up to it, you might see if you could open a new, separate
(draft) PR that updates all those docs. (But you could also wait and see if
someone volunteers. There are some good doc writers active ATM
Guido van Rossum added the comment:
Cool. Please add me to the nosy list of any issues you open.
Also, if you're interesting helping out with the match statement, once the SC
approves it, we'll need to add docs for that. See issue42128 for a poss
Guido van Rossum added the comment:
Since there are so few projects, maybe you can just contact them?
--
___
Python tracker
<https://bugs.python.org/issue42
Guido van Rossum added the comment:
I thought for all?
--
___
Python tracker
<https://bugs.python.org/issue42187>
___
___
Python-bugs-list mailing list
Unsub
Guido van Rossum added the comment:
I'm not an expert on singledispatch. It seems the get_type_hints() call is
present in 3.8 as well.
Could you investigate and find a root cause? Then maybe we can fix it. (If you
come up with a PR that would be very much appreciated.)
--
ver
Guido van Rossum added the comment:
Good find! I see that typing.Callable has adopted this structure precisely to
enable caching.
We should see if we can fix _collections_abc.Callable. It's still early in the
life of 3.9 so I think this is reasonable.
We'll need a subclass of Ge
Guido van Rossum added the comment:
Looks like a bug. Maybe someone can bisect and find when this started happening?
--
___
Python tracker
<https://bugs.python.org/issue42
3001 - 3100 of 5533 matches
Mail list logo
