> On Jan 17, 2017, at 5:16 PM, Victor Stinner <victor.stin...@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@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
