[Python-Dev] Can we use "designated initializer" widely in core modules?
INADA Naoki
songofacandy at gmail.com
Tue Jan 17 19:59:20 EST 2017
More information about the Python-Dev mailing list
Tue Jan 17 19:59:20 EST 2017
- Previous message (by thread): [Python-Dev] Can we use "designated initializer" widely in core modules?
- Next message (by thread): [Python-Dev] Can we use "designated initializer" widely in core modules?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Jan 18, 2017 at 9:00 AM, Erik <python at lucidity.plus.com> wrote: > On 17/01/17 06:32, INADA Naoki wrote: >> >> With designated initializer, it becomes: >> >> 0, /* tp_free */ >> + .tp_fastcall = (fastternaryfunc)attrgetter_call, >> }; >> >> It's readable, and easy to review. > > > FWIW, I dislike mixing the two forms (because it still prevents the > structure layout changing - or introduces bugs if it does - though I guess > in Python's case that's not likely to happen). > > PEP 7 doesn't mention anything about this and I doubt a wholesale conversion > effort to the C99 syntax would be desirable, but perhaps a recommendation > that if a new initializer is being added then the whole expression should be > changed to the C99 syntax is reasonable. > > Regards, E. > I think mixing two forms is OK only if new form is used only at bottom. (like keyword arguments are allowed after all positional arguments in Python function calling) Complete rewriting makes diff huge. And there is PyVarObject_HEAD_INIT already.
- Previous message (by thread): [Python-Dev] Can we use "designated initializer" widely in core modules?
- Next message (by thread): [Python-Dev] Can we use "designated initializer" widely in core modules?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list