On Thu, Mar 3, 2016, 16:43 Victor Stinner wrote:
> Why starting many discussions on the private python-committers mailing
> list? Why not discussing libffi on python-dev?
>
Because they are offshoots of your email to python-committers about the C
API and no one changed the to: field.
> Victor
2016-03-03 18:39 GMT+01:00 Brett Cannon :
> But I do think the spirit of Victor's idea is worth considering.
Oh, another note about such theorical API. For CPython, it would be
nice to experiment to implement such new API *on top* of the existing
Python C API. And it should be a third party projec
Why starting many discussions on the private python-committers mailing
list? Why not discussing libffi on python-dev?
Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code o
On Thu, Mar 3, 2016 at 12:38 PM, Brett Cannon wrote:
> [...] the maintenance issue we have with ctypes (or at least that's
> my hang-up with it). I think we still have not figured out what code we have
> patched and so no one has been willing to update to a newer version of
> libffi. I think Zacha
On Thu, 3 Mar 2016 at 10:40 Antoine Pitrou wrote:
>
> Le 03/03/2016 19:38, Brett Cannon a écrit :
> >
> > Ignoring the potential to crash the interpreter (I personally don't care
> > but some do), is the maintenance issue we have with ctypes (or at least
> > that's my hang-up with it). I think we
Le 03/03/2016 19:38, Brett Cannon a écrit :
>
> Ignoring the potential to crash the interpreter (I personally don't care
> but some do), is the maintenance issue we have with ctypes (or at least
> that's my hang-up with it). I think we still have not figured out what
> code we have patched and so
On Thu, 3 Mar 2016 at 10:04 Antoine Pitrou wrote:
>
> Le 03/03/2016 18:58, Eric Snow a écrit :
> >> It is doing fine as an external library, but if something as radical as
> >> heavily trimming back and/or rewriting the C API occurs then having
> CFFI in
> >> the stdlib to evolve with the interna
Le 03/03/2016 18:58, Eric Snow a écrit :
>> It is doing fine as an external library, but if something as radical as
>> heavily trimming back and/or rewriting the C API occurs then having CFFI in
>> the stdlib to evolve with the internal C changes makes sense. I think that's
>> where the thought of
On Thu, Mar 3, 2016 at 10:39 AM, Brett Cannon wrote:
> But I do think the spirit of Victor's idea is worth considering.
+1
> ...what would we need to do to our C API to make
> it so that anyone following a new API wouldn't be broken if we dropped the
> GIL?
If I recall correctly, this was one k
On Thu, 3 Mar 2016 at 06:31 Antoine Pitrou wrote:
>
> Le 03/03/2016 13:40, Nick Coghlan a écrit :
> >>
> >> I would be nice to discuss how to move to a new C API which doesn't
> >> expose implementation details and discuss if libraries will move to it
> >> or not. Implementation "details": GIL, r
On Thu, 3 Mar 2016 at 06:26 Victor Stinner wrote:
> 2016-03-03 13:40 GMT+01:00 Nick Coghlan :
> > Adding cffi (including its dependencies) to the standard library was
> > approved-in-principle a couple of years ago, and I believe the one
> > technical issue with a lack of support for ahead-of-tim
Le 03/03/2016 13:40, Nick Coghlan a écrit :
>>
>> I would be nice to discuss how to move to a new C API which doesn't
>> expose implementation details and discuss if libraries will move to it
>> or not. Implementation "details": GIL, reference counting, C
>> structures like PyObject, etc.
>
> Add
2016-03-03 13:40 GMT+01:00 Nick Coghlan :
> Adding cffi (including its dependencies) to the standard library was
> approved-in-principle a couple of years ago, and I believe the one
> technical issue with a lack of support for ahead-of-time compilation
> of the extension module has since been addre
On 3 March 2016 at 21:26, Victor Stinner wrote:
> 2016-03-02 2:01 GMT+01:00 Larry Hastings :
>> The purpose of the event is to disseminate information and spark
>> conversation among Python core developers. It's our once-a-year chance to
>> get together and hash out where we're going and what we'
2016-03-02 2:01 GMT+01:00 Larry Hastings :
> The purpose of the event is to disseminate information and spark
> conversation among Python core developers. It's our once-a-year chance to
> get together and hash out where we're going and what we're doing,
> face-to-face.
Sadly, I don't plan to atte
On 2016-03-03 08:45, Nick Coghlan wrote:
> On 2 March 2016 at 11:01, Larry Hastings wrote:
>> It's that time once again: time to start planning for the 2016 Python
>> Language Summit!
>
> Huzzah, thanks for organising this again!
>
> I've forwarded the email to a few folks to suggest they submit
16 matches
Mail list logo
