On Thu, Feb 21, 2019 at 6:01 AM Armin Rigo wrote:
> Hi,
>
> On Tue, 19 Feb 2019 at 13:12, Victor Stinner wrote:
> > Please don't use _GET_ITEM() or _PyTuple_ITEMS(). It prevents
> > to use a more efficient storage for tuple. Something like:
> >
>
On 2019-02-21 12:53, Antoine Pitrou wrote:
On Thu, 21 Feb 2019 13:45:05 +0100
Victor Stinner wrote:
Le jeu. 21 févr. 2019 à 12:36, Antoine Pitrou a écrit :
>
> On Thu, 21 Feb 2019 12:13:51 +0100
> Victor Stinner wrote:
> >
> > Premature optimization is the root of all evil. Most C
Victor Stinner wrote:
> Premature optimization is the root of all evil. Most C extensions use
> premature optimization which are causing us a lot of troubles nowadays
> when we want to make the C API evolve and cause issues to PyPy which
> has issues to reimplement the C API on top of their
Just letting everyone know that I'm intending to restart this discussion
over in capi-sig, as I feel like I've got an informational-PEP worth of
"vision", "ideas" and "direction" and nomenclature for our C API (*not*
talking about a rewrite, but the principles we should be following
now... and
Hi,
On Tue, 19 Feb 2019 at 13:12, Victor Stinner wrote:
> Please don't use _GET_ITEM() or _PyTuple_ITEMS(). It prevents
> to use a more efficient storage for tuple. Something like:
> https://pythoncapi.readthedocs.io/optimization_ideas.html#specialized-list-for-small-integers
>
> PyPy already
On 2019-02-21 12:18, Victor Stinner wrote:
What I also would like to see is the creation of a group of people who
work on the C API to discuss each change and test these changes
properly.
I don't think that we should "discuss each change", we should first have
an overall plan. It doesn't make
On Thu, 21 Feb 2019 13:45:05 +0100
Victor Stinner wrote:
> Le jeu. 21 févr. 2019 à 12:36, Antoine Pitrou a écrit :
> >
> > On Thu, 21 Feb 2019 12:13:51 +0100
> > Victor Stinner wrote:
> > >
> > > Premature optimization is the root of all evil. Most C extensions use
> > > premature
On Thu, Feb 21, 2019 at 9:23 PM Paul Moore wrote:
>
> On Thu, 21 Feb 2019 at 12:12, Antoine Pitrou wrote:
>
> > Actually, it would be interesting to have some kind of survey of C
> > extensions (through random sampling? or popularity?) to find out why the
> > developers had to write a C
Le jeu. 21 févr. 2019 à 12:36, Antoine Pitrou a écrit :
>
> On Thu, 21 Feb 2019 12:13:51 +0100
> Victor Stinner wrote:
> >
> > Premature optimization is the root of all evil. Most C extensions use
> > premature optimization
>
> How do you know it's premature? Some extensions _are_ meant for
On Thu, 21 Feb 2019 at 12:12, Antoine Pitrou wrote:
> Actually, it would be interesting to have some kind of survey of C
> extensions (through random sampling? or popularity?) to find out why the
> developers had to write a C extension in the first place and what their
> concerns are.
Indeed.
Le 21/02/2019 à 12:58, Paul Moore a écrit :
> On Thu, 21 Feb 2019 at 11:35, Antoine Pitrou wrote:
>>
>> On Thu, 21 Feb 2019 12:13:51 +0100
>> Victor Stinner wrote:
>>>
>>> Premature optimization is the root of all evil. Most C extensions use
>>> premature optimization
>>
>> How do you know it's
On Thu, 21 Feb 2019 at 11:35, Antoine Pitrou wrote:
>
> On Thu, 21 Feb 2019 12:13:51 +0100
> Victor Stinner wrote:
> >
> > Premature optimization is the root of all evil. Most C extensions use
> > premature optimization
>
> How do you know it's premature? Some extensions _are_ meant for speed.
On 16/02/2019 23:34, Steve Dower wrote:
> I like that we're taking (small) steps to reduce the size of our API.
I consider myself - an "outsider", so an "outsider's" view is that
anything that makes it more clear about what is intended aka supported
as the Python API is an improvement.
Without
On Thu, 21 Feb 2019 12:13:51 +0100
Victor Stinner wrote:
>
> Premature optimization is the root of all evil. Most C extensions use
> premature optimization
How do you know it's premature? Some extensions _are_ meant for speed.
Regards
Antoine.
Hi Eric,
IMHO the main blocker issue for any C API change is that nobody is
able to measure the risk these changes. To better control the risk, I
propose to select a list of popular C extensions, and build a CI to
run their test suite on top of the development version of Python. Such
CI wouldn't
Le mar. 19 févr. 2019 à 21:15, Stefan Behnel a écrit :
> What I would ask, though, and I think that's also Jeroen's request, is to
> be careful what you lock up behind Py_BUILD_CORE. Any new functionality
> should be available to extension modules by default, unless there is a good
> reason why
On Tue, Feb 19, 2019 at 12:45 PM Steve Dower wrote:
> On 19Feb2019 1141, Barry Warsaw wrote:
> > Steve Dower wrote on 2/16/19 14:34:>
> >> This is mostly about being able to assign blame when things break, so
> >> I'm totally okay with extension modules that want to play with internals
> >>
Steve Dower schrieb am 19.02.19 um 21:40:
> On 19Feb2019 1212, Stefan Behnel wrote:
>> Then it's up to the users to decide
>> how much work they want to invest into keeping up with C-API changes vs.
>> potentially sub-optimal but stable C-API usage.
> [...]
> And it's not up to the users - it's up
On 19Feb2019 1141, Barry Warsaw wrote:
Steve Dower wrote on 2/16/19 14:34:>
This is mostly about being able to assign blame when things break, so
I'm totally okay with extension modules that want to play with internals
declaring Py_BUILD_CORE to get access to them (though I suspect that
won't
On 19Feb2019 1212, Stefan Behnel wrote:
So, yeah, I'm happy with the status quo, and a bit worried about all the
moving around of declarations and that scent of a sword of Damocles hanging
over their potential confinement. IMHO, things should just be public and
potentially marked as "unstable"
Nick Coghlan schrieb am 19.02.19 um 15:00:
> On Tue, 19 Feb 2019 at 20:41, Antoine Pitrou wrote:
>> On Mon, 18 Feb 2019 19:04:31 -0800 Steve Dower wrote:
>>> If you always rebuild your extension for every micro version (3.x.y) of
>>> CPython, then sure, go ahead and use this.
>>
>> Usually we
Steve Dower wrote on 2/16/19 14:34:>
This is mostly about being able to assign blame when things break, so
I'm totally okay with extension modules that want to play with internals
declaring Py_BUILD_CORE to get access to them (though I suspect that
won't work out of the box - maybe we should
On 19Feb2019 0555, Nick Coghlan wrote:
I really don't want us to ever get into a situation where we're
actively encouraging third party projects to define Py_BUILD_CORE.
If we decide we do want to go down a path like that, I'd instead
prefer to see us define something more like "Py_FRAGILE_API"
On 19Feb2019 0229, Jeroen Demeyer wrote:
On 2019-02-19 04:04, Steve Dower wrote:
On 18Feb.2019 1324, Jeroen Demeyer wrote:
For a very concrete example, was it really necessary to put
_PyTuple_ITEMS in (4)? That's used in _functoolsmodule.c. Especially
given that the very similar
On Tue, 19 Feb 2019 at 20:41, Antoine Pitrou wrote:
> On Mon, 18 Feb 2019 19:04:31 -0800
> Steve Dower wrote:
> > If you always rebuild your extension for every micro version (3.x.y) of
> > CPython, then sure, go ahead and use this.
>
> Usually we would guarantee that API details don't change in
On Tue, 19 Feb 2019 at 05:33, Eric Snow wrote:
>
> 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
Le mar. 19 févr. 2019 à 11:57, INADA Naoki a écrit :
> On the other hand, it makes sense to move _PyTuple_ITEMS to (3) or even (2).
> PyTuple_ITEMS(t) seems better than _GET_ITEM(t, 0).
Please don't use _GET_ITEM() or _PyTuple_ITEMS(). It prevents
to use a more efficient storage for tuple.
Le lun. 18 févr. 2019 à 22:34, Jeroen Demeyer a écrit :
> First of all, if everybody can actually #define Py_BUILD_CORE and get
> access to the complete API, I don't mind so much. But then it's
> important that this actually keeps working (i.e. that those headers will
> always be installed).
>
>
On Tue, Feb 19, 2019 at 7:32 PM Jeroen Demeyer wrote:
>
> On 2019-02-19 04:04, Steve Dower wrote:
> > On 18Feb.2019 1324, Jeroen Demeyer wrote:
> >> For a very concrete example, was it really necessary to put
> >> _PyTuple_ITEMS in (4)? That's used in _functoolsmodule.c. Especially
> >> given
On Mon, 18 Feb 2019 19:04:31 -0800
Steve Dower wrote:
>
> > I'm afraid of hiding actually useful private macros under Py_BUILD_CORE.
> > For example, Modules/_functoolsmodule.c and Modules/_json.c use API
> > functions from (4). But if an API function is useful for implementing
> > functools or
On 2019-02-19 04:04, Steve Dower wrote:
On 18Feb.2019 1324, Jeroen Demeyer wrote:
For a very concrete example, was it really necessary to put
_PyTuple_ITEMS in (4)? That's used in _functoolsmodule.c. Especially
given that the very similar PySequence_Fast_ITEMS is in (2), that seems
like a
On 2019-02-19 04:04, Steve Dower wrote:
Otherwise, the
internal memory layout becomes part of the public ABI
Of course, the ABI (not API) depends on the internal memory layout. Why
is this considered a problem? If you want a fixed ABI, use API level (1)
from my last post. If you want a fixed
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 16Feb.2019 1332, Antoine Pitrou wrote:
> On Sat, 16 Feb 2019 11:15:44 +0100
> 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
On Sat, 16 Feb 2019 11:15:44 +0100
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 don't like the idea (in general,
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 don't like the idea (in general, I'm not
talking about PyInterpreterState specifically) that external
Hi all,
I've been working on the runtime lately, particularly focused on my
multi-core Python project. One thing that would help simplify changes
in this area is if PyInterpreterState were defined in
Include/internal. This would mean the type would be opaque unless
Py_BUILD_CORE were defined.
41 matches
Mail list logo
