A RetroSearch Logo

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

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2008-January/076358.html below:

[Python-Dev] [Python-3000] inst_persistent_id

[Python-Dev] [Python-3000] inst_persistent_idJim Fulton jim at zope.com
Sun Jan 20 22:10:24 CET 2008
I took Python-3000 out of the cc list as I originally just wanted to  
make them aware of this issue.

On Jan 14, 2008, at 12:59 PM, Armin Rigo wrote:

> Hi,
>
> On Sat, Jan 12, 2008 at 07:33:38PM -0500, Alexandre Vassalotti wrote:
>> Well, in Python 3K, inst_persistent_id() won't be usable, since
>> PyInstance_Type was removed.
>
> Looking at the code, inst_persistent_id() is just a confusing name.   
> It
> has got nothing to do with PyInstance_Type; it's called for any object
> type that cPickle.c doesn't know how to handle.

It has to do with instances in a more general sense.

>  In fact, it seems that
> cPickle.c never calls inst_persistent_id() for objects of type
> PyInstance_Type...


Hm, good point.

At the time, all I cared about were ExtensionClass instances, which  
were akin to modern-day new-style instances.

It doesn't make sense to not call this function for classic instances.

This optimization is fairly useful.  I propose to update the logic to  
call this function for classic instances too.  I'm also open to  
renaming it if that would make people happier. :)

Thoughts?

Jim

--
Jim Fulton
Zope Corporation


More information about the Python-Dev mailing list

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