[Python-Dev] PEP 286: Please comment

Martin v. Loewis martin@v.loewis.de
13 Mar 2002 08:37:19 +0100


Jack Jansen <Jack.Jansen@oratrix.com> writes:

> - I assume 'failobjects' are deallocated on failure, not success, yes?

Oops, right. More precisely: the list is deallocated in either case,
but the objects survive clearing in case of success.

> - I miss a rationale (some use cases would be nice)

I'm primarily concerned with the rationale given: fixing the bugs
#416288 and #501716. I should also give the rationale of allowing
introduction of the 'E' converter; beyond that, I don't know what
applications people envision - contributions are welcome.

> - it's nowhere explained how the ...Memory() calls would be
> implemented.

It's an implementation detail :-) I plan to use a PyCObject, using a
destructor and a description-cookie.

> - Would the interpreter mainloop always create argument tuples where
> it now uses normal tuples? 

It would always allocate an argument tuple. It would keep the lists
empty (NULL) until they are used. I'll add that.

> Is this a method flag? What's the cost of conversion (or of using
> ArgumentTuples in stead of tuples in general)?

The cost should be an increase by 8 bytes in the size of the argument
tuple if the affected converters are not used; otherwise, it will
allocate additional objects depending on the arguments passed.

If people simultaneously change 'e' converters to 'E' converters, I
expect a speed-up, since there will be typically one memory allocation
less per affected argument.

> Issues with apply()?

Indeed. I did not think about this so far: with the implementation I
had in mind, a warning would be produced and the resulting object
becomes garbage if AddOkMemory is invoked in the function being
applied. I guess this is not acceptable.

One solution would be to copy all argument tuples in apply. That cost
could be reduced by adding a method flag, and only copy if the method
being applied uses an affected converter.

Another solution would be to give up the entire of a new type, and use
a weak dictionary to associate the argument tuples with additional
information. That would require that tuples become weakly
referencable. 

Input on that matter would be appreciated.

> - What would happen to calls that still use normal tuples? There's a
> lot of callback code out there...

In principle, this is the same issue as apply: if the code creates
tuples on its own, it may produce garbage. OTOH, if the code uses
PyObject_Call, then everything would work fine: PyObject_Call would
create argument tuples.

Another option is to have Py_BuildValue create argument tuples, but
I'm not sure that this would help much.

It appears that the apply() issue might kill the entire idea;
suggestions how to proceed are welcome.

Regards,
Martin