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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4