[Python-Dev] Re: A better way to freeze modules

Thanks for all the replies, everyone! I'll reply to a few comments individually. But I first wanted to address the common theme around zipimport. First, one idea that nobody mentioned (and came to me after reading the replies) was to possibly leverage zipimport for freezing the standard library

[Python-Dev] A better way to freeze modules

Over in https://bugs.python.org/issue45020 there is some exciting work around expanding the use of the frozen importer to speed up Python interpreter startup. I wholeheartedly support the effort and don't want to discourage progress in this area. Simultaneously, I've been down this path before

[Python-Dev] Re: macOS issues with 3.8.7rc1

ssity. While I think there are merits to having a discussion around macOS version support policy, may I ask that it take place in a different thread so it doesn't derail the more immediate conversation centering around the 3.8.7 release? > > On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc > w

[Python-Dev] Re: macOS issues with 3.8.7rc1

On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren wrote: > > > On 8 Dec 2020, at 19:59, Gregory Szorc wrote: > > Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding > macOS. > > Without the changes from https://github.com/python/cpython/pull/22855

[Python-Dev] macOS issues with 3.8.7rc1

Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS. Without the changes from https://github.com/python/cpython/pull/22855 backported, attempting to build a portable binary on macOS 11 (e.g. by setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning:

[Python-Dev] Building Standalone Python Applications with PyOxidizer

towards incorporation in official Python packaging tools a few years down the road. I'm not too familiar with the various day-to-day happenings of Python and Python Packaging. But if you steer me in the right direction, I could start getting involved... I hope you like PyOxidizer! Gregory Szorc

Re: [Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 3rd version

On 5/20/2019 4:09 AM, Victor Stinner wrote: > Hi Gregory, > > IMHO your remarks are not directly related to the PEP 587 and can be > addressed in parallel. > >> It sounds like PyOxidizer and Hermetic Python are on the same page and >> we're working towards a more official solution. But I want to

Re: [Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 3rd version

On 5/16/2019 10:25 AM, Victor Stinner wrote: > Le jeu. 16 mai 2019 à 16:10, Thomas Wouters a écrit : >>> Would you be ok with a "PyConfig_Init(PyConfig *config);" function >>> which would initialize all fields to theire default values? Maybe >>> PyConfig_INIT should be renamed to

Re: [Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 3rd version

On 5/15/2019 4:10 PM, Victor Stinner wrote: > Hi, > > Thanks to the constructive discussions, I enhanced my PEP 587. I don't > plan any further change, the PEP is now ready to review (and maybe > even for pronouncement, hi Thomas! :-)). > > The Rationale now better explains all challenges and

Re: [Python-Dev] Python startup time

On 5/1/2018 8:26 PM, Gregory Szorc wrote: > On 7/19/2017 12:15 PM, Larry Hastings wrote: >> >> >> On 07/19/2017 05:59 AM, Victor Stinner wrote: >>> Mercurial startup time is already 45.8x slower than Git whereas tested >>> Mercurial runs on Python 2.7.12

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018 at 8:26 PM, Benjamin Peterson <benja...@python.org> wrote: > > > On Wed, May 2, 2018, at 09:42, Gregory Szorc wrote: > > The direction Mercurial is going in is that `hg` will likely become a > Rust > > binary (instead of a #!python script) th

Re: [Python-Dev] Python startup time

On 5/2/18 2:24 PM, Barry Warsaw wrote: > On May 2, 2018, at 09:42, Gregory Szorc <gregory.sz...@gmail.com> wrote: > >> As for things Python could do to make things better, one idea is for >> "package bundles." Instead of using .py, .pyc, .so, etc files as se

Re: [Python-Dev] Python startup time

On Tue, May 1, 2018 at 11:55 PM, Ray Donnelly wrote: > Is your Python interpreter statically linked? The Python 3 ones from the anaconda distribution (use Miniconda!) are for Linux and macOS and that roughly halved our startup times. My Python interpreters use a shared

Re: [Python-Dev] Python startup time

On 7/19/2017 12:15 PM, Larry Hastings wrote: > > > On 07/19/2017 05:59 AM, Victor Stinner wrote: >> Mercurial startup time is already 45.8x slower than Git whereas tested >> Mercurial runs on Python 2.7.12. Now try to sell Python 3 to Mercurial >> developers, with a startup time 2x - 3x

Re: [Python-Dev] Better support for consuming vendored packages

On 3/22/2018 10:48 AM, Oleg Broytman wrote: > Hi! > > On Thu, Mar 22, 2018 at 09:58:07AM -0700, Gregory Szorc > <gregory.sz...@gmail.com> wrote: >> Not all consumers of Python packages wish to consume Python packages in the >> common `pip install ` > > IMO

[Python-Dev] Better support for consuming vendored packages

I'd like to start a discussion around practices for vendoring package dependencies. I'm not sure python-dev is the appropriate venue for this discussion. If not, please point me to one and I'll gladly take it there. I'll start with a problem statement. Not all consumers of Python packages wish

[Python-Dev] Binary CPython distribution for Linux

I'm an advocate of getting users and projects to move to modern Python versions. I believe dropping support for end-of-lifed Python versions is important for the health of the Python community. If you've done any amount of Python 3 porting work, you know things get much harder the more 2.x

Re: [Python-Dev] python process creation overhead

On 5/12/2014 8:43 PM, Nick Coghlan wrote: On 13 May 2014 10:19, dw+python-...@hmmz.org wrote: On Mon, May 12, 2014 at 04:22:52PM -0700, Gregory Szorc wrote: Why can't Python start as quickly as Perl or Ruby? On my heavily abused Core 2 Macbook with 9 .pth files, 2.7 drops from 81ms

Re: [Python-Dev] python process creation overhead

On 5/10/2014 2:46 PM, Victor Stinner wrote: Le 10 mai 2014 22:51, Gregory Szorc gregory.sz...@gmail.com mailto:gregory.sz...@gmail.com a écrit : Furthermore, Python 3 appears to be 50% slower than Python 2. Please mention the minor version. It looks like you compared 2.7 and 3.3. Please

[Python-Dev] python process creation overhead

to mitigate or correct it. [1] http://www.selenic.com/pipermail/mercurial-devel/2014-May/058854.html Gregory Szorc gregory.sz...@gmail.com P.S. I'm not subscribed, so please CC me on responses. ___ Python-Dev mailing list Python-Dev@python.org https