On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer wrote:
> On 2018-06-18 16:55, INADA Naoki wrote:
> > Speeding up most python function and some bultin functions was very
> > significant.
> > But I doubt making some 3rd party call 20% faster can make real
> > applications significant faster.
>
> The
On 2018-06-18 16:55, INADA Naoki wrote:
Speeding up most python function and some bultin functions was very
significant.
But I doubt making some 3rd party call 20% faster can make real
applications significant faster.
These two sentences are almost contradictory. I find it strange to claim
tha
On 06/08/2018 12:48 AM, Victor Stinner wrote:
Question: Do you think that bugs spotted by a GC collection are common
enough to change the GC thresholds in development mode (new -X dev
flag of Python 3.7)?
I'd prefer that the development / debug environment be as much like
production use as p
Victor Stinner schrieb am 18.06.2018 um 15:09:
> I tried two options to add support for FASTCALL on calling an object:
> add a flag in tp_flags and reuse tp_call, or add a new tp_fastcall
> slot. I failed to implement correctly any of these two options.
>
> There are multiple issues with tp_fastca
Hola python-dev,
Here is some more coverage from the Python Language Summit. As usual,
I am posting SubscriberLinks for articles that are still behind the
paywall. LWN subscribers can always see our content right away; one
week after they are published in a weekly edition, they become freely
a
Like Inada-san, I would like to see the implementation first.
On Mon, Jun 18, 2018, 07:33 Jeroen Demeyer wrote:
> On 2018-06-18 15:09, Victor Stinner wrote:
> > 2) we implemented a lot of other optimizations which made calls faster
> > without having to touch tp_call nor tp_fastcall.
>
> And tha
On Mon, Jun 18, 2018 at 11:33 PM Jeroen Demeyer wrote:
> On 2018-06-18 15:09, Victor Stinner wrote:
> > 2) we implemented a lot of other optimizations which made calls faster
> > without having to touch tp_call nor tp_fastcall.
>
> And that's a problem because these optimizations typically only w
On 2018-06-18 15:09, Victor Stinner wrote:
2) we implemented a lot of other optimizations which made calls faster
without having to touch tp_call nor tp_fastcall.
And that's a problem because these optimizations typically only work for
specific classes. My PEP wants to replace those by somethi
On 06/18/18 15:13, Ethan Furman wrote:
I'm sure we've already had this conversation, but my google-fu is
failing me.
Can someone provide a link to a discussion explaining why the new
ordering of dictionaries does not defeat the hash-randomization
non-ordering we added a few versions ago?
Hi
On Mon, 18 Jun 2018 06:13:15 -0700
Ethan Furman wrote:
> I'm sure we've already had this conversation, but my google-fu is failing me.
>
> Can someone provide a link to a discussion explaining why the new ordering of
> dictionaries does not defeat the
> hash-randomization non-ordering we added
Hi,
I tried two options to add support for FASTCALL on calling an object:
add a flag in tp_flags and reuse tp_call, or add a new tp_fastcall
slot. I failed to implement correctly any of these two options.
There are multiple issues with tp_fastcall:
* ABI issue: it's possible to load a C extensio
I'm sure we've already had this conversation, but my google-fu is failing me.
Can someone provide a link to a discussion explaining why the new ordering of dictionaries does not defeat the
hash-randomization non-ordering we added a few versions ago?
--
~Ethan~
_
12 matches
Mail list logo
