On 2018-07-08 23:13, Mark Shannon wrote:
I've added you suggestion, and everyone else's, to this github repo:
https://github.com/markshannon/extended-calling-convention
Feel free to comment on github, submit PRs or just email me directly if
you have anything else you want to add.
Do you agree
On 07/07/18 22:11, Jeroen Demeyer wrote:
On 2018-07-07 15:38, Mark Shannon wrote:
Hi,
We seem to have a plethora of PEPs where we really ought to have one (or
none?).
- PEP 575 has been withdrawn.
- PEP 579 is an informational PEP with the bigger picture; it does
contain some of the
On Sat, Jul 7, 2018 at 6:38 AM, Mark Shannon wrote:
> 1. The new API should be fully backwards compatible and shouldn't break the
> ABI
Which ABI? The stable ABI (PEP 384)? I don't think object layout is
exposed there, though I'm not sure of the details.
The regular ABI that almost everyone
On Sat, Jul 7, 2018, 08:17 INADA Naoki, wrote:
> > IMO, mailing lists are a terrible way to do software design, but a good
> > way to gather requirements as it makes less likely that someone will be
> > forgotten.
> >
>
> Agreed. There are several topics we should discuss for these PEPs.
>
On 2018-07-07 15:38, Mark Shannon wrote:
Hi,
We seem to have a plethora of PEPs where we really ought to have one (or
none?).
- PEP 575 has been withdrawn.
- PEP 579 is an informational PEP with the bigger picture; it does
contain some of the requirements that you want to discuss here.
- PEP
> > > 5. It should speed up CPython for the standard benchmark suite.
...
> >
> > I don't think point 5 is a goal here either, as the problem isn't that
> > these calling optimisations don't exist, it's that they don't
> > currently have a public API that third party projects can access (the
> >
INADA Naoki schrieb am 07.07.2018 um 17:16:
>> 2. The new API should be used internally so that 3rd party extensions
>> are not second class citizens in term of call performance.
>
> These PEPs proposes new public protocol which can be implemented
> by 3rd party extensions, especially Cython.
>
> IMO, mailing lists are a terrible way to do software design, but a good
> way to gather requirements as it makes less likely that someone will be
> forgotten.
>
Agreed. There are several topics we should discuss for these PEPs.
Mailing list is hard to follow.
Can we have other communication
On Sat, 7 Jul 2018 16:39:08 +0200
Stefan Behnel wrote:
> Nick Coghlan schrieb am 07.07.2018 um 16:14:
> > when the new calling
> > convention is tied to a protocol that any type can implement (as PEP
> > 580 proposes), the concern doesn't even arise.
>
> Nick, +1 to all of what you said in
On Sun, 8 Jul 2018 00:14:13 +1000
Nick Coghlan wrote:
>
> > So, let us gather the requirements for a new calling API.
>
> > Here are my starting suggestions:
> >
> > 1. The new API should be fully backwards compatible and shouldn't break the
> > ABI
> > 2. The new API should be used
Nick Coghlan schrieb am 07.07.2018 um 16:14:
> when the new calling
> convention is tied to a protocol that any type can implement (as PEP
> 580 proposes), the concern doesn't even arise.
Nick, +1 to all of what you said in your reply, and I also really like the
fact that this proposal is
On 7 July 2018 at 23:38, Mark Shannon wrote:
> Hi,
>
> We seem to have a plethora of PEPs where we really ought to have one (or
> none?).
>
> Traditionally when writing a new piece of software, one gathered
> requirements before implementing the code. Let us return to that venerable
> tradition.
12 matches
Mail list logo
