[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