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.hettin...@gmail.com> wrote: > > > 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/ > guido%40python.org > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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