Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

2018-11-20 Thread Glenn Linderman
On 11/20/2018 10:33 PM, Nathaniel Smith wrote: On Tue, Nov 20, 2018 at 6:05 PM Glenn Linderman wrote: On 11/20/2018 2:17 PM, Victor Stinner wrote: IMHO performance and hiding implementation details are exclusive. You should either use the C API with impl. details for best performances, or use

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

2018-11-20 Thread Nathaniel Smith
On Tue, Nov 20, 2018 at 6:05 PM Glenn Linderman wrote: > > On 11/20/2018 2:17 PM, Victor Stinner wrote: >> IMHO performance and hiding implementation details are exclusive. You >> should either use the C API with impl. details for best performances, >> or use a "limited" C API for best

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

2018-11-20 Thread Glenn Linderman
On 11/20/2018 2:17 PM, Victor Stinner wrote: Le mar. 20 nov. 2018 à 23:08, Stefan Krah a écrit : Intuitively, it should probably not be part of a limited API, but I never quite understood the purpose of this API, because I regularly need any function that I can get my hands on. (...) Reading

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

2018-11-20 Thread Victor Stinner
Le mar. 20 nov. 2018 à 23:08, Stefan Krah a écrit : > Intuitively, it should probably not be part of a limited API, but I never > quite understood the purpose of this API, because I regularly need any > function that I can get my hands on. > (...) > Reading typed strings directly into an array

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

2018-11-20 Thread Stefan Krah
On Mon, Nov 19, 2018 at 04:08:07PM +0100, Victor Stinner wrote: > Le lun. 19 nov. 2018 à 13:18, Stefan Krah a écrit : > > In practice people desperately *have* to use whatever is there, including > > functions with underscores that are not even officially in the C-API. > > > > I have to use

Re: [Python-Dev] bpo-34532 status

2018-11-20 Thread Steve Dower
It's merged now. Sorry for not seeing the update (I get far too many github notifications/emails to be able to pay attention to them - pinging on the issue tracker generally works best). Cheers, Steve On 20Nov2018 1002, Brett Cannon wrote: To provide context,

Re: [Python-Dev] bpo-34532 status

2018-11-20 Thread Brett Cannon
To provide context, https://bugs.python.org/issue34532 is about making the Python launcher on Windows not return an error condition when using `py -0` (and probably `py --list` and `py --list-paths`). On Tue, 20 Nov 2018 at 08:29, Brendan Gerrity wrote: > Just wanted to check on

[Python-Dev] bpo-34532 status

2018-11-20 Thread Brendan Gerrity
Just wanted to check on bpo-34532/pr#9039. The requested changes were submitted as a commit to the PR. Best, Brendan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

2018-11-20 Thread Nathaniel Smith
On Tue, Nov 20, 2018 at 1:34 AM Petr Viktorin wrote: > > On 11/19/18 12:14 PM, Victor Stinner wrote: > > To design a new C API, I see 3 options: > > > > (1) add more functions to the existing Py_LIMITED_API > > (2) "fork" the current public C API: remove functions and hide as much > >

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

2018-11-20 Thread Petr Viktorin
On 11/19/18 12:14 PM, Victor Stinner wrote: To design a new C API, I see 3 options: (1) add more functions to the existing Py_LIMITED_API (2) "fork" the current public C API: remove functions and hide as much implementation details as possible (3) write a new C API from scratch, based on the

Re: [Python-Dev] Need discussion for a PR about memory and objects

2018-11-20 Thread Jeff Allen
On 20/11/2018 00:14, Chris Barker via Python-Dev wrote: On Mon, Nov 19, 2018 at 1:41 AM Antoine Pitrou > wrote: I'd rather keep the reference to memory addressing than start doing car analogies in the reference documentation. I agree -- and any of the