Skip to content

pickle problems (with Boost.Python) #35903

Closed

Description

@rwgk
mannequin
BPO 502085
Nosy @mwhudson, @gvanrossum, @tim-one

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = 'https://github.com/gvanrossum'
closed_at = <Date 2011-03-16.17:48:13.762>
created_at = <Date 2002-01-10.22:49:22.000>
labels = ['library']
title = 'pickle problems (with Boost.Python)'
updated_at = <Date 2011-03-16.17:48:13.762>
user = 'https://bugs.python.org/rwgk'

bugs.python.org fields:

activity = <Date 2011-03-16.17:48:13.762>
actor = 'brett.cannon'
assignee = 'gvanrossum'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2002-01-10.22:49:22.000>
creator = 'rwgk'
dependencies = []
files = []
hgrepos = []
issue_num = 502085
keywords = ['patch']
message_count = 8.0
messages = ['8702', '8703', '8704', '8705', '8706', '8707', '8708', '8709']
nosy_count = 5.0
nosy_names = ['mwh', 'gvanrossum', 'tim.peters', 'rwgk', 'brandon-rhodes']
pr_nums = []
priority = 'high'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue502085'
versions = ['Python 2.2']

Activity

  1. rwgk commented on Jan 10, 2002

    rwgkmannequin
    MannequinAuthor

    Boost.Python
    (http://www.boost.org/libs/python/doc/index.html) is a
    popular package for integrating Python and C++.

    Boost.Python pickle support is broken when using
    Python 2.2 final, but
    works with Python 2.2c1.

    I noticed this difference:

    diff /usr/local_cci/Python-
    2.2/lib/python2.2/pickle.py /usr/local_cci/Python-
    2.2c1/lib/python2.2/pickle.py
    26c26
    < __version__ = "$Revision: 1.56 $" # Code
    version
    ---

    __version__ = "$Revision: 1.55 $" # Code
    version
    166,169d165
    < if issubclass(t, TypeType):
    < self.save_global(object)
    < return

    I inserted one line in pickle.py:

    % diff /usr/local_cci/Python-
    2.2/lib/python2.2/pickle.py .
    165a166

            print "t", t
    

    Result:

    t <extension class pickle1.world at 1400c9c08>
    t 
    <boost::python::meta_class<boost::python::detail::exten
    sion_instance> object at 0x3ffffe41ae0>
    Traceback (most recent call last):
      File "zi", line 9, in ?
        pstr = pickle.dumps(wd)
      File "pickle.py", line 974, in dumps
        Pickler(file, bin).dump(object)
      File "pickle.py", line 115, in dump
        self.save(object)
      File "pickle.py", line 216, in save
        self.save_reduce(callable, arg_tup, state)
      File "pickle.py", line 241, in save_reduce
        save(callable)
      File "pickle.py", line 167, in save
        if issubclass(t, TypeType):
    TypeError: issubclass() arg 1 must be a class

    The following patch restores backward-compatibility:

    % diff /usr/local_cci/Python-
    2.2/lib/python2.2/pickle.py .
    166,168c166,173
    < if issubclass(t, TypeType):
    < self.save_global(object)
    < return
    ---

            try:
                issc = issubclass(t, TypeType)
            except TypeError:
                pass
            else:
                if issc:
                    self.save_global(object)
                    return
    

    Remark: I also noticed that 2.2 cPickle still works
    for us
    (double-checked) even though the CVS logs indicate
    that it was
    also modified between 2.2c1 and 2.2.

    Thanks,
    Ralf

  2. added
    stdlibStandard Library Python modules in the Lib/ directory
    on Jan 10, 2002
  3. added
    stdlibStandard Library Python modules in the Lib/ directory
    on Jan 10, 2002
  4. gvanrossum commented on Jan 11, 2002

    @gvanrossum
    Member

    Logged In: YES
    user_id=6380

    Hm, I'm surprised that t (which was returned by
    type(object)) is not considered a type. Can you explain the
    Boost metaclass hierarchy a bit so that I can understand how
    this can work? It was found in the ob_type slot of the
    object (because that's what type() returns) so it should
    look a lot like a type! Then why isn't it one?

    IOW I think that the correct solution would be a change to
    Boost. But I'm open to persuasion.

  5. rwgk commented on Jan 11, 2002

    rwgkmannequin
    MannequinAuthor

    Logged In: YES
    user_id=71407

    IOW I think that the correct solution would be a change to
    Boost. But I'm open to persuasion.

    In principle I agree with you, but here are a few arguments
    to
    justify the easy fix:

    • The old Boost.Python metaclass system is a dead branch.
      We would prefer to concentrate our time on the ongoing
      rewrite of Boost.Python which will be fully based on
      the new Python 2.2 type system.

    • A significant number of people are using released versions
      of Boost(.Python). If the easy fix is integrated in
      Python 2.2.1,
      they could continue to use what they have.

    • Other people might be affected by your change. The
      suggested solution
      will restore backward-compatibility with more people's
      existing code.

    • This is more a question: can you envision that the
      suggested
      fix has negative side-effects?

    Thanks,
    Ralf

  6. gvanrossum commented on Jan 11, 2002

    @gvanrossum
    Member

    Logged In: YES
    user_id=6380

    Ah, I didn't realize this was the old Boost. I should have
    (the new one only runs on Python 2.2).

    I'll think about it.

  7. rwgk commented on Mar 25, 2002

    rwgkmannequin
    MannequinAuthor

    Logged In: YES
    user_id=71407

    python 2.2.1c1 still exhibits the problem described
    in the original posting. Is this expected? Is there
    still hope that the suggested fix/work-around is
    considered for 2.2.1?
    Thanks,
    Ralf

  8. tim-one commented on Mar 25, 2002

    @tim-one
    Member

    Logged In: YES
    user_id=31435

    Boosted priority and assigned to Guido. Guido, if you want
    to do something here for 2.2.1, now's the time.

  9. gvanrossum commented on Mar 26, 2002

    @gvanrossum
    Member

    Logged In: YES
    user_id=6380

    I checked in a fix on the trunk.

    There's nothing I can do to get this into 2.2.1c2, but
    Michael might be willing to put it in 2.2.1final. Otherwise
    it should go into 2.2.2, if we ever release one.

    (Sorry -- I forgot about this, and you were just a tad too
    late to make the 2.2.1c2 release.)

  10. mwhudson commented on Mar 26, 2002

    @mwhudson

    Logged In: YES
    user_id=6656

    It's in 221c2

  11. transferred this issue fromon Apr 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

stdlibStandard Library Python modules in the Lib/ directory

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions