[issue44659] Remove Ivan from list of typing experts

Guido van Rossum added the comment: Many thanks from me too, Ivan. I have enjoyed working with you and will miss you. Come back any time! -- ___ Python tracker <https://bugs.python.org/issue44

[issue44668] More differences in instance and subclass checks between typing.Union and types.Union

Guido van Rossum added the comment: This seems a low-priority issue to me. The code is invalid, but I don't think it's very important to raise an exception (typing.Union is also inconsistent). Static type checkers will flag all these as errors. (Or perhaps none of them? It may dep

[issue44490] PEP 604 Union (int | str) doesn't have __parameters__

Guido van Rossum added the comment: New changeset a2721649598eb715304a1ac8678a409585f73b27 by Ken Jin in branch '3.10': bpo-44490: Improve typing module compatibility with types.Union (GH-27048) (#27222) https://github.com/python/cpython/commit/a2721649598eb715304a1ac8678a40

[issue44524] __name__ attribute in typing module

Guido van Rossum added the comment: I see this as part of a trend to improve runtime introspection of complex type expressions. That seems to be going ahead regardless of whether we like it or not, so let's do this. -- ___ Python tracker &

[issue44668] More differences in instance and subclass checks between typing.Union and types.Union

Guido van Rossum added the comment: Sure. -- ___ Python tracker <https://bugs.python.org/issue44668> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44353] PEP 604 NewType

Guido van Rossum added the comment: Do we have to solve it? Using `from __future__ import annotations` it should work, at least when used as an annotation. Or is that too inconvenient or inconsistent? -- ___ Python tracker <ht

[issue44653] Parameter substitution in the union type does not work with typing.Union

Guido van Rossum added the comment: I need someone else to own this, sorry. -- ___ Python tracker <https://bugs.python.org/issue44653> ___ ___ Python-bugs-list m

[issue44353] PEP 604 NewType

Guido van Rossum added the comment: Jelle, can you post more details about your benchmark? -- ___ Python tracker <https://bugs.python.org/issue44353> ___ ___

[issue44353] PEP 604 NewType

Guido van Rossum added the comment: Hm, 20% isn't so bad, but one of the arguments for NewType was that it "disappears" at runtime -- which the current version does, but the class-based version doesn't quite. Right now I don't have the cycles to think about this

[issue44353] PEP 604 NewType

Guido van Rossum added the comment: OTOH, for 3.10 the clock is ticking. Let's go for it. (If it's deemed too slow, we could eventually add an accelerator just for this.) -- ___ Python tracker <https://bugs.python.o

[issue43693] Logically merge cell and locals array. They are already contiguous in memory

Guido van Rossum added the comment: Another task seems to have appeared, Nick Coghlan would like the typedef to be renamed to PyLocal_VarKind, and the getter/setter similarly. -- nosy: +ncoghlan ___ Python tracker <https://bugs.python.

[issue44653] Parameter substitution in the union type does not work with typing.Union

Guido van Rossum added the comment: Thanks for taking over here, Ł! -- ___ Python tracker <https://bugs.python.org/issue44653> ___ ___ Python-bugs-list mailin

[issue43838] There is a way to access an underlying mapping in MappingProxyType

Guido van Rossum added the comment: Maybe we should not fix this then? Copying seems unattractive, and the reason we proxy in the first place is not absolute safety but to make sure people don’t accidentally update the dict when they intend to update the class (for the side effect of updating

[issue44732] Rename types.Union to types.UnionType

Guido van Rossum added the comment: Agreed. I think we should do it, Serhiy’s reasoning makes sense. We should just update the PEP and add a note that this was changed during the beta period. -- ___ Python tracker <https://bugs.python.

[issue44098] Remove ParamSpec from __parameters__ of most typing generics

Guido van Rossum added the comment: Yeah, but we shouldn't go out of our way to reject it. Especially since in 3.11 we'll likely have something equivalent to PEP 563 or PEP 649 (the SC is thinking deep about this right now) and either of those means that usually it won't be e

[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence

Guido van Rossum added the comment: Given that the class used to demonstrate this behavior has a bug (__len__ is inconsistent with __getitem__), I don't think it matters much -- if doing it your way is (as I suspect) slower than the current implementation for other (well-behaved) sequ

[issue42913] asyncio.ProactorEventLoop mishandles signal wakeup file descriptor

Guido van Rossum added the comment: Have you investigated how that could be implemented and what the new API would look like? Personally I don't really like signals (they're not portable and code using them is super hard to get right) and I hesitate to add to their API. OTOH maybe

[issue42815] new thread doesn't copy context of the parent thread

Guido van Rossum added the comment: Trust me, it's too late to fix this in 3.10. -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/is

[issue44524] __name__ attribute in typing module

Guido van Rossum added the comment: Serhiy or Ken-Jin? -- ___ Python tracker <https://bugs.python.org/issue44524> ___ ___ Python-bugs-list mailing list Unsub

[issue43838] There is a way to access an underlying mapping in MappingProxyType

Change by Guido van Rossum : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue44885] Incorrect exception highlighting for fstring format

Guido van Rossum added the comment: (I originally reported this.) -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue44885> ___ ___ Python-bug

[issue40222] "Zero cost" exception handling

Guido van Rossum added the comment: I propose we declare all APIs for code objects *unstable*, liable to change each (feature) release. I want to get rid of PyCode_NewWithPosArgs() and just have PyCode_New(). All callers to either one must be changed anyways. (And we’re not done changing

[issue40222] "Zero cost" exception handling

Guido van Rossum added the comment: > >> I want to get rid of PyCode_NewWithPosArgs() and just have PyCode_New(). > That as added because of PEP 387 and unfortunately removing it is backwards > incompatible. Is changing the signature allowed? Because it *must* be chang

[issue40222] "Zero cost" exception handling

Guido van Rossum added the comment: I've started a thread on python-dev. https://mail.python.org/archives/list/python-...@python.org/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/#ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC -- ___ Python tracker &

[issue44863] Allow TypedDict to inherit from Generics

Guido van Rossum added the comment: See also https://github.com/python/mypy/issues/3863 -- ___ Python tracker <https://bugs.python.org/issue44863> ___ ___ Pytho

[issue44926] typing.get_type_hints() raises for type aliases with forward references

Guido van Rossum added the comment: Is GH-27017 at all relevant here? -- ___ Python tracker <https://bugs.python.org/issue44926> ___ ___ Python-bugs-list mailin

[issue44926] typing.get_type_hints() raises for type aliases with forward references

Guido van Rossum added the comment: I think it's fine for get_type_hints() to give up in some cases. It's not fine if it were to look in the wrong namespace (e.g. if the caller of get_type_hints() were to happen to have an unrelated class named "Foo" in its namespace,

[issue44926] typing.get_type_hints() raises for type aliases with forward references

Guido van Rossum added the comment: Maximilian, I think your last analysis is spot on. The problem is specific to type aliases and how at runtime they do not carry information about scope with them. The current type alias syntax (both the original form and the form using "x: Type

[issue44895] refleak test failure in test_exceptions

Guido van Rossum added the comment: So there's code generated for an except clause with a variable that clears the variable at the end, so that this works: try: ... except Exception as err: ... print(err) # Should fail, since err was cleared when the except clause exited. Maybe th

[issue44932] `issubclass` and `isinstance` doesn't check for all 2nd argument types

Guido van Rossum added the comment: Agreed. Thanks, Serhiy. -- ___ Python tracker <https://bugs.python.org/issue44932> ___ ___ Python-bugs-list mailin

[issue44942] Add number pad enter bind to TK's simpleDialog

Guido van Rossum added the comment: It’s fine. We now need the PR author to sign the CLA. -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue44

[issue44942] Add number pad enter bind to TK's simpleDialog

Guido van Rossum added the comment: Sorry, CLA is signed, but I'd like Terry Reedy to have a peek. -- nosy: +terry.reedy ___ Python tracker <https://bugs.python.org/is

[issue44926] typing.get_type_hints() raises for type aliases with forward references

Guido van Rossum added the comment: We could mention this in the docs for one or more of the following: - type aliases (old or new syntax) - forward references - get_type_hints() Ken Jin, can you guide Maximilian towards a successful doc update PR

[issue44921] dict subclassing is slow

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue44921> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44957] typing docs: Mention PEP 604 syntax more prominently

Guido van Rossum added the comment: Ken, this sounds like a good idea. Can you help? -- nosy: +gvanrossum, kj ___ Python tracker <https://bugs.python.org/issue44

[issue44957] typing docs: Mention PEP 604 syntax more prominently

Guido van Rossum added the comment: Thanks to both of you!! -- ___ Python tracker <https://bugs.python.org/issue44957> ___ ___ Python-bugs-list mailin

[issue44926] typing.get_type_hints() raises for type aliases with forward references

Guido van Rossum added the comment: New changeset 16b9be4861e007ad483611ba0479feb2b90ea783 by Maximilian Hils in branch 'main': bpo-44926: `get_type_hints`: Add note about type aliases with forward refs (#27859) https://github.com/python/cpyt

[issue44915] Python keywords as string keys in TypedDict

Guido van Rossum added the comment: Unfortunately you can’t use Python keywords in such positions and we have no plans to fix this. Serhiy’s workaround is the best you can do. -- resolution: -> wont fix stage: -> resolved status: open -&g

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Guido van Rossum added the comment: What about __bytes__? -- ___ Python tracker <https://bugs.python.org/issue24234> ___ ___ Python-bugs-list mailing list Unsub

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

Guido van Rossum added the comment: So let’s add that in a separate PR. -- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue24234> ___ ___

[issue45017] move opcode-related logic from modulefinder to dis

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue45017> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: I noticed nedbat un-nosied himself. Probably he didn't realize you were calling him out because it's possible this would affect coverage.py? -- ___ Python tracker <https://bugs.python.o

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: > The big time consumer is turning marshal'ed code objects back > into Python objects, though. If that could be made faster by > e.g. using a more efficient storage format such as one which is > platform dependent, it'd be a much bigger

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: We should ask Neil S. for the issue where Larry introduced this. That might have some discussion. But if I had to guess, it’s confusing that you can see *Python* source that you can’t edit (or rather, where editing doesn’t get reflected in the next Python

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: The plot thickens. By searching my extensive GMail archives for Jeethu Rao I found an email from Sept. 14 to python-dev by Larry Hastings titled "Store startup modules as C structures for 20%+ startup speed improvement?" It references an issu

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: Adding Larry in case he remembers more color. (Larry: the key question here is whether some version of this (like the one I've been working on, or a simpler one that Eric has prepared) is viable, given that any time someone works on one of the froz

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: > Since nobody's said so in so many words (so far in this thread anyway): the > prototype from Jeethu Rao in 2018 was a different technology than what Eric > is doing. The "Programs/_freeze_importlib.c" Eric's playing with

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: > I'd like to remove docstring from code object at all. > func.__doc__ can be set by MAKE_FUNCTION or STORE_ATTR. You'd just be moving the problem though -- the docstring would have be included in the co_consts array of the surrounding cod

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: Gregor, thanks for sharing your experience! I guess freezing the entire stdlib instead of just a smattering of modules (like we do here) exacerbated the problems in your case. Builtin modules (such as sys or time) don't have a __file__ attribute e

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: Why all the hating on docstrings? What have docstrings done wrong? I know there's the -OO flag that strips docstrings, but it doesn't work well and I think it was a mistake. -- ___ Python track

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: > FWIW, I asked Ned Batchelder about this and he said this approach > ("fullcoverage" [1]) was added to support running coverage on the stdlib. > [...] The docs you pointed out in [3] (where it talks about a *horrible hack yo

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: [Gregory Szorc] > What do you set __file__ to? [...] Exactly. I think it should not be set, just like it's not set for builtin modules. > I have some observations about the implications of this. I typed up a long > comment but then re

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: > At this point, here are the open questions I'm seeing: > + The editing-stdlib-.py-files problem: [...] > + Compatibility: [...] ? + Penalty for too many frozen modules: [...] > FWIW, I think the ideal mechanism for a dev build wil

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: FWIW, I'd be okay with doing the -X flag in a separate PR. -- ___ Python tracker <https://bugs.python.org/is

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: I think we shouldn't change *which* code object contains the docstring (changing anything about that is likely to disturb someone's workflow in a way that's hard to fix) -- only how PyFunction_New finds that docstring in the code object

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

Guido van Rossum added the comment: Thanks! This comes right in time, because we're working on freezing many more modules, and modules containing frozen sets didn't have a consistent frozen representation. Now they do! (See issue45019, issue45020) -- nosy: +

[issue39452] Improve the __main__ module documentation

Guido van Rossum added the comment: Thanks, the rewrite is great! I have one nit: did you consider which of these two idioms is better? if __name__ == "__main__": main() vs. if __name__ == "__main__": sys.exit(main()) Your docs seem to promote the second,

[issue45019] Freezing modules has manual steps but could be automated.

Guido van Rossum added the comment: Is this ready to close? -- ___ Python tracker <https://bugs.python.org/issue45019> ___ ___ Python-bugs-list mailin

[issue45055] Fresh build on Windows fails the first time for zlib.c

New submission from Guido van Rossum : When I make a fresh checkout of the main branch on Windows and type "pcbuild\build" it starts downloading some distributions (e.g. sqlite) and then starts building. Fine. But at some point there's a whole bunch of errors that seem to com

[issue45056] compiler: Unnecessary None in co_consts

Guido van Rossum added the comment: I wonder what the 3.10 compiler does different to cause this -- in 3.9 that extra None is not in co_consts. (Note: Mark is on vacation for 2 weeks.) -- nosy: +Mark.Shannon, gvanrossum ___ Python tracker <ht

[issue45055] Fresh build on Windows fails the first time for zlib.c

Guido van Rossum added the comment: I've seen it a few times. I don't do this that often, but since I've discovered "git worktree" this has occurred to me a few times (can't recall if it was every time, but today wasn't the first). I'm totally

[issue21736] Add __file__ attribute to frozen modules

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue21736> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39452] Improve the __main__ module documentation

Guido van Rossum added the comment: You're right, I'm being inconsistent. :-( I withdraw my objection. There are cases where sys.exit() is easier than returning an exit code, e.g. when the error is discovered deep inside some other code. But it's probably better to ra

[issue44091] traceback & inspect modules should verify that the .py source file matches the one that the running process is using

Guido van Rossum added the comment: This sounds like a project requiring a considerable amount of plumbing to get the info from where it's available to where it's needed. For example, importlib reads the PYC file, checks the header, and then passes the rest of the file to mar

[issue44091] traceback & inspect modules should verify that the .py source file matches the one that the running process is using

Guido van Rossum added the comment: All legit cases, I agree, but are they worth the considerable work? -- ___ Python tracker <https://bugs.python.org/issue44

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

Guido van Rossum added the comment: How come the deprecation didn't happen in 3.10? Were people just not interested? -- ___ Python tracker <https://bugs.python.org/is

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

Guido van Rossum added the comment: We can add to the 3.10 docs that it is deprecated without any code change. And in 3.11 we can add a warning. -- ___ Python tracker <https://bugs.python.org/issue40

[issue23864] doc: issubclass without registration only works for "one-trick pony" collections ABCs.

Guido van Rossum added the comment: Maybe issue45024 is also connected? (It also seems to relate to hasattr() logic.) -- ___ Python tracker <https://bugs.python.org/issue23

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: I am still not convinced that it's a good idea to put the docstring in the surrounding code object. I'd like to be able to see it when I introspect a code object, not just when introspecting a function object (I may be analyzing code only, and

[issue45056] compiler: Unnecessary None in co_consts

Guido van Rossum added the comment: Are you sure? I know we're really close to the release, but I'd much rather change the PYC format during the RC cycle than once we're doing bugfix releases. I don't think we've ever changed the magic number between bugfix releases

[issue45056] compiler: Unnecessary None in co_consts

Guido van Rossum added the comment: Since we're not changing the magic number, wheels created for rc1 will still work with the final 3.10 (and vice versa!) -- creating a wheel or PYC file just will produce a different sequence of bytes, but there are other things that do that. Then

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: Let's wait until Mark Shannon is back from vacation (another week). Note that class docstrings *are* contained in the class body code object -- there's executable code equivalent to __doc__ = "this is the docstring" But I agree i

[issue44863] Allow TypedDict to inherit from Generics

Guido van Rossum added the comment: Updating an existing (standards track) PEP significantly is not traditional. I recommend writing a new PEP. On Sun, Sep 5, 2021 at 01:24 Ken Jin wrote: > > Ken Jin added the comment: > > Guido, OP has kindly written a mini PEP for this. Do yo

[issue44863] Allow TypedDict to inherit from Generics

Guido van Rossum added the comment: Since this primarily affects static type checkers such as mypy, Pyre and pyright, it’s best to discuss it on typing-sig. -- ___ Python tracker <https://bugs.python.org/issue44

[issue45122] Remove PyCode_New and PyCode_NewWithPosOnlyArgs

New submission from Guido van Rossum : This is up for grabs. For reference, the Steering Council approved getting rid of these two C APIs without honoring the customary two-release deprecation period required by PEP 387. For reference see https://github.com/python/steering-council/issues/75

[issue45122] Remove PyCode_New and PyCode_NewWithPosOnlyArgs

Guido van Rossum added the comment: PS. It would be nice to also update Cython, which is the only thing that uses these C APIs. -- ___ Python tracker <https://bugs.python.org/issue45

[issue45122] Remove PyCode_New and PyCode_NewWithPosOnlyArgs

Guido van Rossum added the comment: That sounds like a good plan (note that alpha 1 will go out around Oct 4). I left an issue for Cython: https://github.com/cython/cython/issues/4365 -- ___ Python tracker <https://bugs.python.org/issue45

[issue20115] NUL bytes in commented lines

Guido van Rossum added the comment: Which part puzzles you? I see that you tried >>> #\0 This does not contain a null byte, just three characters: a hash, a backslash, and a digit zero. -- ___ Python tracker <https://bugs.python.or

[issue20115] NUL bytes in commented lines

Guido van Rossum added the comment: Serhiy’s comment from 2014-01-04 gives the answer. It’s different reading from a file than from a string. And only “python x.py” still reads from a file. -- ___ Python tracker <https://bugs.python.org/issue20

[issue45122] Remove PyCode_New and PyCode_NewWithPosOnlyArgs

Guido van Rossum added the comment: Da-woods, can you take care of that? -- ___ Python tracker <https://bugs.python.org/issue45122> ___ ___ Python-bugs-list m

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

Guido van Rossum added the comment: Raymond, I am super grateful that you are showing us the assembly language. That's the kind of thing we need to do more of if we want to be successful. (In this case I'm not surprised by the outcome, but I have never studied x86 assembly and

[issue45152] Prepare for splitting LOAD_CONST into several opcodes

Guido van Rossum added the comment: We're not (yet) trying to optimize the code being executed (we should perhaps add an issue about class creation to https://github.com/faster-cpython/ideas). I agree that marshal is very fast already; I doubt the extra cost of wordcode would pay off

[issue45109] pipes seems designed for bytes but is str-only

Guido van Rossum added the comment: I think that module is probably a relic from the Python 1 days… -- ___ Python tracker <https://bugs.python.org/issue45

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: If you reduce the number of modules being frozen you could probably manage to land this (or most of it) before tackling those other issues. -- ___ Python tracker <https://bugs.python.org/issue45

[issue43893] typing.get_type_hints does not accept type annotations with leading whitespaces

Change by Guido van Rossum : -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue45211] Useful (expensive) information is discarded in getpath.c.

Guido van Rossum added the comment: Honestly I find it debatable whether we're doing anyone a favor by publishing the __file__ of the corresponding stdlib file for frozen modules. There will be situations where this points to the wrong file, and editing the file will not have an e

[issue45188] De-couple the Windows builds from freezing modules.

Guido van Rossum added the comment: Is this now done? I.e. can we now drop the frozen .h files from the repo? -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue45

[issue45186] Marshal output isn't completely deterministic.

Guido van Rossum added the comment: I would propose that marshal internally make an extra pass over its input in order to determine which objects are referenced multiple times. This will speed up reading marshalled data (in addition to addressing the reproducibility issue with debug builds

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: I would move "default to "on" (except if actually running out of the source tree)" to the "maybe" category. I left a few comments in other deps. I think we should start by turning this on by default in PGO builds. Separate

[issue45188] De-couple the Windows builds from freezing modules.

Guido van Rossum added the comment: I tried this: - remove the generated .h files - touched dictobject.c - touched dictobject.h After each step I tried to rebuild. Each case the compilation of frozen.c failed and then the build stopped, so apparently the .h files weren't generated

[issue21736] Add __file__ attribute to frozen modules

Guido van Rossum added the comment: > Note that the filename information is already available in the > code object's co_filename attribute. Hm, in the latest (3.11) main that's not true -- co_filename is set to something like "". And that's about right, since

[issue45188] De-couple the Windows builds from freezing modules.

Guido van Rossum added the comment: We can once GH-28375 lands. -- ___ Python tracker <https://bugs.python.org/issue45188> ___ ___ Python-bugs-list mailin

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: FWIW, Python/frozen_modules/__hello__.h is still in the repo somehow. -- ___ Python tracker <https://bugs.python.org/issue45

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: (Ah, now I recall how the $(srcdir) mechanism works again. Generated files do *not* have a $(srcdir) prefix, since they are generated in the destination directory. Hence the fix for the buildbot failure a few days ago. I take back my skepticism about that

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: BTW, why does the script still run Programs/_freeze_module over all the modules to be frozen? Isn't that up to the Makefile or its Windows equivalent? -- ___ Python tracker <https://bugs.python.org/is

[issue45020] Freeze all modules imported during startup.

Guido van Rossum added the comment: > It would be nice to freeze argparse.py and its dependencies. For > command-line tools, startup time is important. I quickly checked, and argparse has at least these dependencies: argparse re enum types operator functools collections keyword r

[issue24076] sum() several times slower on Python 3 64-bit

Guido van Rossum added the comment: @Stefan > FWIW, a PGO build of Py3.7 is now about 20% *faster* here than my Ubuntu > 16/04 system Python 2.7 Does that mean we can close this issue? Or do I misunderstand what you are comparing? 32 vs. 64 bits? PGO vs. non-PGO? OTOH on my Mac I

[issue24138] Speed up range() by caching and modifying long objects

Guido van Rossum added the comment: Should we try the free list for integers again? -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue24

[issue24138] Speed up range() by caching and modifying long objects

Guido van Rossum added the comment: (Never mind, that should have gone to https://bugs.python.org/issue24165, which is the integer freelist -- conclusion there in 2015 was also that it didn't do much.) -- ___ Python tracker &

[issue24165] Free list for single-digits ints

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue24165> ___ ___ Python-bugs-list mailing list Unsubscribe:

<    17   18   19   20   21   22   23   24   25   26   >