Guido van Rossum added the comment:
@Ewout, the current workaround (until pydevd is fixed) is to add
-Xfrozen_modules=off to the Python command line.
--
___
Python tracker
<https://bugs.python.org/issue1666
Guido van Rossum added the comment:
We need to move on this, because the outcome of this discussion is a release
blocker for 3.11b1 -- the next release!
--
priority: normal -> release blocker
type: -> behavior
___
Python tracker
Change by Guido van Rossum :
--
pull_requests: +30425
pull_request: https://github.com/python/cpython/pull/32387
___
Python tracker
<https://bugs.python.org/issue45
Guido van Rossum added the comment:
> -_Py_DECREF (pgo hard reject)
What exactly does "pgo hard reject" mean? I Googled it and found no hits
besides this very issue.
I am trying to redefine the top three from this error log as macros, but since
I still don't have stable benc
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue47234>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
So is the conclusion that this should be closed as "not a bug"?
--
___
Python tracker
<https://bugs.python.o
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue47236>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
If you think the changes to .replace() should be documented just open a new
bpo. You made this issue about your various proposals to change .replace().
--
___
Python tracker
<https://bugs.python.org/issue47
Guido van Rossum added the comment:
This idea just cannot work. Take these two functions:
def f():
foo()
try:
bar()
except:
pass
def g():
try:
foo()
bar()
except:
pass
Using dis to look at their disassembly, the only hint that in f
Guido van Rossum added the comment:
At this point I think it's worth filing a new bug proposing to deprecate 1-arg
super(), pointing out the broken usages that search found.
--
___
Python tracker
<https://bugs.python.org/issue44
Guido van Rossum added the comment:
[Victor]
> Do you consider that .replace() must reject changing co_code if other tables
> are not updated?
I simply don't believe it can always do that correctly, so I believe it should
not do it.
> Debugging tables are not strictly requ
Guido van Rossum added the comment:
1. If we're reorganizing anyway, I see no reason to keep the old names.
2. For maximum backwards compatibility, I'd say keep as much as you can, as
long as keeping it won't interfere with the reorganization
Guido van Rossum added the comment:
How would you compute the exception table from the bytecode? There are no clues
in the bytecode about where the try and except blocks are.
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.
Guido van Rossum added the comment:
> See bpo-47185: code.replace(co_code=new_code) no longer catch exceptions on
> Python 3.11.
Surely the bigger issue is that the contents of new_code itself must be totally
different? Also there are other tables that need to be adjusted if you real
Guido van Rossum added the comment:
I don't mind reorganizing this, but I would insist that we keep code using old
undocumented things (like the sre_* modules) working for several releases,
using the standard deprecation approach.
--
___
Python
Guido van Rossum added the comment:
Yeah, I see no description of what you can do with an unbound super object in
the docs (https://docs.python.org/3/library/functions.html#super), and
experimentation with it does not reveal any useful functionality.
You may want to open a new issue
Guido van Rossum added the comment:
Okay let's close it then. :-)
--
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Guido van Rossum :
--
nosy: +eric.snow, gvanrossum
___
Python tracker
<https://bugs.python.org/issue46197>
___
___
Python-bugs-list mailing list
Unsub
Guido van Rossum added the comment:
Thanks, let's close the issue as "won't fix".
--
resolution: -> wont fix
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs
Guido van Rossum added the comment:
Looks like there may be a new plan where we solve a smaller problem (overloads)
in the context of typing only.
--
___
Python tracker
<https://bugs.python.org/issue45
Guido van Rossum added the comment:
I used 9 in deepfreeze.py to signify "immortal object". It has been
copied by others (small integers are essentially immortal too). I wasn't too
sure that the refcount wouldn't go below zero if the interpreter is repeatedly
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue45100>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Please don’t try to “fix” anything. The value is only useful if you
understand the implementation. It should map straightforwardly to what’s in
memory.
On Mon, Mar 28, 2022 at 05:16 STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
&
Guido van Rossum added the comment:
So IIUC the "autosuper" idea is to assign a special instance of super to
self.__super, so that you can write self.__super.method(...) to invoke a super
method, using the magic of __private variables, instead of having to write
super(class
Guido van Rossum added the comment:
New changeset 785cc6770588de087d09e89a69110af2542be208 by Kumar Aditya in
branch 'main':
bpo-46429: tweak deepfreeze output (#32107)
https://github.com/python/cpython/commit/785cc6770588de087d09e89a69110af2542be208
Guido van Rossum added the comment:
I’m sorry, my brain hurts when trying to understand my own code for super.
Hopefully someone younger can look at this.--
--Guido (mobile)
--
___
Python tracker
<https://bugs.python.org/issue44
Guido van Rossum added the comment:
Fixed by deprecating the message argument to cancel(). It will be removed in
3.13.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bug
Guido van Rossum added the comment:
New changeset 0360e9f34659e7d7f3dae021b82f78452db8c714 by Andrew Svetlov in
branch 'main':
bpo-46829: Deprecate passing a message into Future.cancel() and Task.cancel()
(GH-31840)
https://github.com/python/cpython/commit
Guido van Rossum added the comment:
Andrew, thanks for explaining this.
The key thing I was missing was that the root cause of the problem is that
Future.__del__ is trying to log an error about the un-awaited task by calling
the exception handler directly. That actually feels a little dodgy
Guido van Rossum added the comment:
I'd like to look at this as a case of simplifying something to its simplest
canonical form, but no simpler. This is what the existing fixed-typevar
expansion does: e.g. tuple[str, T, T][int] becomes tuple[str, int, int].
I propose that we try to agree
Guido van Rossum added the comment:
Start here:
https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit
AFAICT the SC hasn't made up their minds about this.
--
___
Python tracker
<https://bugs.python.org/issue7
Change by Guido van Rossum :
--
title: Add vectorcall for generica alias object -> Add vectorcall for generic
alias object
___
Python tracker
<https://bugs.python.org/issu
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue7946>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
I will wait until there is a draft PR to review, or until you ping me.--
--Guido (mobile)
--
___
Python tracker
<https://bugs.python.org/issue46
Guido van Rossum added the comment:
I think I'm with Serhiy, I don't understand the hesitance to transform
tuple[*Ts][int, str] into tuple[int, str].
What would be an example of a substitution that's too complex to do?
--
___
Python tracker
Guido van Rossum added the comment:
With python built from main I get:
/Users/guido/test_sys_exit_in_exception_handler.py:12: DeprecationWarning:
There is no current event loop
loop = asyncio.get_event_loop()
Got error, exiting
Exception ignored in: >
Traceback (most recent call l
Guido van Rossum added the comment:
Nevertheless, the example code still hangs after calling sys.exit(). I can't
quite tell where it is hanging.
--
___
Python tracker
<https://bugs.python.org/issue25
Guido van Rossum added the comment:
Andrew, would you be interested in investigating this? I can't even follow the
flow through asyncio that causes the observed behavior (though I seem to have
confirmed it).
--
nosy: +asvetlov
___
Python tracker
Guido van Rossum added the comment:
@Dennis, if/when the PR looks good to you, you can merge it.
--
___
Python tracker
<https://bugs.python.org/issue47
Guido van Rossum added the comment:
I can't yet confirm a regression in 3.11 (the main branch, currently) compared
to 3.10. See my adventures in
https://github.com/faster-cpython/ideas/discussions/315.
--
___
Python tracker
<ht
Guido van Rossum added the comment:
The link
https://github.com/facebookincubator/cinder/blob/cinder/3.8/Python/ceval.c#L6617
points to something that I wouldn't associate with the subject. @Dino, could
you provide a new link (preferably a permalink)?
FWIW rather than dynamically checking
Change by Guido van Rossum :
--
type: -> behavior
versions: +Python 3.11
___
Python tracker
<https://bugs.python.org/issue47017>
___
___
Python-bugs-list mai
New submission from Guido van Rossum :
At least on Windows and macOS, this repro shows that frozen modules are on in a
dev build:
Mac:
~/cpython$ ./python.exe -c 'import os; print(os._exists.__code__)'
", line 41>
~/cpython$ ./python.exe -Xfrozen_modules=off -c 'import os;
print(os
Guido van Rossum added the comment:
New changeset 29624e769c5c3c1e59c6acc8b69383ead53e8a9f by Victor Stinner in
branch 'main':
bpo-31415: importtime was made by Inada Naoki (GH-31875)
https://github.com/python/cpython/commit/29624e769c5c3c1e59c6acc8b69383ead53e8a9f
Guido van Rossum added the comment:
Okay.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46843>
___
___
Guido van Rossum added the comment:
Before we land GH-31840 we should have a somewhat more public discussion (e.g.
on python-dev or maybe in Async-SIG, https://discuss.python.org/c/async-sig/20;
or at least here) about deprecating the cancel message. I'm all for it but
certainly Chris
Guido van Rossum added the comment:
I've recently dabbled a bit in some new primitives for asyncio, and based on
that experience I think this would be very useful.
IIRC Trio does this (presumably at considerable cost) in userland.
--
___
Python
Guido van Rossum added the comment:
Alas, I have no idea. I don't even recall what copy_with() is for (it was
apparently introduced in 3.7). Possibly vopy_with() is wrong here? I imaging
some of this has to do with the special casing needed so that repr() of an
empty Tuple type doesn't
Guido van Rossum added the comment:
Good think I forgot to close the issue. ;-)
--
___
Python tracker
<https://bugs.python.org/issue46771>
___
___
Python-bug
Guido van Rossum added the comment:
I'm closing this, the asyncio.timeout() context manager has been merged. Thanks
Andrew!
@agronholm you said you were interested in tweaking the cancellation behavior
some more. If you're still interested, let's discuss that in a separate bpo
(please
Guido van Rossum added the comment:
New changeset f537b2a4fb86445ee3bd6ca7f10bc9d3a9f37da5 by Andrew Svetlov in
branch 'main':
bpo-46771: Implement asyncio context managers for handling timeouts (GH-31394)
https://github.com/python/cpython/commit/f537b2a4fb86445ee3bd6ca7f10bc9d3a9f37da5
Guido van Rossum added the comment:
I don't think that `except A|B` looks better than `except (A, B)`, so I am
against this proposal. Exception matching is its own special thing (e.g. it
doesn't honor virtual subclasses) and we shouldn't hyper-generalize
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue46896>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
This still hasn't been fixed. I suspect that a new patch should be produced and
uploaded as a PR. It looks pretty simple.
--
keywords: +easy
nosy: +gvanrossum
versions: +Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
Guido van Rossum added the comment:
Playing tricks where compile-time and run-time see slightly different types is
probably more productive than trying to revert a PR that was in Python 3.9 and
3.10. :-)
I'm not opposed to supporting generic NamedTuple, but I expect the fix will
never hit
Guido van Rossum added the comment:
New changeset b465b606049f6f7dd0711cb031fdaa251818741a by Niklas Rosenstein in
branch 'main':
bpo-41370: Evaluate strings as forward refs in PEP 585 generics (GH-30900)
https://github.com/python/cpython/commit/b465b606049f6f7dd0711cb031fdaa251818741a
Guido van Rossum added the comment:
There is general confusion as to which part of the traceback is truncated. If I
have main() -> f() -> g() -> error(), and the limit is 2, does it print main()
-> f(), or does it print g() -> error()? (I'm not even sure which would be more
Guido van Rossum added the comment:
Okay, that's a sensible use case.
I do doubt your intuition of preferring named tuples over dataclasses a bit.
This seems to encourage premature optimization. I'd say for simple cases use
plain tuples (most performant), for complex cases use dataclasses
Guido van Rossum added the comment:
Can you be more specific about your use cases?
--
___
Python tracker
<https://bugs.python.org/issue43923>
___
___
Python-bug
Guido van Rossum added the comment:
So if it doesn't work in mypy why bother making it work at runtime? Is there an
actual use case that broke? (There might be, but probably esoteric if nobody's
run into it until now.)
--
___
Python tracker
Guido van Rossum added the comment:
Mypy seems to allow this:
from typing import NamedTuple, TypeVar, Generic, List, Tuple
T = TypeVar("T")
class New(NamedTuple, Generic[T]):
x: List[T]
y: Tuple[T, T]
It's true that pyright doesn't, but maybe that's because it doesn't wo
Guido van Rossum added the comment:
Couldn't there be a subtler solution than rolling back GH-19371?
--
___
Python tracker
<https://bugs.python.org/issue43
Change by Guido van Rossum :
--
components: +Library (Lib)
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: enhancement -> behavior
___
Python tracker
<https://bugs.python
Guido van Rossum added the comment:
New changeset cc400585fab02994255f21ae8183d5f147236815 by Kumar Aditya in
branch 'main':
bpo-46877: export unittest.doModuleCleanups in unittest package (#31613)
https://github.com/python/cpython/commit/cc400585fab02994255f21ae8183d5f147236815
Guido van Rossum added the comment:
So this bug is referenced when pydevd encounters some problem with 3.11a5+:
https://github.com/fabioz/PyDev.Debugger/issues/213
Since the link to this bug is apparently baked into the error messages printed
by pydevd, I am adding this comment to this old
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue46836>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Would it make sense to enforce the no-instantiation rule in __new__ instead of
__init__?
--
___
Python tracker
<https://bugs.python.org/issue44
Guido van Rossum added the comment:
Oops.
So this is an intentional feature -- Protocol replaces __init__ so that you
can't (accidentally) instantiate a protocol. And the code to do this has
changed a couple of times recently to deal with some edge cases. At least one
of the PRs
Guido van Rossum added the comment:
New changeset 7d611b4cabaf7925f5f94daddf711d54aeae2cf9 by Guido van Rossum in
branch 'main':
bpo-46771: Remove two controversial lines from Task.cancel() (GH-31623)
https://github.com/python/cpython/commit/7d611b4cabaf7925f5f94daddf711d54aeae2cf9
Guido van Rossum added the comment:
Everyone,
I've sent a PR (which I expect will make it into alpha 6) that restores the old
cancel() semantics. This should make Tin happy, but I think we'll still have to
have a longer discussion about the downsides.
https://github.com/python/cpython/pull
Change by Guido van Rossum :
--
pull_requests: +29748
pull_request: https://github.com/python/cpython/pull/31623
___
Python tracker
<https://bugs.python.org/issue46
Guido van Rossum added the comment:
Raymond, I agree that this is going too far. I believe the OP has taken the
position that "abstract" has only one meaning and it is defined by
inspect.isabstract(). I disagree with this.
An ABC is an ABC is an ABC, and it provides certain fun
Change by Guido van Rossum :
--
resolution: -> third party
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
If the problem is in mypy, it should be filed in the mypy tracker, not here.
--
___
Python tracker
<https://bugs.python.org/issue44
Guido van Rossum added the comment:
> PEP 587 introduced PyStatus to Python startup code which let the
> Py_Initialize() caller to decide how to handle errors ;-) For example, you
> can open a graphical popup rather than killing the process with SIGABRT
> (Py_FatalError() beh
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 :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue46777>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Thanks! Marking as duplicate.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Fix incorrect use of directives in asyncio documentation
___
Python tra
Change by Guido van Rossum :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> resource usage
___
Python tracker
<https://bugs.python
Guido van Rossum added the comment:
New changeset eb002dbe0da9622245a355db5f0cd5aa2fc70b40 by Kumar Aditya in
branch 'main':
bpo-46712: Share global string identifiers in deepfreeze (GH-31261)
https://github.com/python/cpython/commit/eb002dbe0da9622245a355db5f0cd5aa2fc70b40
Guido van Rossum added the comment:
Let's concentrate the discussion in the other issue.
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
(FWIW I would close this issue but I'll wait to see if @asvetlov has something
to add.)
--
___
Python tracker
<https://bugs.python.org/issue46
Guido van Rossum added the comment:
The implementation of asyncio.TaskGroup isn't all that complicated (and the new
"cancel count" API helps). I recommend that you build one that satisfies your
requirements yourself, or convince the authors of some other package like
Quattro o
Guido van Rossum added the comment:
> How it should be handled? Currently PyUnicode_InternInPlace ignores any
> errors and does not return it. It would be backwards-incompatible to change
> that, moreover as I explained in
> https://github.com/python/cpython/pull/30683#discussio
Guido van Rossum added the comment:
-1. Libraries that manage their own tasks should continue to do so, until they
are ready to adopt TaskGroup. Trying to "own" (and wait for) tasks created by a
library sounds like a recipe for disaster if the library wasn't expecting that.
D
Guido van Rossum added the comment:
Could you just have a global task group that owns these long-running tasks? It
could be embedded in a "toplevel" task that is created using
asyncio.create_task() (which won't be deprecated). To shut down all
long-running tasks at the end, j
Guido van Rossum added the comment:
New changeset 7fce1063b6e5a366f8504e039a8ccdd6944625cd by Tin Tvrtković in
branch 'main':
bpo-46771: Implement task cancel requests counter (GH-31513)
https://github.com/python/cpython/commit/7fce1063b6e5a366f8504e039a8ccdd6944625cd
Guido van Rossum added the comment:
Another:
- The description of this name binding and resolution process
in the PLR [20, §4.2.] is unfortunately not particularly clear.
(I found this to be the case too, and wrote up what I found:
https://gvanrossum.github.io/formal/scopesblog.html
Guido van Rossum added the comment:
A few examples of issues brought up by Kohl:
- While the PLR explicitly states that “x < y calls x.__lt__(y)”
[20, §3.3.1.] this is actually false.
There are cases where x < y does not call x.__lt__(y)
and there are other cases where x.__
Guido van Rossum added the comment:
That's pretty mysterious. The deep-freeze code isn't on the stack for either of
those, but allocation of new unicode string objects is. I'm guessing these are
somehow leaked by the interning, but I don't follow yet how
Guido van Rossum added the comment:
I will now merge GH-31513 (cancel counts). Once that's in you can merge main
into your timeout PR (GH-31394) and then that can land soon (I'd like to review
it once more).
--
___
Python tracker
<ht
Guido van Rossum added the comment:
> Not leaking memory at exit matters when Python is embedded
> in an application.
Sure, but "leaks" caused by deep-freezing cannot be solved by freeing up the
deep-frozen memory -- the solution must be to update the accounting s
Guido van Rossum added the comment:
We should really stop appending to a closed issue.
Anyway, raising ExceptionGroup is backwards incompatible, since "except
CancelledError" wouldn't cancel the group.
--
___
Python track
Guido van Rossum added the comment:
Okay, let's change the error handling. @Kumar, can you handle that?
@Victor, the refleak is unrelated to the error handling right? Presumably the
leak is imaginary -- the deep-frozen interned strings should be accounted for
somehow. @Kumar do you need
Guido van Rossum added the comment:
To make this cleanly interact with timeout, TaskGroup etc., the CancelOnEvent
class should have a "did-I-cancel" flag which is set in the _cancel_on_event()
callback. Then if that flag is set it should call .uncancel(), and if that
returns a
Guido van Rossum added the comment:
But that example is made-up. Is there a real-world situation where you need to
know the call site, and it wouldn't be obvious from other log messages?
Directly cancelling a task without also somehow catching the cancellation (like
in the timeout or task
Guido van Rossum added the comment:
> If some code is used together with timeout() and this code calls
> `.cancel()` but forgot about `.uncancel()` in try/except/finally --
> timeout() never raises TimeoutError.
Could you show an example? I'm not sure from this description who can
Guido van Rossum added the comment:
I would like to go on record (again) as preferring to get rid of the
cancel-message parameter altogether. Let's deprecate it. When we initially
designed things without a cancel message we did it on purpose -- "cancellation"
is a s
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue45100>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Sounds good to me. (I don’t care what happens at runtime but I want to
support the folks who do.)--
--Guido (mobile)
--
___
Python tracker
<https://bugs.python.org/issue45
1 - 100 of 5393 matches
Mail list logo
