More on the 'cruft removal' topic:
I notice that a number of fields in PyTypeObject are deprecated; the
question is, how to get rid of them without gratuitously breaking
everything? Even if there's zero code out there that still uses
tp_getattr instead of tp_getattro, you can't simply remove th
Talin wrote:
> Has anyone proposed the notion of getting away from C-style initializer
> lists, at least for the case of PyTypeObject?
yes, and it was mentioned in the python-dev summaries that were mailed
out a couple of days ago:
http://effbot.org/zone/idea-register-type.htm
Larry Hast
Talin wrote:
> What you end up with is code that looks like this:
>
> PyTypeObject myType = {
> PyObject_HEAD_INIT(NULL)
> 0,
> "myType",
> sizeof(myInstance)
> }
>
> void init() {
> if (PyType_ReadyInit( &myType, myTypeMethods, myTypeData ) < 0)
> return;
> }
If
Greg Ewing wrote:
> Talin wrote:
>
>> What you end up with is code that looks like this:
>>
>> PyTypeObject myType = {
>> PyObject_HEAD_INIT(NULL)
>> 0,
>> "myType",
>> sizeof(myInstance)
>> }
>>
>> void init() {
>> if (PyType_ReadyInit( &myType, myTypeMethods, myTypeData
Some comments:
- I'm all for trying something new here; the existing approach is
definitely aged.
- Fredrik's solution makes one call per registered method. (I don't
know if the patch he refers to follows that model.) That seems a fair
amount of code for an average type -- I'm wondering if it's t
Guido van Rossum wrote:
> - Fredrik's solution makes one call per registered method. (I don't
> know if the patch he refers to follows that model.) That seems a fair
> amount of code for an average type -- I'm wondering if it's too early
> to worry about code bloat (I don't think the speed is goin
Guido van Rossum wrote:
> - Can't we require a C99 compiler and use C99 struct initialization?
> Then the table lines could look like
>
> tp_new = Noddy_new,
> tp_init = Noddy_init,
>
> This probably means the conversion tool would be even simpler (a
> couple of lines of sed would do). It has m
On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
> For example, consider the case for tp_init and tp_new. ... you have
> to put 37 initializer values before them, whether you use them or not.
> Now, you still have the problem that 'tp_methods' itself is something
> like the 28th field in the struct,
On 11/28/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > - Fredrik's solution makes one call per registered method. (I don't
> > know if the patch he refers to follows that model.) That seems a fair
> > amount of code for an average type -- I'm wondering if it's too ear
Guido van Rossum wrote:
>>> Can't we require a C99 compiler and use C99 struct initialization?
>> that won't address the binary compatibility and optimization issues that
>> are the main rationales for my proposal, though.
>
> Why not? This is the Py3k list -- there is no hope for binary
> compat
Fredrik Lundh wrote:
> Guido van Rossum wrote:
>
>> - Fredrik's solution makes one call per registered method. (I don't
>> know if the patch he refers to follows that model.) That seems a fair
>> amount of code for an average type -- I'm wondering if it's too early
>> to worry about code bloat (I
Guido van Rossum wrote:
> I wonder if a bunch of well thought-out standard ABCs, applied to the
> standard data types, and perhaps more support for setting __bases__,
> wouldn't address most concerns.
I think it would, but I don't know if we're going to get anywhere
without getting more concrete.
On 11/28/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> >>> Can't we require a C99 compiler and use C99 struct initialization?
> >> that won't address the binary compatibility and optimization issues that
> >> are the main rationales for my proposal, though.
> >
> > Why
On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
> > Guido van Rossum wrote:
> >
> >> - Fredrik's solution makes one call per registered method. (I don't
> >> know if the patch he refers to follows that model.) That seems a fair
> >> amount of code for an average type -- I'm won
Guido van Rossum wrote:
> Some comments:
>
> - Talin's solution seems to require the definition of an awful lot of
> new constants -- one per slot. And a lot of special-casing in the type
> initialization code to handle them because there are so many different
> signatures.
Actually, I was thinki
Guido van Rossum wrote:
> Some comments:
>
> - Fredrik's solution makes one call per registered method. (I don't
> know if the patch he refers to follows that model.) That seems a fair
> amount of code for an average type -- I'm wondering if it's too early
> to worry about code bloat (I don't thin
On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> Some comments:
>
> - Talin's solution seems to require the definition of an awful lot of
> new constants -- one per slot. And a lot of special-casing in the type
> initialization code to handle them because there are so many
On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Some comments:
> >
> > - Fredrik's solution makes one call per registered method. (I don't
> > know if the patch he refers to follows that model.) That seems a fair
> > amount of code for an average type -- I'm wondering if
Talin wrote:
> The other drawback is that there's a greater chance of a misspelling,
I don't think there is, really. It wouldn't be caught
at compile time, but it would be caught very quickly
at run time if you tried to initialise a type with a
method flagged as "special" whose name wasn't one of
Talin wrote:
> It means that
> now the VM gets to decide what methods are special and what methods
> aren't.
Further to that, the VM still gets to decide whether any
given special method gets a type slot. But the SPECIAL
flag is needed to say that you intend the method to be
*used* as a special
On 29 Nov 2006, at 1:10 AM, Greg Ewing wrote:
BTW, another advantage of all this is that it provides a lot
more flexibility in the overall approach to implementing
the type object. For example, we might decide to move the
type slots into a separate memory block, so that the
type struct could
Guido van Rossum wrote:
> On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > Some comments:
>> >
>> > - Fredrik's solution makes one call per registered method. (I don't
>> > know if the patch he refers to follows that model.) That seems a fair
>> > amount of code for an
22 matches
Mail list logo
