Re: [Python-Dev] Small lament...
A bit late, this reached my inbox: https://peternorvig.medium.com/new-python-operators-9f31b56ddcc7 On Sat, Apr 1, 2023 at 11:23 AM Skip Montanaro wrote: > Just wanted to throw this out there... I lament the loss of waking up on > April 1st to see a creative April Fool's Day joke on one or both of these > lists, often from our FLUFL... Maybe such frivolity still happens, just not in > the Python ecosystem? I know you can still import "this" or > "antigravity", but those are now old (both introduced before 2010). When > was the last time a clever easter egg was introduced or an April Fool's Day > joke played? > > ¯\_(ツ)_/¯ > > Skip > > ___ > Python-Dev mailing list -- python-...@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-...@python.org/message/Q62W2Q6R6XMX57WK2CUGEENHMT3C3REF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> -- https://mail.python.org/mailman/listinfo/python-list
[issue1666807] Incorrect file path reported by inspect.getabsfile()
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/issue1666807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47006] PEP 646: Decide on substitution behavior
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 <https://bugs.python.org/issue47006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)
Change by Guido van Rossum : -- pull_requests: +30425 pull_request: https://github.com/python/cpython/pull/32387 ___ Python tracker <https://bugs.python.org/issue45116> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)
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 benchmark results it's hard to know if this has any effect. -- ___ Python tracker <https://bugs.python.org/issue45116> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47234] PEP-484 "numeric tower" approach makes it hard/impossible to specify contracts in documentation
Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <https://bugs.python.org/issue47234> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47237] Inheritance from base class with property in class makes them non-instantiatable
Guido van Rossum added the comment: So is the conclusion that this should be closed as "not a bug"? -- ___ Python tracker <https://bugs.python.org/issue47237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47236] Document types.CodeType.replace() changes about co_exceptiontable
Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue47236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11
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/issue47185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11
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(), the call to foo() is outside the try block and in g() it is inside it is the presence of some NOP opcodes. The actual demarcation of where the try blocks start and end is exclusively determined by the exception table. It just doesn't make sense to try to validate that correct parameters are being passed in when you are modifying co_code and friends. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods
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/issue44090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11
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 required just to *execute* code, no? No, but if they are wrong crashes might happen when they are consulted. At the very least they would confuse users. > If you consider that the caller *must* update co_exceptiontable, replace() > must raise an exception in this case, to prevent creating a code object which > would behave in a strange way (broken exception handling). No. There are a zillion use cases. If you are using .replace() you are taking responsibility for the result. > If someone really wants testing an empty exception table just for fun, it > would still be possible to pass co_exceptiontable=b''. > My concern is more about people upgrading to Python 3.11 and who "suddenly" > don't get their exceptions handled anymore. I would prefer catching such bug > at the replace() call, rather than having to execute the code (and only > notice the bug in production? oops). Where would these people get the value that they're using to replace co_code? Surely if they are generating bytecode it will already be broken. Pretty much all instructions are different in 3.11. -- ___ Python tracker <https://bugs.python.org/issue47185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47152] Reorganize the re module sources
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. -- ___ Python tracker <https://bugs.python.org/issue47152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11
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.org/issue47185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40222] "Zero cost" exception handling
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 really do change co_code, e.g. the debugging tables. -- ___ Python tracker <https://bugs.python.org/issue40222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47152] Reorganize the re module sources
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 tracker <https://bugs.python.org/issue47152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods
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 for this, and we'll probably have to propose a 2-release deprecation period and start issuing a deprecation warning, in case there are nevertheless users (like autosuper clones). -- ___ Python tracker <https://bugs.python.org/issue44090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24837] await process.wait() does not work with a new_event_loop
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.org/issue24837> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46197] ensurepip bootstrap breaks out of isolated environment
Change by Guido van Rossum : -- nosy: +eric.snow, gvanrossum ___ Python tracker <https://bugs.python.org/issue46197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods
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.python.org/issue44090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45100] Improve help() by making typing.overload() information accessible at runtime
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/issue45100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45953] Statically allocate interpreter states as much as possible.
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 finalized and reinitialized. Once we have official immortal objects (see PEP 683) we should switch to that. Since you seem to be challenging the value of 9, my question to you is, why do you care what the refcount of 1 is? -- ___ Python tracker <https://bugs.python.org/issue45953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45100] Improve help() by making typing.overload() information accessible at runtime
Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue45100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45953] Statically allocate interpreter states as much as possible.
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: > > > Should sys.getrefcount try to "fix" the value (...) > > https://peps.python.org/pep-0683/ would make it possible. Right now, I > don't think that it's possible. > > Right now, a refcount of 100210 can be a real value, or it can be an > immortal object. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue45953> > ___ > -- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue45953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods
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(classname, self).method(...). That was perhaps a good idea 20 years ago, but nowadays you can use argument-less super(), so you can write super().method(...), and AFAICT that works for class methods too. I don't think we need two ways to do it. -- ___ Python tracker <https://bugs.python.org/issue44090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46429] Merge all deepfrozen files into one
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 -- ___ Python tracker <https://bugs.python.org/issue46429> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44090] Add class binding to unbound super objects for allowing autosuper with class methods
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/issue44090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46829] Confusing CancelError message if multiple cancellations are scheduled
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://bugs.python.org/issue46829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46829] Confusing CancelError message if multiple cancellations are scheduled
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/0360e9f34659e7d7f3dae021b82f78452db8c714 -- ___ Python tracker <https://bugs.python.org/issue46829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25489] sys.exit() caught in async event loop exception handler
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. This is why I'm not yet comfortable with (d). Looking at call_exception_handler(), whether it calls the default handler or a custom handler, it explicitly checks for SystemExit and KeyboardInterrupt and re-raises those. And only those -- everything ends up logging an error. Which makes me wonder. Maybe that error in Future.__del__ should not call any exception handler at all, but just call logger.error()? Or maybe Future.__del__ should catch exceptions coming out of there and log an error? Maybe a modified version of (d), but only implemented in Future.__del__, not in call_exception_handler()? -- ___ Python tracker <https://bugs.python.org/issue25489> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47006] PEP 646: Decide on substitution behavior
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 on a set of rules for what can be simplified further and what cannot, when we have B = C[...]; A = B[...], (IOW A = C[...][...]), for various shapes of the subscripts to C and B. Note that what's relevant for the second subscript is C[...].__parameters__, so I'll call that "left" below. 1. Some edge case seems to be that if *tuple[...] is involved on either side we will never simplify. Or perhaps a better rule is that *tuple[...] is never simplified away (but fixed items before and after it may be). 2. Another edge case is that if neither side has any starred items we will always simplify (since this is the existing behavior in 3.10). This may raise an error if the number of subscripts on the right does not match the number of parameters on the left. 3. If there's a single *Ts on the left but not on the right, we should be able to simplify, which again may raise an error if there are not enough values on the right, but if there are more than enough, the excess will be consumed by *Ts (in fact that's the only way *Ts is fed). 4. If there's a *Ts on the right but not on the left, we should _not_ simplify, since whatever we have on the left serves as a constraint for *Ts. (E.g. tuple[int, int][*Ts] constrains *Ts to being (int, int).) 5. If there's exactly one *Ts on the left and one on the right, we _might__ be able to simplify if the prefix and suffix of the __parameters__ match the prefix and suffix of the subscript on the right. E.g. C[int, T, *Ts, float][str, *Ts] can be simplified to C[int, str, *Ts, float]. OTOH C[int, T, *Ts, float][*Ts] cannot be simplified -- but we cannot flag it as an error either. Note that __parameters__ in this example is (T, Ts); we have to assume that typevartuples in __parameters__ are always used as *Ts (since the PEP recognizes no valid unstarred uses of Ts). TBH case 5 is the most complex and I may have overlooked something. I'm more sure of cases 1-4. -- ___ Python tracker <https://bugs.python.org/issue47006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7946] Convoy effect with I/O bound threads and New GIL
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/issue7946> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47067] Add vectorcall for generic alias object
Change by Guido van Rossum : -- title: Add vectorcall for generica alias object -> Add vectorcall for generic alias object ___ Python tracker <https://bugs.python.org/issue47067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7946] Convoy effect with I/O bound threads and New GIL
Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue7946> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46965] Enable informing callee it's awaited via vector call flag
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/issue46965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47006] PEP 646: Decide on substitution behavior
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 <https://bugs.python.org/issue47006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25489] sys.exit() caught in exception handler
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 last): File "/Users/guido/cpython/Lib/asyncio/base_events.py", line 1749, in call_exception_handler self._exception_handler(self, context) ^^ File "/Users/guido/test_sys_exit_in_exception_handler.py", line 6, in handler sys.exit(42) SystemExit: 42 This is printed from write_unraisable_exc_file(). Earlier comments in this issue indicate that the exception is being raised from a finalizer (__del__ method). But how? -- ___ Python tracker <https://bugs.python.org/issue25489> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25489] sys.exit() caught in exception handler
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/issue25489> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25489] sys.exit() caught in exception handler
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 <https://bugs.python.org/issue25489> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47067] Add vectorcall for generica alias object
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/issue47067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)
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 <https://bugs.python.org/issue45116> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46965] Enable informing callee it's awaited via vector call flag
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 what the next opcode is, maybe we could use a super-instruction for CALL + GET_AWAITABLE? (Understanding that there are a bunch of different CALL opcodes.) The gather code you link to is all in C. Is rewriting gather in C the only way to benefit from this speedup? (I guess you could just add your gather impl to the existing _asynciomodule.c, in the same or a separate PR.) -- ___ Python tracker <https://bugs.python.org/issue46965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47017] frozen modules are on by default in dev build
Change by Guido van Rossum : -- type: -> behavior versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue47017> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47017] frozen modules are on by default in dev build
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._exists.__code__)' On Windows, the same except use .\python.bat. -- messages: 415203 nosy: eric.snow, gvanrossum priority: normal severity: normal status: open title: frozen modules are on by default in dev build ___ Python tracker <https://bugs.python.org/issue47017> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31415] Add -X option to show import time
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 -- ___ Python tracker <https://bugs.python.org/issue31415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46843] PersistentTaskGroup API
Guido van Rossum added the comment: Okay. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46829] Confusing CancelError message if multiple cancellations are scheduled
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 Jerdonek (who wrote the original code, see bpo-31033) needs to have a say, and from a comment on GH-19951 it looks Yury Selivanov also really liked it. -- ___ Python tracker <https://bugs.python.org/issue46829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46892] Async Call-Stack Reconstruction
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 tracker <https://bugs.python.org/issue46892> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46981] Empty typing.Tuple
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 print "Tuple[]" (which IIRC it did, long ago). -- ___ Python tracker <https://bugs.python.org/issue46981> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
Guido van Rossum added the comment: Good think I forgot to close the issue. ;-) -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 +nosy me if you create one). -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46967] Type union for except
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. -- ___ Python tracker <https://bugs.python.org/issue46967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46896] add support for watching writes to selected dictionaries
Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue46896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14911] generator.throw() documentation inaccurate
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 ___ Python tracker <https://bugs.python.org/issue14911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43923] Can't create generic NamedTuple as of py3.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 3.9 and 3.10, and it needs to be a "fix forward" PR. Would you mind closing the "revert" PR unmerged? -- ___ Python tracker <https://bugs.python.org/issue43923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41370] PEP 585 and ForwardRef
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 -- ___ Python tracker <https://bugs.python.org/issue41370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46949] Print an indication if traceback exceeds sys.tracebacklimit
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 useful.) FWIW the reason I suggested printing "many" is a worry that somehow a bug could cause counting the length of the list to take forever (e.g. if it ends in a cycle). It would seem more robust to limit the count. -- ___ Python tracker <https://bugs.python.org/issue46949> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43923] Can't create generic NamedTuple as of py3.9
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 (named fields and many other features that you may eventually want). Compare concurent.futures.wait()'s return type (a named tuple) to asyncio.tasks.wait()'s return type (a plain tuple). I don't think that naming the fields of the return tuple (awkwardly :-) makes the c.f.wait() API easier to understand than the asyncio.wait() API. Maybe named tuples, like typed dicts, are "in-between" solutions on the spectrum of data types (tuple - named tuple - dataclass; dict - typed dict - dataclass), and we should encourage people to use the neighboring solutions instead. I'd rather spend efforts making dataclasses faster than adding features to named tuples. -- ___ Python tracker <https://bugs.python.org/issue43923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43923] Can't create generic NamedTuple as of py3.9
Guido van Rossum added the comment: Can you be more specific about your use cases? -- ___ Python tracker <https://bugs.python.org/issue43923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43923] Can't create generic NamedTuple as of py3.9
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 <https://bugs.python.org/issue43923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43923] Can't create generic NamedTuple as of py3.9
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 work in
3.9-3.10?
--
___
Python tracker
<https://bugs.python.org/issue43923>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43923] Can't create generic NamedTuple as of py3.9
Guido van Rossum added the comment: Couldn't there be a subtler solution than rolling back GH-19371? -- ___ Python tracker <https://bugs.python.org/issue43923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46877] [doc] unittest.doModuleCleanups() does not exist
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.org/issue46877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46877] [doc] unittest.doModuleCleanups() does not exist
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 -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue46877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1666807] Incorrect file path reported by inspect.getabsfile()
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, closed bug.
I can't seem to reproduce it. I modernized the reproducer script:
###
import inspect,sys
print('Version info:',sys.version_info)
print()
f1 = inspect.getabsfile(inspect)
f2 = inspect.getabsfile(inspect.iscode)
print('File for `inspect` :',f1)
print('File for `inspect.iscode`:',f2)
print('Do these match?',f1==f2)
if f1==f2:
print('OK')
else:
print('BUG - this is a bug in this version of Python')
###EOF
And the output is:
Version info: sys.version_info(major=3, minor=11, micro=0,
releaselevel='alpha', serial=5)
File for `inspect` :
c:\users\gvanrossum\appdata\local\programs\python\python311\lib\inspect.py
File for `inspect.iscode`:
c:\users\gvanrossum\appdata\local\programs\python\python311\lib\inspect.py
Do these match? True
OK
I tried it with the most recent Python built from source and get the same
result:
Version info: sys.version_info(major=3, minor=11, micro=0,
releaselevel='alpha', serial=5)
File for `inspect` : c:\users\gvanrossum\cpython\lib\inspect.py
File for `inspect.iscode`: c:\users\gvanrossum\cpython\lib\inspect.py
Do these match? True
OK
So I wonder if the problem that's currently plagueing pydevd in 3.11 alpha
releases is slightly different?
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue1666807>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46836] [C API] Move PyFrameObject to the internal C API
Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue46836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44807] typing.Protocol silently overrides __init__ method of delivered class
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/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44807] typing.Protocol silently overrides __init__ method of delivered class
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 was by Yurii, who created this issue. I didn't read through all that when I closed the issue, so I'm reopening it. Maybe Yurii can devise a solution? (Although apparently their first attempt, https://github.com/python/cpython/pull/27543 was closed without merging.) Yurii and Lukasz should probably figure this out. -- resolution: third party -> stage: resolved -> test needed status: closed -> open ___ Python tracker <https://bugs.python.org/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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/31623 -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
Change by Guido van Rossum : -- pull_requests: +29748 pull_request: https://github.com/python/cpython/pull/31623 ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46814] Documentation for constructing abstract base classes is misleading
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 functionality through the ABCMeta metaclass: (1) forbid instantiation when at least one @abstractmethod-decorated method exist that isn't overridden, and (2) virtual subclasses. Calling out that a class with metaclass=ABCMeta is only abstract when it has at least one @abstractmethod left, over and over, is not helpful. -- ___ Python tracker <https://bugs.python.org/issue46814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44807] typing.Protocol silently overrides __init__ method of delivered class
Change by Guido van Rossum : -- resolution: -> third party stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44807] typing.Protocol silently overrides __init__ method of delivered class
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/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46430] intern strings in deepfrozen modules
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() behavior) which might be more user friendly :-D Or just log > the error. That's up to pycore_interp_init() in pylifecycle.c now. Kumar called _PyStatus_ERR() there, so I think nothing more needs to be done. -- ___ Python tracker <https://bugs.python.org/issue46430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46430] intern strings in deepfrozen modules
Change by Guido van Rossum : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46777] Fix incorrect use of directives in asyncio documentation
Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue46777> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46661] Duplicate deprecation warnings in docs for asyncio
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 tracker <https://bugs.python.org/issue46661> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46712] Share global string identifiers in deepfreeze
Change by Guido van Rossum : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> resource usage ___ Python tracker <https://bugs.python.org/issue46712> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46712] Share global string identifiers in deepfreeze
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 -- ___ Python tracker <https://bugs.python.org/issue46712> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46844] Implicit binding of PersistentTaskGroup (or virtual event loops)
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.org/issue46844> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46843] PersistentTaskGroup API
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/issue46843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46843] PersistentTaskGroup API
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 or aiotools to provide variations. -- nosy: +tinchester ___ Python tracker <https://bugs.python.org/issue46843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46430] intern strings in deepfrozen modules
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#discussion_r800648477 > intern_strings only check if all the items are strings which will be always > true in case of deep-freeze so I don't think anything needs to be changed > here. I would be interested to know if I am missing something though. The other functions you are calling *do* return errors. You should not ignore those. If any errors are reported the caller can decide what to do (e.g. call Py_FatalError(). -- ___ Python tracker <https://bugs.python.org/issue46430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46844] Context-based TaskGroup for legacy libraries
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. Do you have a specific use case or scenario that has bitten you in the past? If you want to continue to argue for this feature we would need specifics (not a link to reams of code but a clear story telling of a problem you've encountered in real life in the past that your proposal might solve). -- ___ Python tracker <https://bugs.python.org/issue46844> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46843] PersistentTaskGroup API
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, just cancel that toplevel task. -- ___ Python tracker <https://bugs.python.org/issue46843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46754] Improve Python Language Reference based on [Köhl 2020]
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 Hopefully it matches what Kohl derived.) -- ___ Python tracker <https://bugs.python.org/issue46754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46754] Improve Python Language Reference based on [Köhl 2020]
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.__lt__(y) is called but more than that happens. - If no expression is provided, the PLR states that “the last exception that was active in the current scope” should be re-raised. Unfortunately, the PLR stays unspecific on what it means for an exception to be “the last exception that was active in the current scope. [...] Instead, raise re-raises the exception that *is active* in the respective execution context (Perhaps unrelated, but indicative of how out of date the PLR is: in executionmodel.rst there's still a mention of and even an index entry for restricted execution, a feature that was removed in some early Python 2 release.) -- ___ Python tracker <https://bugs.python.org/issue46754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46430] intern strings in deepfrozen modules
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. -- ___ Python tracker <https://bugs.python.org/issue46430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46430] intern strings in deepfrozen modules
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 somewhere. Where is the existence of Py_None accounted for (since it's statically allocated, or at least used to be)? That's likely where we'd have to do something about the deep-frozen objects. -- ___ Python tracker <https://bugs.python.org/issue46430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
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 tracker <https://bugs.python.org/issue45390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46430] intern strings in deepfrozen modules
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 help investigating this? -- ___ Python tracker <https://bugs.python.org/issue46430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 value > 0, it should bubble the CancelledError out; otherwise it can raise EventRaised (if the condition is set). -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46829] Confusing CancelError message if multiple cancellations are scheduled
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 group cases) feels like an odd practice to me. And passing the cancel message through is complex (as we've seen in recent PRs). -- ___ Python tracker <https://bugs.python.org/issue46829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 cancels whom and where the try/except/finally is in relation to the rest. If you have something that catches CancelledError and then ignores it, e.g. while True: try: await except CancelledError: pass then that's an immortal task and it shouldn't be run inside a timeout. If you have something that catches CancelledError once, e.g. try: await finally: await there should be no need to call .uncancel() *unless* the may hang -- in that case you could write try: await finally: async with timeout(5): await I'm not sure that we should recommend using .uncancel() except in very special cases (e.g. when writing a timeout() context manager :-) and those cases should just be tested. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46829] Confusing CancelError message if multiple cancellations are scheduled
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 single flag, not a collection of data. -- ___ Python tracker <https://bugs.python.org/issue46829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45100] Improve help() by making typing.overload() information accessible at runtime
Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <https://bugs.python.org/issue45100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
