[Python-Dev] Can we use "designated initializer" widely in core modules?
Guido van Rossum
guido at python.org
Tue Jan 17 21:28:30 EST 2017
I'm for allowing the new convention. If it had been supported 20 years ago
I would've used it.
I'm against changing any existing code to use it -- such massive changes
are high risk and low reward. Just do it for new fields or new types.
I recommend being reluctant to add new fields -- the number of type objects
is larger than you'd think and these are static bytes which I consider a
relatively expensive resource.
There's also an ABI issue with new fields -- new fields can only be
accessed after checking that the type object has been compiled with a
version of the headers that defines the field, else you'd be accessing
On Tue, Jan 17, 2017 at 5:52 PM, Raymond Hettinger <
raymond.hettinger at gmail.com> wrote:
> > On Jan 17, 2017, at 5:16 PM, Victor Stinner <victor.stinner at gmail.com>
> > /* tp_xxx */" lines and make the code much more
> > readable! It should help to prevent bugs when the code is modified.
> I'm +0 on the change (it is a massive code churn with a huge diff and
> won't match any existing C extensions or published books on Python) but it
> does have advantages in the face of all the new tp slots being proposed
> which would be painful regardless.
> I don't want to pretend that it really prevents bugs though.
> Historically, this just hasn't been a problem for us in practice (I've
> written and reviewed many, many of these structs over the years). In fact,
> the change may become a source of bugs as people forget to fill-in slots or
> lose their cues as to what slots are available (I for one use the current
> copy and paste as a checklist for what should and shouldn't be included).
> I would really like to hear Guido's opinion on the subject (IIRC he
> designed the current system of slots and has had to live with its pros and
> cons over a long period time). Also at one time, Guido opined that he was
> somewhat resistant to adding new slots (otherwise, we would already have a
> __length_hint__ slot which I proposed a few years ago).
> Lastly, if we do go forward with this sweeping change, we should also
> explore the possibility of flattening the current tp_as_sequence,
> tp_as_mapping, and tp_as_number indirections. These have historically have
> been somewhat of a pain and have led to many otherwise unnecessary
> P.S. I'm not sure if we care about the size of the types but they are
> growing at an unprecedented rate (amidst lots of other code churn as well).
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev