On Wed, Aug 1, 2018 at 1:16 PM, Jeffrey Zhang wrote:
> I found a interesting issue when checking the Lib/datetime.py implementation
> in python3
>
> This patch is introduced by cf86e368ebd17e10f68306ebad314eea31daaa1e [0].
> But if you
> check the github page[0], or using git tag --contains, you w
I found a interesting issue when checking the Lib/datetime.py
implementation in python3
This patch is introduced by cf86e368ebd17e10f68306ebad314eea31daaa1e [0].
But if you
check the github page[0], or using git tag --contains, you will find v2.7.x
includes this commit too.
$ git tag --contains c
On 30Jul2018 13:40, Bob Purvy wrote:
I've been trying to figure out how to access the archives programmatically.
I'm sure this is easy once you know, but googling various things hasn't
worked. What I want to do is graph the number of messages about PEP 572 by
time. (or has someone already done
Feel free to modify the script to make your own statistics ;-)
Victor
2018-08-01 0:57 GMT+02:00 Michael Selik :
> Would it be possible to normalize by the number of mailing list members and
> also by "active" members? The latter would be tricky to define.
>
> On Mon, Jul 30, 2018 at 3:29 PM Victo
Would it be possible to normalize by the number of mailing list members and
also by "active" members? The latter would be tricky to define.
On Mon, Jul 30, 2018 at 3:29 PM Victor Stinner wrote:
> Hi Bob,
>
> I wrote a basic script to compute the number of emails per PEP. It
> requires to downloa
Hi,
I finished my work on the _PyCoreConfig structure: it's a C structure
in Include/pystate.h which has many fields used to configure Python
initialization. In Python 3.6 and older, these parameters were scatted
around the code, and it was hard to get an exhaustive list of it.
This work is linke
Jeroen Demeyer schrieb am 31.07.2018 um 14:01:
> On 2018-07-31 12:56, Victor Stinner wrote:
>> I would be nice to be able to use something to "generate" C
>> extensions, maybe even from pure Python code.
>
> Cython has a "pure Python mode" which does exactly that. There are several
> ways to inclu
Antoine Pitrou schrieb am 31.07.2018 um 09:45:
> On Tue, 31 Jul 2018 09:27:03 +0200
> Jeroen Demeyer wrote:
>> On 2018-07-31 08:58, Antoine Pitrou wrote:
>>> I think Stefan is right that we
>>> should push people towards Cython and alternatives, rather than direct
>>> use of the C API (which peopl
On Tue, 31 Jul 2018 at 10:32 Antoine Pitrou wrote:
>
> Well, I tried to subscribe to capi-sig, but I didn't get a
> confirmation e-mail.
>
I subscribed yesterday without issue. I would email postmaster to try and
find out what happened.
-Brett
>
> Regards
>
> Antoine.
>
>
> On Tue, 31 Jul 201
Well, I tried to subscribe to capi-sig, but I didn't get a
confirmation e-mail.
Regards
Antoine.
On Tue, 31 Jul 2018 18:25:25 +0200
Victor Stinner wrote:
> I replied on capi-sig.
>
> 2018-07-31 18:03 GMT+02:00 Antoine Pitrou :
> > On Tue, 31 Jul 2018 15:34:05 +0200
> > Victor Stinner wrot
On Mon, Jul 30, 2018 at 5:26 PM Nick Coghlan wrote:
>
> On 26 July 2018 at 02:13, Erik Bray wrote:
> > I think a new approach that might be more practical for actually
> > getting this platform re-supported, is to go ahead and add a CI build,
> > and just skip all known failing test modules. Thi
I replied on capi-sig.
2018-07-31 18:03 GMT+02:00 Antoine Pitrou :
> On Tue, 31 Jul 2018 15:34:05 +0200
> Victor Stinner wrote:
>> Antoine: would you mind to subscribe to the capi-sig mailing list? As
>> expected, they are many interesting points discussed here, but I would
>> like to move all C
On Tue, Jul 31, 2018 at 7:35 AM Victor Stinner wrote:
> 2018-07-31 14:01 GMT+02:00 Jeroen Demeyer :
> > Anyway, I know that this is probably not going to happen, but I just wanted
> > to bring it up in case people would find it a great idea. But maybe not many
> > CPython core developers actually
On Tue, 31 Jul 2018 15:34:05 +0200
Victor Stinner wrote:
> Antoine: would you mind to subscribe to the capi-sig mailing list? As
> expected, they are many interesting points discussed here, but I would
> like to move all C API discussions to capi-sig. I only continue on
> python-dev since you star
On 2018-07-31 10:07, Jeroen Demeyer wrote:
On 2018-07-31 09:36, INADA Naoki wrote:
[snip]
I would like to stress that PEP 580 was designed for maximum
performance, both today and for future extensions (such as calling with
native C types).
I don't know what the word *stress* mean here. (Sor
On Tue, Jul 31, 2018 at 9:55 PM Jeroen Demeyer wrote:
>
> On 2018-07-31 12:10, INADA Naoki wrote:
> > Surely, they should understand they must use CCALL_* flags instead of
> > METH_* flags when implementing fast-callable object.
>
> Yes indeed. But implementing a fast-callable object is quite
> sp
On 2018-07-31 15:34, Victor Stinner wrote:
But I never used Cython nor cffi, so I'm not sure which one is the
most appropriate depending on the use case.
Cython is a build-time tool, while cffi is a run-time tool.
But Cython does a lot more than just FFI. It is a Python->C compiler
which can
On 2018-07-31 12:10, INADA Naoki wrote:
After spent several days to read PEP 580 and your implementation, I think
I can implement it. I think it's not easy, but it's not impossible too.
The signature of "extended_call_ptr" in PEP 576 is almost the same as
the signature of a CCALL_FUNCARG|CCAL
2018-07-31 14:01 GMT+02:00 Jeroen Demeyer :
> Anyway, I know that this is probably not going to happen, but I just wanted
> to bring it up in case people would find it a great idea. But maybe not many
> CPython core developers actually know and use Cython?
I know that Yury wants to use Cython for
Antoine: would you mind to subscribe to the capi-sig mailing list? As
expected, they are many interesting points discussed here, but I would
like to move all C API discussions to capi-sig. I only continue on
python-dev since you started here (and ignored my request to start
discussing my idea on ca
On 2018-07-31 12:10, INADA Naoki wrote:
Surely, they should understand they must use CCALL_* flags instead of
METH_* flags when implementing fast-callable object.
Yes indeed. But implementing a fast-callable object is quite
specialized, not something that ordinary extension writers would care
On 2018-07-31 12:56, Victor Stinner wrote:
We try to make CPython build as simple as possible. I'm quite sure
that Cython rely on the stdlib.
It does rely on modules like "re" and "functools".
Would depending on Cython open a
chicken-and-egg issue?
Yes, that's a problem but it's not unsolva
On Tue, 31 Jul 2018 12:51:23 +0200
Victor Stinner wrote:
> 2018-07-31 8:58 GMT+02:00 Antoine Pitrou :
> > What exactly in the C API made it slow or non-promising?
> >
> >> The C API requires that your implementations make almost all the same
> >> design choices that CPython made 25 years ago (C
2018-07-31 9:27 GMT+02:00 Jeroen Demeyer :
> On 2018-07-31 08:58, Antoine Pitrou wrote:
>>
>> I think Stefan is right that we
>> should push people towards Cython and alternatives, rather than direct
>> use of the C API (which people often fail to use correctly, in my
>> experience).
>
>
> I know t
2018-07-31 8:58 GMT+02:00 Antoine Pitrou :
> What exactly in the C API made it slow or non-promising?
>
>> The C API requires that your implementations make almost all the same
>> design choices that CPython made 25 years ago (C structures, memory
>> allocators, reference couting, specific GC imple
On Tue, Jul 31, 2018 at 7:27 PM Antoine Pitrou wrote:
>
> On Tue, 31 Jul 2018 19:10:48 +0900
> INADA Naoki wrote:
> >
> > I said "So PEP 576/580 are needed only when implementing callable object".
> > I showed example "functools.partial or functools.lru_cache".
> >
> > Using FASTCALL for callable
On Tue, 31 Jul 2018 19:10:48 +0900
INADA Naoki wrote:
>
> I said "So PEP 576/580 are needed only when implementing callable object".
> I showed example "functools.partial or functools.lru_cache".
>
> Using FASTCALL for callable object, instead of tp_call is one of important
> goal
> of PEP 576
On Tue, Jul 31, 2018 at 6:14 PM Jeroen Demeyer wrote:
>
> On 2018-07-31 09:36, INADA Naoki wrote:
> > I think PEP 580 is understandable only for people who tried to implement
> > method objects.
>
> Is this really a problem? Do we expect that all Python developers can
> understand all PEPs, especi
On 2018-07-31 11:12, INADA Naoki wrote:
For me, this is the most important benefit of PEP 580. I can't split
it from PEP 580.
I want PEP 580 to stand by itself. And you say that it is already
complicated enough, so we should not mix native C calling into it.
PEP 580 is written to allow futu
On Tue, Jul 31, 2018 at 5:46 PM Jeroen Demeyer wrote:
>
> On 2018-07-31 09:36, INADA Naoki wrote:
> > I want to see PoC of direct C calling.
>
> To be honest, there is no implementation plan for this yet. I know that
> several people want this feature, so it makes sense to think about it.
Yes. I
On 2018-07-31 09:36, INADA Naoki wrote:
I think PEP 580 is understandable only for people who tried to implement
method objects.
Is this really a problem? Do we expect that all Python developers can
understand all PEPs, especially on a technical subject like this?
To give a different example
On 2018-07-31 09:36, INADA Naoki wrote:
I want to see PoC of direct C calling.
To be honest, there is no implementation plan for this yet. I know that
several people want this feature, so it makes sense to think about it.
For me personally, the main open problem is how to deal with arguments
On Tue, 31 Jul 2018 09:27:03 +0200
Jeroen Demeyer wrote:
> On 2018-07-31 08:58, Antoine Pitrou wrote:
> > I think Stefan is right that we
> > should push people towards Cython and alternatives, rather than direct
> > use of the C API (which people often fail to use correctly, in my
> > experience)
First of all, I'm sorry to I forgot change my mail title.
(I though about reserving one more slot for Cython for
further Cython-to-Cython call optimization, but I rejected
my idea because I'm not sure it really help Cython.)
On Mon, Jul 30, 2018 at 11:55 PM Jeroen Demeyer wrote:
>
> On 2018-07-
On 2018-07-31 08:58, Antoine Pitrou wrote:
I think Stefan is right that we
should push people towards Cython and alternatives, rather than direct
use of the C API (which people often fail to use correctly, in my
experience).
I know this probably isn't the correct place to bring it up, but I'm
On Tue, 31 Jul 2018 02:29:42 +0200
Victor Stinner wrote:
> >> Last year, I gave a talk at the Language Summit (during Pycon) to
> >> explain that CPython should become 2x faster to remain competitive.
> >> IMHO all attempts to optimize Python (CPython forks) have failed
> >> because they have been
36 matches
Mail list logo
