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" <br...@python.org>
Sent: 1/17/2017 8:58
To: "INADA Naoki" <songofaca...@gmail.com>; "Python-Dev" <python-dev@python.org>
Subject: Re: [Python-Dev] Can we use "designated initializer" widely in
coremodules?
On Mon, 16 Jan 2017 at 22:34 INADA Naoki <songofaca...@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@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/brett%40python.org_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
