<div dir="ltr"><div><div>I'm for allowing the new convention. If it had been supported 20 years ago I would've used it.<br><br>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.<br><br></div>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.<br><br></div>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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 17, 2017 at 5:52 PM, Raymond Hettinger <span dir="ltr"><<a href="mailto:raymond.hettinger@gmail.com" target="_blank">raymond.hettinger@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jan 17, 2017, at 5:16 PM, Victor Stinner <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>> wrote:<br>
><br>
>  /* tp_xxx */" lines and make the code much more<br>
> readable! It should help to prevent bugs when the code is modified.<br>
<br>
</span>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.<br>
<br>
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).<br>
<br>
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).<br>
<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Raymond<br>
</font></span><br>
<br>
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).<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>