[Python-Dev] Re: killing static types (for sub-interpreters?)

If the object is going to live until the "end of time" (process/runtime/whatever) then there'll never be a need to deallocate it, and so there's no point counting how many references exist (and ditto for anything that it references). Currently, statically allocated types include references to

[Python-Dev] Re: killing static types (for sub-interpreters?)

On 28Apr2020 2006, Steve Dower wrote: (For those who aren't following it, there's a discussion with a patch and benchmarks going on at https://bugs.python.org/issue40255 about making objects individually immortal. It's more focused around copy-on-write, rather than subinterp

[Python-Dev] Remove ctypes from uuid

For those who haven't looked in a while, the uuid module uses ctypes to look up libuuid for uuid_generate_time_safe() and uuid_generate_time() functions. I've run into scenarios where I need to remove this from our own builds, but it seems like it's probably unnecessary anyway? It's certainly

[Python-Dev] Re: A PEP PR that I closed until someone discusses context

On 06May2020 2204, joannah nanjekye wrote: I saw a PR on the PEP repository that looked like a joke here : https://github.com/python/peps/pull/1396 The author can give context to re-open if it was intentional. Given there isn't a real email address on the PEP, I'd assume it was meant as a jo

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 02Jun2020 1430, David Mertz wrote: On Tue, Jun 2, 2020 at 8:07 AM Chris Angelico > wrote: > Given that the only input parameters are the iterables themselves, it's a stretch to even consider the first two as possibilities. Why? I can conceivably imag

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 12Jun2020 1008, Paul Moore wrote: On Fri, 12 Jun 2020 at 09:47, Mark Shannon wrote: Starting a new process is cheap. On my machine, starting a new Python process takes under 1ms and uses a few Mbytes. Is that on Windows or Unix? Traditionally, process creation has been costly on Windows, w

[Python-Dev] Re: When can we remove wchar_t* cache from string?

On 16Jun2020 1641, Inada Naoki wrote: * This change doesn't affect to pure Python packages. * Most of the rest uses Cython. Since I already report an issue to Cython, regenerating with new Cython release fixes them. The precedent set in our last release with tp_print was that regenerating

[Python-Dev] Re: Design and Architecture of python

If you're not willing to slog through the source code and many PEPs and past discussions, Anthony Shaw has done it for you and written a book: https://realpython.com/products/cpython-internals-book/ All the other write-ups I'm aware of are very dated, so I don't have any free suggestions I'm a

[Python-Dev] Re: os.add_dll_directory and DLL search order

On 22Jun2020 1039, Seth G wrote: However, there is one feature of using the Windows PATH that I can't seem to replicate with add_dll_directory. The MapServer DLL builds are linked to sqlite3 3.24.0, whereas Python 3.8.2 is linked to 2.6.0. Building with matching versions is not something I can

[Python-Dev] Re: os.add_dll_directory and DLL search order

On 22Jun2020 1646, Steve Dower wrote: DLLs should not be in the search path at all - it's searched by sys.path when importing .pyd files, which are loaded by absolute path and their dependencies found adjacent. To clarify this - by "DLLs" I meant the DLLs directory, not D

[Python-Dev] Re: How to customize CPython to a minimal set

On 21Jul2020 0633, Huang, Yang wrote: Yes. Micropyhton is also in consideration. But sqlite3 is the first usage. There should be some additional features like numpy, scipy... Not sure if micropython supports well? Or is there a feasible way to strip CPython ? Only by manually removing modul

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 22Jul2020 1319, Mark Shannon wrote: On 21/07/2020 9:46 pm, Gregory P. Smith wrote: Q: Why can't we have the information about the entire span of lines rather than consider a definition to be a "line"? Pretty much every profiler, coverage tool, and debugger ever expects lines to be natura

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 25Jul2020 2014, Jim J. Jewett wrote: But it sounds as though you are saying the benefit is irrelevant; it is just inherently too expensive to ask programs that are already dealing with internals and trying to optimize performance to make a mechanical change from: code.magic_attrname to:

[Python-Dev] Re: Fwd: [pypi-announce] upgrade to pip 20.2 -- plus changes coming in 20.3

Do you think we should be updating the version of pip bundled with Python 3.9 at this stage (for the first RC)? Similarly, is there a need to update Python 3.8 for its next release? Thanks, Steve On 30Jul2020 2119, Sumana Harihareswara wrote: A new pip is out. Please see below, upgrade, and le

[Python-Dev] Re: Fwd: [pypi-announce] upgrade to pip 20.2 -- plus changes coming in 20.3

Thanks. It looks like we can do it later this week and make the next round of releases. Please let us know asap if anything comes up that you wouldn't want to be released. Cheers, Steve On 01Aug2020 1632, Sumana Harihareswara wrote: Steve Dower asked: Do you think we should be updatin

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 07Aug2020 2133, Joao S. O. Bueno wrote: Enough cheaptalk - links are here: tests: https://github.com/jsbueno/terminedia/blob/fa5ac012a7b93a2abe26ff6ca41dbd5f5449cb0b/tests/test_utils.py#L356 Branch comparison for the match/case version: https://github.com/jsbueno/terminedia/compare/patma I

[Python-Dev] Re: Procedure for trivial PRs

On 8/13/2020 9:56 PM, Mariatta wrote:  a) is it ok to touch 3.9, as it's in rc1? Yeah bug fixes are accepted to the maintenance branches. I think your PR does count as documentation bug fix, so it should be ok to backport to 3.9 At this stage, changes to the 3.9 branch won't go into the

[Python-Dev] PEP 632: Deprecate distutils module

iodically check in and skim read it, assuming things don't go way off track). Also be aware that I already have some minor changes lined up that are not in this text. Refer to the discussion on Discourse if you need to see those. Cheers, Steve --- PEP: 632 Title: Deprecate distutils

[Python-Dev] Re: PEP 632: Deprecate distutils module

Thanks everyone for your input so far. Rest assured, I am very aware of air-gapped and limited network systems, as well as corporate policies and processes. Having distutils in the standard library does not help with any of these. Do not forget that pip (and presently, though not permanently,

[Python-Dev] Re: PEP 632: Deprecate distutils module

On 07Sep2020 1424, Stefan Krah wrote: On Mon, Sep 07, 2020 at 11:43:41AM +0100, Steve Dower wrote: Rest assured, I am very aware of air-gapped and limited network systems, as well as corporate policies and processes. Having distutils in the standard library does not help with any of these. Of

[Python-Dev] Re: PEP 632: Deprecate distutils module

On 07Sep2020 1602, Stefan Krah wrote: I'm under the impression that distutils has effectively been frozen for the last decade, except for the substantial improvements you made for the MSVC part. For Unix, no one has addressed e.g. C++ support. The underlying reason has always been that we cannot

[Python-Dev] Re: PEP 632: Deprecate distutils module

On 9/11/2020 12:24 PM, Matthias Klose wrote: On 9/4/20 1:28 PM, Steve Dower wrote: Hi all. setuptools has recently adopted the entire codebase of the distutils module, so that they will be able to make improvements directly without having to rely on patching the standard library. As a result

Re: [Python-Dev] Draft PEP for time zone support.

Paul Moore wrote: > On 12 December 2012 16:11, Brian Curtin wrote: > > I don't think it's all that bad to include a small script on Windows > > which runs every few days to check PyPI, then present an option to > > update the info. This is what Java itself is doing anyway. > > What would that do

<    3   4   5   6   7   8