RetroSearch Browse

Fri Aug 8 01:02:13 EDT 2003 · https://mail.python.org/pipermail/python-dev/2003-August/037523.html

At 03:50 07.08.2003 +0200, Samuele Pedroni wrote:
>At 21:23 06.08.2003 -0400, Tim Peters wrote:
>
>>Note that I don't object to introducing a mechanism that copy etc can use
>>that's highly efficient under all implementations.  But the introduction of
>>such a mechanism isn't sufficient reason to get rid of the current id(),
>>even if id() is horridly expensive in some implementations.
>
>yes, that would be a reasonable compromise, basically as implemented the 
>new Jython id is costly a bit in speed (not so relevant) and then memory 
>if one asks the id of a lot of long lived objects, so users should be 
>aware of this and in case stear away from id, having copy.deepcopy etc not 
>using id(.) would help with that. Deprecating maybe is too much but at 
>least making users aware that id() is horridly expensive in some 
>implementations <wink>.

I will follow up with something more concrete to discuss about (some 
patches) at some point in the 2.4 timeframe. Now I want to focus on other 
things. At least the problems have been put on the table and 
misunderstandings cleared up.

regards.  

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-August/037523.html below:

[Python-Dev] sizeof(long) != sizeof(void*)