[issue38187] test.test_tools.test_c_analyzer fails in refleak mode

Change by Eric Snow : -- assignee: -> eric.snow resolution: -> fixed stage: patch review -> resolved status: open -> pending ___ Python tracker <https://bugs.python

[issue38187] test.test_tools.test_c_analyzer fails in refleak mode

Change by Eric Snow : -- status: pending -> closed ___ Python tracker <https://bugs.python.org/issue38187> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue36876] Global C variables are a problem.

Change by Eric Snow : -- pull_requests: +16393 pull_request: https://github.com/python/cpython/pull/16841 ___ Python tracker <https://bugs.python.org/issue36

[issue36876] Global C variables are a problem.

Eric Snow added the comment: New changeset e4c431ecf50def40eb93c3969c1e4eeaf7bf32f1 by Eric Snow in branch 'master': bpo-36876: Re-organize the c-analyzer tool code. (gh-16841) https://github.com/python/cpython/commit/e4c431ecf50def40eb93c3969c1e4e

[issue38631] Replace Py_FatalError() with regular Python exceptions

Eric Snow added the comment: FWIW, I agree. :) -- nosy: +eric.snow ___ Python tracker <https://bugs.python.org/issue38631> ___ ___ Python-bugs-list mailin

[issue38500] Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals

Eric Snow added the comment: It depends on how you look at the degree to which you are interacting with the runtime. This is a fairly low-level hook into the runtime. So arguably if you are using this API then you should specify being a "core" extension. That said, getting t

[issue40255] Fixing Copy on Writes from reference counting

Change by Eric Snow : -- nosy: +eric.snow nosy_count: 15.0 -> 16.0 pull_requests: +23592 pull_request: https://github.com/python/cpython/pull/24828 ___ Python tracker <https://bugs.python.org/issu

[issue40255] Fixing Copy on Writes from reference counting

Eric Snow added the comment: FYI, I've just put up a similar PR [1] to Eddie's, with a focus on object immortality rather than immutability. However, if Py_IMMORTAL_CONST_REFCOUNTS is defined then it should have the behavior Eddie is after. [1] https://github.com/python/cpython/

[issue40255] Fixing Copy on Writes from reference counting

Eric Snow added the comment: Note that my PR does make the builtin types immortal (at least those initialized in _PyTypes_Init()). However, I did not make the singletons or other candidate objects immortal in the PR. That can be done separately

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

New submission from Eric Snow : In the limited C-API we expose the following static PyObject variables: * 5 singletons * ~70 exception types * ~70 other types Since they are part of the limited API, they have a direct effect on the stable ABI. The problem is that these objects should not be

[issue40255] Fixing Copy on Writes from reference counting

Eric Snow added the comment: While the eventual solution may overlap, my interests are divergent enough from those here that I've created a separate issue: bpo-43503. -- ___ Python tracker <https://bugs.python.org/is

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: Here are some solutions that I've considered: 1. immutable objects a. make the objects truly immutable/const * not trivial, if possible b. make the objects effectively immutable * (see GH-24828) use a really high refcount to make races irrel

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: If the stable ABI weren't an issue then we would probably: * deprecate using the objects directly * do something like (2a) in the meantime It may make sense to do that for "#ifndef Py_LIMITED_API", regardless of how we handle

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Change by Eric Snow : -- nosy: +Mark.Shannon, nascheme, vstinner ___ Python tracker <https://bugs.python.org/issue43503> ___ ___ Python-bugs-list mailin

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Change by Eric Snow : -- keywords: +patch pull_requests: +23642 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/24828 ___ Python tracker <https://bugs.python.org/issu

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Change by Eric Snow : -- components: +Extension Modules, Interpreter Core, Subinterpreters ___ Python tracker <https://bugs.python.org/issue43503> ___ ___ Pytho

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by Eric Snow : -- nosy: +eric.snow nosy_count: 2.0 -> 3.0 pull_requests: +23645 pull_request: https://github.com/python/cpython/pull/24828 ___ Python tracker <https://bugs.python.org/issu

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: One simple solution is to explicitly state that the limited API does not support subinterpreters. This is already implied by the fact that the multi-phase init API (PEP 489) requires subinterpreter support but is not part of the limited API. If we establish

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: FYI, I posted to capi-sig about this: https://mail.python.org/archives/list/capi-...@python.org/thread/INLCGPMTYFLRTWQL7RB4MUQZ37JAFRAU/ -- ___ Python tracker <https://bugs.python.org/issue43

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: > I am confused. How can widening the usable number of functions (i.e. using > the whole C-API rather than the limited API) help c-extension modules be > usable in subinterpreters? Aren't the same singletons, exception types, and > other types expo

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: > PEP 489 is *very much* part of the limited API. Gah, I missed that. That said, I don't think it matters; I just lose an easy point in the rationale. :) -- ___ Python tracker <https://bugs.python.org

[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.

Eric Snow added the comment: FYI, I'm going to focus discussion on the capi-sig thread. -- ___ Python tracker <https://bugs.python.org/issue43503> ___ ___

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

Change by Eric Snow : -- nosy: +eric.snow nosy_count: 4.0 -> 5.0 pull_requests: +24833 pull_request: https://github.com/python/cpython/pull/26216 ___ Python tracker <https://bugs.python.org/issu

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

Change by Eric Snow : -- pull_requests: +24865 pull_request: https://github.com/python/cpython/pull/26258 ___ Python tracker <https://bugs.python.org/issue43

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

Change by Eric Snow : -- pull_requests: +24955 pull_request: https://github.com/python/cpython/pull/26364 ___ Python tracker <https://bugs.python.org/issue43

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

Change by Eric Snow : -- pull_requests: +24967 pull_request: https://github.com/python/cpython/pull/26375 ___ Python tracker <https://bugs.python.org/issue43

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

Change by Eric Snow : -- pull_requests: +24981 pull_request: https://github.com/python/cpython/pull/26388 ___ Python tracker <https://bugs.python.org/issue43

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

Change by Eric Snow : -- pull_requests: +24989 pull_request: https://github.com/python/cpython/pull/26396 ___ Python tracker <https://bugs.python.org/issue43

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

Eric Snow added the comment: New changeset 9f494d492944c3a6a7a7471b4ad3a025dc7de289 by Eric Snow in branch 'main': bpo-43693: Add _PyCode_New(). (gh-26375) https://github.com/python/cpython/commit/9f494d492944c3a6a7a7471b4ad3a0

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

Eric Snow added the comment: New changeset 2c1e2583fdc4db6b43d163239ea42b0e8394171f by Eric Snow in branch 'main': bpo-43693: Add new internal code objects fields: co_fastlocalnames and co_fastlocalkinds. (gh-26388) https://github.com/python/cpyt

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

Eric Snow added the comment: New changeset b2bf2bc1ece673d387341e06c8d3c2bc6e259747 by Mark Shannon in branch 'main': bpo-43693: Compute deref offsets in compiler (gh-25152) https://github.com/python/cpython/commit/b2bf2bc1ece673d387341e06c8d3c2

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

Eric Snow added the comment: Thanks Pablo. I'll get this sorted out. Sorry for the pain. -- ___ Python tracker <https://bugs.python.org/issue43693> ___ ___

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

Change by Eric Snow : -- pull_requests: +25165 pull_request: https://github.com/python/cpython/pull/26577 ___ Python tracker <https://bugs.python.org/issue43

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

Eric Snow added the comment: New changeset 2ab27c4af4ddf7528e1375e77c787c7fbb09b5e6 by Eric Snow in branch 'main': bpo-43693: Un-revert commits 2c1e258 and b2bf2bc. (gh-26577) https://github.com/python/cpython/commit/2ab27c4af4ddf7528e1375e77c787c

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

Eric Snow added the comment: New changeset 631f9938b1604d4f893417ec339b9e0fa9196fb1 by Eric Snow in branch 'main': bpo-43693: Add the MAKE_CELL opcode and interleave fast locals offsets. (gh-26396) https://github.com/python/cpython/commit/631f9938b1604d4f893417ec339b9e

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

Change by Eric Snow : -- pull_requests: +25172 pull_request: https://github.com/python/cpython/pull/26587 ___ Python tracker <https://bugs.python.org/issue43

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

Change by Eric Snow : -- pull_requests: +25173 pull_request: https://github.com/python/cpython/pull/26588 ___ Python tracker <https://bugs.python.org/issue43

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

Eric Snow added the comment: New changeset 165c884154901deae46b5e328a6414d130e6bfff by Eric Snow in branch 'main': bpo-43693: Silence some compiler warnings. (gh-26588) https://github.com/python/cpython/commit/165c884154901deae46b5e328a6414

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

Eric Snow added the comment: Thanks, Pablo! -- ___ Python tracker <https://bugs.python.org/issue43693> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by Eric Snow : -- pull_requests: +25192 pull_request: https://github.com/python/cpython/pull/26609 ___ Python tracker <https://bugs.python.org/issue43

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

Eric Snow added the comment: New changeset 3e1c7167d86a2a928cdcb659094aa10bb5550c4c by Eric Snow in branch 'main': bpo-43693: Un-revert commit f3fa63e. (#26609) https://github.com/python/cpython/commit/3e1c7167d86a2a928cdcb659094aa1

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

Change by Eric Snow : -- pull_requests: +25212 pull_request: https://github.com/python/cpython/pull/26626 ___ Python tracker <https://bugs.python.org/issue43

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

Eric Snow added the comment: New changeset e6e34e45222b9c7a63ba92386612acf768082ba0 by Eric Snow in branch 'main': bpo-43693: Do not check co_cell2arg if a non-cell offset. (gh-26626) https://github.com/python/cpython/commit/e6e34e45222b9c7a63ba92386612ac

[issue44363] Address sanitizer (gcc version) is generating false positives

Eric Snow added the comment: This was my bad. I only partially fixed original problem when un-reverting 3fa63e in gh-26609. I've merged the rest of the fix in gh-26626. Sorry about that. -- nosy: +eric.snow ___ Python tracker &

[issue42088] types.SimpleNamespace.__repr__ documentation inconsistency

Eric Snow added the comment: I'm not sure what to think about this. The type is explicitly exposed to Python code "SimpleNamespace" via the types module. However, that's the same as how other builtin types are exposed in that module. For example, the builti

[issue42088] types.SimpleNamespace.__repr__ documentation inconsistency

Eric Snow added the comment: > According to the documentation for types.SimpleNamespace, > `repr(SimpleNamespace())` > should return `"SimpleNamespace()"`, but in actuality returns `"namespace()"`. Note that I purposefully wrote "roughly" in the docs (

[issue21760] inspect documentation describes module type inaccurately

Eric Snow added the comment: I've merged the changes for __file__. Thanks, furkanonder! The fixes in the types module remain to be done, though now I see 4 of the relevant attributes instead of 2. (missing: __path__, __file__, __cac

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

Eric Snow added the comment: New changeset ac38a9f2dfbba95f5d4338eb11a0221d38ef9328 by Eric Snow in branch 'main': bpo-43693: Eliminate unused "fast locals". (gh-26587) https://github.com/python/cpython/commit/ac38a9f2dfbba95f5d43

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

Eric Snow added the comment: FWIW, I've wrapped up the key parts that I wanted to get done here (co_localplusnames/kinds, MAKE_CELL, eliminate unused fast local for arg cells). I'm leaving this open for now as there are a few things I didn't do that seem part of the original in

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

Change by Eric Snow : -- assignee: eric.snow -> stage: patch review -> needs patch ___ Python tracker <https://bugs.python.org/issue43693> ___ ___ Pyth

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

New submission from Eric Snow : Currently we freeze the 3 main import-related modules, as well as one module for testing. Adding more modules or otherwise making any adjustments requires manually editing several files (frozen.c, Makefile.pre.in, ...). Those files aren't particu

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

Change by Eric Snow : -- keywords: +patch pull_requests: +26428 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/27980 ___ Python tracker <https://bugs.python.org/issu

[issue45020] Freeze all modules imported during startup.

New submission from Eric Snow : Currently we freeze the 3 main import-related modules into the python binary (along with one test module). This allows us to bootstrap the import machinery from Python modules. It also means we get better performance importing those modules. If we freeze

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: FYI, with my branch I'm getting a 15% improvement to startup for "./python -c pass". -- ___ Python tracker <https://bugs.pyt

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: I'm aware of two potentially problematic consequences to this change: * making changes to those source files for the modules will not be reflected during execution until after "make" is run * tricks to inject hooks ASAP (e.g. coverage.py swap

[issue45020] Freeze all modules imported during startup.

Eric Snow 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.

Eric Snow added the comment: > For the latter, the obvious solution is to introduce a startup hook I'm not sure why I said "obvious". Sorry about that. -- ___ Python tracker <https://bugs.

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: @Guido, @Mark Shannon, do you recall the other issue where folks objected to that other patch, due to local changes to source files not being reflected? Also, one thought that comes to mind is that we could ignore the frozen modules when in a dev environment

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: Neil, do you recall the story here? -- nosy: +BTaskaya, brandtbucher, nascheme ___ Python tracker <https://bugs.python.org/issue45

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: On Fri, Aug 27, 2021 at 6:29 PM Guido van Rossum wrote: > 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

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: On Fri, Aug 27, 2021 at 11:14 PM Larry Hastings wrote: > [snip] On the other hand: if we made a viable tool that could consume some > arbitrary > set of .py files and produce a C file, and said C file could then be compiled > into a > shared lib

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: At this point, here are the open questions I'm seeing: + The editing-stdlib-.py-files problem: * use a command-line flag to opt-out of frozen modules? * use a build flag to opt out (e.g. a configure flag or a new Py_NO_FROZEN or even Py_DEBUG)? * i

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: > * tricks to inject hooks ASAP (e.g. coverage.py swaps the encodings module) > may lose their entry point FWIW, I asked Ned Batchelder about this and he said this approach ("fullcoverage" [1]) was added to support running coverage on the stdl

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: On Mon, Aug 30, 2021 at 2:22 PM Guido van Rossum wrote: > I propose to only opt in by default in **PGO builds**. After all what we're > doing is another extreme optimization. > > It should always be possible to opt in using some -X flag (

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

Eric Snow added the comment: New changeset 044e8d866fdde3804bdb2282c7d23a8074de8f6f by Eric Snow in branch 'main': bpo-45019: Add a tool to generate list of modules to include for frozen modules (gh-27980) https://github.com/python/cpython/commit/044e8d866fdde3804bdb2282c7d23a

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

Eric Snow added the comment: I'm just waiting for the buildbots to finish. -- ___ Python tracker <https://bugs.python.org/issue45019> ___ ___ Python-bugs-l

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

Change by Eric Snow : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue45020] Freeze all modules imported during startup.

Change by Eric Snow : -- keywords: +patch pull_requests: +26549 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/28107 ___ Python tracker <https://bugs.python.org/issu

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: On Tue, Aug 31, 2021 at 10:05 PM Inada Naoki wrote: > I don't want all frozen header files to be committed in git repository. > Can't we just build them during build process? That's a good point (and an interesting one). Only two of t

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: On Tue, Aug 31, 2021 at 12:14 PM Brett Cannon wrote: > > set __file__ (and __path__) on frozen modules? > > See https://bugs.python.org/issue21736 Great! I'll take a look. -- ___ Pytho

[issue45096] Update Tools/freeze to make use of Tools/scripts/freeze_modules.py?

New submission from Eric Snow : In bpo-45019 we added Tools/scripts/freeze_modules.py to improve how we manage which modules get frozen by default. (We turned previously manual steps into automation of generated code.) There is probably some overlap with what we do in Tools/freeze

[issue45186] Marshal output isn't completely deterministic.

New submission from Eric Snow : (See: https://github.com/python/cpython/pull/28107#issuecomment-915627148) The output from marshal (e.g. PyMarshal_WriteObjectToString(), marshal.dump()) may be different depending on if it is a debug or non-debug build. I found this while working on freezing

[issue45186] Marshal output isn't completely deterministic.

Eric Snow added the comment: FYI, I came up with a fix (for frozen modules, at least) in https://github.com/python/cpython/pull/28107. -- ___ Python tracker <https://bugs.python.org/issue45

[issue45186] Marshal output isn't completely deterministic.

Eric Snow added the comment: One consequence of this is that frozen module .h files can be different for debug vs. non-debug, which causes CI (and Windows builds) to fail. -- ___ Python tracker <https://bugs.python.org/issue45

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

New submission from Eric Snow : Currently for Windows builds, generating the frozen modules depends on first building python.exe. One consequence of this is that we must keep all frozen module .h files in the repo (which we'd like to avoid for various reasons). We should be able to f

[issue45020] Freeze all modules imported during startup.

Change by Eric Snow : -- dependencies: +De-couple the Windows builds from freezing modules., Marshal output isn't completely deterministic. ___ Python tracker <https://bugs.python.org/is

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

Change by Eric Snow : -- pull_requests: +26728 pull_request: https://github.com/python/cpython/pull/28319 ___ Python tracker <https://bugs.python.org/issue45

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

Eric Snow added the comment: New changeset a2d8c4b81b8e68e2ffe10945f7ca69174c14e52a by Eric Snow in branch 'main': bpo-45019: Do some cleanup related to frozen modules. (gh-28319) https://github.com/python/cpython/commit/a2d8c4b81b8e68e2ffe10945f7ca69

[issue45020] Freeze all modules imported during startup.

Change by Eric Snow : -- pull_requests: +26729 pull_request: https://github.com/python/cpython/pull/28320 ___ Python tracker <https://bugs.python.org/issue45

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: On Mon, Sep 13, 2021 at 2:59 PM Guido van Rossum wrote: > 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. Yeah, that's wha

[issue45189] Drop the "list_frozen" command from _test_embed.

New submission from Eric Snow : In Programs/_test_embed.c the "list_frozen" command prints out the name of each frozen module (defined in Python/frozen.c). The only place this is used is in Tools/scripts/generate_stdlib_module_names.py (in list_frozen()). That script can be updat

[issue45186] Marshal output isn't completely deterministic.

Change by Eric Snow : -- keywords: +patch pull_requests: +26746 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/28335 ___ Python tracker <https://bugs.python.org/issu

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

Change by Eric Snow : -- pull_requests: +26747 pull_request: https://github.com/python/cpython/pull/28335 ___ Python tracker <https://bugs.python.org/issue45

[issue45020] Freeze all modules imported during startup.

Change by Eric Snow : -- pull_requests: +26745 pull_request: https://github.com/python/cpython/pull/28335 ___ Python tracker <https://bugs.python.org/issue45

[issue21736] Add __file__ attribute to frozen modules

Change by Eric Snow : -- pull_requests: +26748 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28335 ___ Python tracker <https://bugs.python.org/issu

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: New changeset a65c86889e208dddb26a7ebe7840c24edbcca775 by Eric Snow in branch 'main': bpo-45020: Add -X frozen_modules=[on|off] to explicitly control use of frozen modules. (gh-28320) https://github.com/python/cpyt

[issue45189] Drop the "list_frozen" command from _test_embed.

Eric Snow added the comment: Yeah, sorry, I got the PRs mixed up. I added it in https://github.com/python/cpython/pull/28320. _imp._get_frozen_module_names() should work just fine. -- ___ Python tracker <https://bugs.python.org/issue45

[issue45186] Marshal output isn't completely deterministic.

Eric Snow added the comment: New changeset cbeb81971057d6c382f45ecce92df2b204d4106a by Eric Snow in branch 'main': bpo-45020: Freeze some of the modules imported during startup. (gh-28335) https://github.com/python/cpython/commit/cbeb81971057d6c382f45ecce92df2

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: New changeset cbeb81971057d6c382f45ecce92df2b204d4106a by Eric Snow in branch 'main': bpo-45020: Freeze some of the modules imported during startup. (gh-28335) https://github.com/python/cpython/commit/cbeb81971057d6c382f45ecce92df2

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

Eric Snow added the comment: New changeset cbeb81971057d6c382f45ecce92df2b204d4106a by Eric Snow in branch 'main': bpo-45020: Freeze some of the modules imported during startup. (gh-28335) https://github.com/python/cpython/commit/cbeb81971057d6c382f45ecce92df2

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

New submission from Eric Snow : Currently we calculate a number of filesystem paths during runtime initialization in Modules/getpath.c (with the key goal of producing what will end up in sys.path). Some of those paths are preserved and some are not. In cases where the discarded data comes

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

Eric Snow added the comment: On Wed, Sep 15, 2021 at 7:51 AM Karthikeyan Singaravelan wrote: > The PR 28319 seems to have introduced a new deprecation warning in tests : I'll fix that. -- ___ Python tracker <https://bugs.python.org

[issue45213] Frozen modules are looked up using a linear search.

New submission from Eric Snow : When looking up a frozen modules, we loop over the array of frozen modules until we find a match (or don't). See find_frozen() in Python/import.c. The frozen importer sits right after the builtin importer and right before the file-based importer. This

[issue45213] Frozen modules are looked up using a linear search.

Eric Snow added the comment: Realistically, I doubt this will ever be a problem. The list of frozen modules is fairly small and the loop in the C code is a lightweight. So it isn't that big of a deal relative to the other costs involved in import. Even if the number of frozen mo

[issue45020] Freeze all modules imported during startup.

Eric Snow added the comment: At this point the fundamental work is done. Here are some follow-up tasks to wrap up this issue: * freeze the remaining stdlib modules imported during startup (os, site, codecs, encodings.*) + blocked by bpo-45186 and bpo-45188 * default to "on"

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

Change by Eric Snow : -- pull_requests: +26776 pull_request: https://github.com/python/cpython/pull/28362 ___ Python tracker <https://bugs.python.org/issue45

[issue45186] Marshal output isn't completely deterministic.

Eric Snow added the comment: That's a good idea. It's certainly cleaner than the approach I took (optionally pass in to marshal.dumps() the list of "before" object/refcount pairs to compare in w_ref()). Adding a flag to marshal.dumps() to opt out shouldn't be to

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

Eric Snow added the comment: New changeset 4b30aaa0c9dc4da956199dbd48af9c06089cb271 by Eric Snow in branch 'main': bpo-45019: Silence a warning in test_ctypes. (gh-28362) https://github.com/python/cpython/commit/4b30aaa0c9dc4da956199dbd48af9c

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

Change by Eric Snow : -- pull_requests: +26788 pull_request: https://github.com/python/cpython/pull/28374 ___ Python tracker <https://bugs.python.org/issue45

[issue45020] Freeze all modules imported during startup.

Change by Eric Snow : -- pull_requests: +26790 pull_request: https://github.com/python/cpython/pull/28375 ___ Python tracker <https://bugs.python.org/issue45

<    1   2   3   4   5   6   7   8   9   10   >