On 18Feb.2019 1324, Jeroen Demeyer wrote:
> Still, do we really need so many levels of API:
> (1) stable API (with #define Py_LIMITED_API)
> (2) public documented API
> (3) private undocumented API (the default exposed API)
> (4) internal API (with #define Py_BUILD_CORE)
>
> I would argue to fold
On 2019-02-18 21:17, Eric Snow wrote:
Historically our approach to keeping API private was to use underscore
prefixes and to leave them out of the documentation (along with
guarding with "#ifndef Py_LIMITED_API"). However, this has lead to
occasional confusion and breakage, and even to leaking
On Sat, Feb 16, 2019 at 3:16 AM Jeroen Demeyer wrote:
> On 2019-02-16 00:37, Eric Snow wrote:
> > One thing that would help simplify changes
> > in this area is if PyInterpreterState were defined in
> > Include/internal.
>
> How would that help anything?
I'm talking just about changes in the
On Sat, Feb 16, 2019 at 3:47 PM Antoine Pitrou wrote:
> On Sat, 16 Feb 2019 14:34:46 -0800
> Steve Dower wrote:
> > Which seems to suggest that the answer to "which members are important
> > to expose?" is "probably none".
>
> That sounds intuitive. But we don't know what kind of hacks some
>
On Sat, Feb 16, 2019 at 3:34 PM Steve Dower wrote:
> On 16Feb.2019 1332, Antoine Pitrou wrote:
> > This sounds like a reasonable design principle: decree the API
> > non-stable and prone to breakage (it already is, anyway), don't hide it.
>
> As I was chatting with Eric shortly before he posted
On Mon, Feb 18, 2019, 7:34 AM Matthias Klose On 16.02.19 00:15, Gregory P. Smith wrote:
> > On Thu, Feb 14, 2019 at 9:29 AM Barry Warsaw wrote:
> >
> >> On Feb 13, 2019, at 23:08, Matěj Cepl wrote:
> >>
> >>> Is this relevant to the discussion at hand? We are talking about
> >>> the binary
Hi, I open this thread to discuss the proposal by Nick Coghlan in
https://bugs.python.org/issue33039
to add __int__ and __trunc__ to a type when __index__ is defined.
Currently __int__ does not default to __index__ during class initialisation
so
both must be defined to get a coherant behavior:
On 16.02.19 18:25, Nick Coghlan wrote:
> While Matthias is still personally reluctant to add the alias for
> Debian/Ubuntu, the *only* thing preventing aliasing /usr/bin/python to
> /usr/bin/python3 right now on the Fedora & RHEL side of things is PEP
> 394, and Guido objected strongly when Petr
On 16.02.19 00:15, Gregory P. Smith wrote:
> On Thu, Feb 14, 2019 at 9:29 AM Barry Warsaw wrote:
>
>> On Feb 13, 2019, at 23:08, Matěj Cepl wrote:
>>
>>> Is this relevant to the discussion at hand? We are talking about
>>> the binary /usr/bin/python3 which will be surely be provided
>>> even by
