Changes between Initial Version and Version 1 of Ticket #15619, comment 15


Ignore:
Timestamp:
01/02/14 13:16:41 (6 years ago)
Author:
SimonKing
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #15619, comment 15

    initial v1  
    66> Honestly, I don't think pickling really needs any amount of efficient code.
    77
    8 That's a valid point, too. I only plays a role if *copying* is implemented by pickling. But we have a separate and hopefully efficient implementation of `__copy__`, and thus `__reduce__` is really only involved when people want to store a poset (and hence, an immutable graph, and thus, a static sparse backend) into a file. So, spending some milli seconds seems acceptable.
     8That's a valid point, too. Efficient pickling mainly plays a role if *copying* is implemented by pickling, since this may happen interactively and frequently. But we have a separate and hopefully efficient implementation of `__copy__`, and thus `__reduce__` is really only involved when people want to store a poset (and hence, an immutable graph, and thus, a static sparse backend) into a file. So, spending some milli seconds seems acceptable.
    99
    1010> So as we are just implementing it to make the testsuite happy, and unless you want to mess with all this code just because of that, let's use it. It's short and it works. It's bad code of course, because pickling is bad work. It's a generic way to store data, that should work regardless of what the data is. It's like XML. Saving data is not something that should be done without *knowing* what the data is.