[Python-Dev] PEP 575, 576, 579 and 580

Brett Cannon brett at python.org
Sat Jul 7 20:55:56 EDT 2018


On Sat, Jul 7, 2018, 08:17 INADA Naoki, <songofacandy at gmail.com> 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.
> Mailing list is hard to follow.
>
> Can we have other communication channel?  Dedicated Github repository?
> zulip? or discuss.python.org?
>
> > 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
>
> Agreed.  We have chance to break ABI/API slightly at Python 4, although
> breakage should be very small compared with Python 3.
>
> Until then, we should keep backward compatibility as possible.
>
> > 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.
> In this meaning, it's not used only *internally*.
>
> > 3. The new API should not prevent 3rd party extensions having full
> > introspection capabilities, supporting keyword arguments or another
> > feature supported by Python functions.
>
> OK.
>
> > 4. The implementation should not exceed D lines of code delta and T
> > lines of code in total size. I would suggest +200 and 1000 for D and T
> > respectively (or is that too restrictive?).
>
> Hmm, I think this should be considered as (Frequency * Value) /
> (Complexity).
> Especially, if PEP 580 can removes 2000 lines of code, T>1000 seems OK.
>

I don't think any concrete number is really going to be helpful. This is
probably going to come down to subjective "will this be complicated and
hard to maintain?" And that call will probably come down to the BDFL for
the PEP.

-Brett 0p


> > 5. It should speed up CPython for the standard benchmark suite.
>
> I think it's impossible in short term.  We have specialized optimization
> (FASTCALL and LOAD_METHOD/CALL_METHOD) already.
> These optimization makes simple method calls 30% faster.
> These PEPs makes 3rd party callable types can utilize these optimization.
>
> > 6. It should be understandable.
> >
>
> OK.
> While main audience is Cython, C extension writer should be able to use
> new protocols by handwritten extension.
>
> > What am I missing? Comments from the maintainers of Cython and other
> > similar tools would be appreciated.
> >
> > Cheers,
> > Mark.
>
>
> --
> INADA Naoki  <songofacandy at gmail.com>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180707/de52b2b6/attachment.html>


More information about the Python-Dev mailing list