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

[Guido van Rossum]

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
garbage bytes.

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>
> wrote:
> >
> >  /* 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
> indirections.
>
>
>
> Raymond
>
>
> 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
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170117/52070b7a/attachment.html>