[Python-Dev] Can we use "designated initializer" widely in coremodules?

[Steve Dower]

Avoiding header files would be my only request. As Brett says, the C99 requirement should not be enforced on all embedders or extenders, so we should try and keep the headers they'll use as compatible as possible.

Cheers,
Steve

Top-posted from my Windows Phone

-----Original Message-----
From: "Brett Cannon" <brett at python.org>
Sent: ‎1/‎17/‎2017 8:58
To: "INADA Naoki" <songofacandy at gmail.com>; "Python-Dev" <python-dev at python.org>
Subject: Re: [Python-Dev] Can we use "designated initializer" widely in coremodules?




On Mon, 16 Jan 2017 at 22:34 INADA Naoki <songofacandy at gmail.com> wrote:

Hi.

---
This discussion is started in http://bugs.python.org/issue29259, and
there is separated issue at http://bugs.python.org/issue29260 .
But I want to see more comments, before issue 29259 is committed.
---

Since Python 3.6, some of C99 features are accepted in PEP 7.
"designated initializer" is one of them.

PEP7 says  "designated initializers (especially nice for type declarations)"

For example, issue 29259 is adding new slot named tp_fastcall in type structure.
Without designated initializer, there are many diffs like this:

     0,                                  /* tp_free */
+    0,                                  /* tp_is_gc */
+    0,                                  /* tp_bases */
+    0,                                  /* tp_mro */
+    0,                                  /* tp_cache */
+    0,                                  /* tp_subclasses */
+    0,                                  /* tp_weaklist */
+    0,                                  /* tp_del */
+    0,                                  /* tp_version_tag */
+    0,                                  /* tp_finalize */
+    (fastternaryfunc)attrgetter_call,   /* tp_fastcall */
 };

With designated initializer, it becomes:

     0,                                  /* tp_free */
+    .tp_fastcall = (fastternaryfunc)attrgetter_call,
 };

It's readable, and easy to review.
Without designated initializer, it's difficult to find copy & paste mistake.
(Can you find if I missed /* tp_is_gc */ line in first patch?)

On the other hand, this syntax is C99 specific.
C++ doesn't accept this syntax, even for newest C++14.
Using this feature make it's difficult to use (subset of) C++ features
in the future.



At this point I really doubt we will ever switch to C++ so I don't think making any such theoretical transition is worth holding back cleaner code. Plus if this isn't going into a header file that some C++ extension module is going to be pulling in then third-party C++ code should be shielded from the incompatibility.
 


So, how widely can we use "designated initializer"?
Only in Modules (_asyncio uses it already)?
Or almost everywhere (Objects/ and Python/)?



I say everywhere we can (and that also means we should probably update the xx* files in Modules/).


-Brett
 

I want to get decision before issue 29259 is committed, because it
will add many "0, /* tp_xxx */"

Regards,
_______________________________________________
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/20170117/779c4633/attachment.html>