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 in
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 wit
ted 11.0 out of necessity.
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
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
>
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:
'XXX
zer with an eye
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 PyOxid
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
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 PyConfig_STATIC_I
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 the
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
On Wed, May 2, 2018 at 8:26 PM, Benjamin Peterson
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) that will use an embedded Pytho
On 5/2/18 2:24 PM, Barry Warsaw wrote:
> On May 2, 2018, at 09:42, Gregory Szorc 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 separate
>> files on the files
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 library. I'll definitely
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 slower...
On 3/22/2018 10:48 AM, Oleg Broytman wrote:
> Hi!
>
> On Thu, Mar 22, 2018 at 09:58:07AM -0700, Gregory Szorc
> wrote:
>> Not all consumers of Python packages wish to consume Python packages in the
>> common `pip install `
>
> IMO `pip` is for developers. To p
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 t
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 lega
On 5/12/2014 8:43 PM, Nick Coghlan wrote:
> On 13 May 2014 10:19, 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
On 5/10/2014 2:46 PM, Victor Stinner wrote:
> Le 10 mai 2014 22:51, "Gregory Szorc" <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 compar
a problem and what steps can
be taken 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-D
20 matches
Mail list logo
