On Sun, Jul 23, 2017 at 5:57 AM, Victor Stinner
wrote:
> We already did that. See _bootlocale for example. (Maybe also
> _collecctions_abc?)
I was asking more in the context of recommended practices for
third-party developers, as Nick mentioned earlier, because it's not
We already did that. See _bootlocale for example. (Maybe also
_collecctions_abc?)
Victor
Le 22 juil. 2017 07:20, "Chris Jerdonek" a
écrit :
> On Fri, Jul 21, 2017 at 9:52 AM, Brett Cannon wrote:
> > On Thu, 20 Jul 2017 at 22:11 Chris Jerdonek
On Fri, Jul 21, 2017 at 9:52 AM, Brett Cannon wrote:
> On Thu, 20 Jul 2017 at 22:11 Chris Jerdonek
> wrote:
>> On Thu, Jul 20, 2017 at 8:49 PM, Nick Coghlan wrote:
>> > ...
>> > * Lazy loading can have a significant impact on
On 07/21/2017 03:28 PM, Barry Warsaw wrote:
The TPI (Terrible Python Idea) I had at Pycon was some kind of (local)
memcached of imported Python modules, which would theoretically allow avoiding
loading the modules from the file system on start up.
There would be all kinds of problems with this
On Jul 20, 2017, at 03:16 PM, Eric Snow wrote:
>Relatedly, at PyCon this year Barry and I were talking about the idea of
>bootstrapping the interpreter from a memory snapshot on disk, rather than
>from scatch (thus drastically reducing the number of IO events).
The TPI (Terrible Python Idea) I
On Thu, 20 Jul 2017 at 22:11 Chris Jerdonek
wrote:
> On Thu, Jul 20, 2017 at 8:49 PM, Nick Coghlan wrote:
> > ...
> > * Lazy loading can have a significant impact on startup time, as it
> > means you don't have to pay for the cost of finding and
On Thu, Jul 20, 2017 at 8:49 PM, Nick Coghlan wrote:
> ...
> * Lazy loading can have a significant impact on startup time, as it
> means you don't have to pay for the cost of finding and loading
> modules that you don't actually end up using on that particular run
>
> We've
On Fri, Jul 21, 2017 at 2:09 PM, Nick Coghlan wrote:
> On 21 July 2017 at 13:55, Chris Angelico wrote:
>> On Fri, Jul 21, 2017 at 1:49 PM, Nick Coghlan wrote:
>>> The are some genuine downsides in increasing the complexity of
>>>
On 21 July 2017 at 13:55, Chris Angelico wrote:
> On Fri, Jul 21, 2017 at 1:49 PM, Nick Coghlan wrote:
>> The are some genuine downsides in increasing the complexity of
>> bootstrapping CPython when all you're starting with is a VCS clone and
>> a C
On Fri, Jul 21, 2017 at 1:49 PM, Nick Coghlan wrote:
> The are some genuine downsides in increasing the complexity of
> bootstrapping CPython when all you're starting with is a VCS clone and
> a C compiler, but those complications are ultimately no worse than
> those we
On 21 July 2017 at 10:19, Nathaniel Smith wrote:
> I'm not sure either of these make much sense when python startup is already
> in the single digit milliseconds. While it's certainly great if we can lower
> that further, my impression is that for any real application, startup
On Thu, Jul 20, 2017 at 10:56 AM Jim J. Jewett wrote:
> I agree that startup time is a problem, but I wonder if some of the pain
> could be mitigated by using a persistent process.
>
This is one strategy that works under some situations, but not all.
There are downsides
On Jul 20, 2017 14:18, "Eric Snow" wrote:
On Thu, Jul 20, 2017 at 11:53 AM, Jim J. Jewett
wrote:
> I agree that startup time is a problem, but I wonder if some of the pain
> could be mitigated by using a persistent process.
>
> [snip]
>
> Is it
On Thu, Jul 20, 2017 at 11:53 AM, Jim J. Jewett wrote:
> I agree that startup time is a problem, but I wonder if some of the pain
> could be mitigated by using a persistent process.
>
> [snip]
>
> Is it too hard to create a daemon server?
> Is the communication and context
On 20 July 2017 at 18:53, Jim J. Jewett wrote:
> Is it too hard to create a daemon server?
> Is the communication and context switch slower than a new startup?
> Is the pattern just not well-enough advertised?
Managing a daemon (including things like stopping it when it's
On Thu, Jul 20, 2017 at 01:53:52PM -0400, "Jim J. Jewett"
wrote:
> I agree that startup time is a problem, but I wonder if some of the pain
> could be mitigated by using a persistent process.
>
> For example, in
>
I agree that startup time is a problem, but I wonder if some of the pain
could be mitigated by using a persistent process.
For example, in
https://mail.python.org/pipermail/python-dev/2017-July/148664.html Ben Hoyt
mentions that the Google Cloud SDK (CLI) team has found it "especially
problematic
17 matches
Mail list logo