We seem to have stumbled upon some strange behavior in cPickle's memo
use when pickling instances.
Here's the repro:
[mymodule.py]
class C:
def __getstate__(self): return ('s1', 's2', 's3')
[interactive interpreter]
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
win
Martin v. Löwis" wrote:
> If obj has no __module__ attribute (or if it is None), pickle
> (didn't check cPickle) also does
>
> for n, module in sys.module.items():
> if "module-ignored": continue
> if getattr(module, result, None) is obj:
> break # use n as module name
>
> If obj does
I'm still plugging away on IronPython's cPickle, and I've stumbled
across another ambiguity in the pickle docs. From
http://docs.python.org/lib/node69.html:
"If a string is returned, it names a global variable whose contents are
pickled as normal. The string returned by __reduce__ should be the
ob
Tim Peters wrote:
> I hope you've read PEP 307:
I have. Thanks to you and Guido for writing it! It's been a huge help.
> The implementation is more like:
[snip]
Thanks! That helps a lot. PEP 307 and the pickle module docs describe the end
result pretty well, but they don't always make it clear
Fredrik Lundh wrote:
> on the other hand, it would be nice if someone actually used Bruce's
questions
> and the clarifications to update the documentation; the ideas behind
the
> internal pickle interfaces aren't exactly obvious, even if you have
the
> source.
I've found a few other places where t
Thanks for your responses, Martin!
Martin v. Löwis wrote:
> Bruce Christensen wrote:
> > - Where are object.__reduce__ and object.__reduce_ex__ defined, and how
> > does copy_reg._reduce_ex fit into the picture?
>
> See
>
> http://docs.python.org/lib/node69.html
In developing a cPickle module for IronPython that's as compatible as
possible with CPython, these questions have come up:
- Where are object.__reduce__ and object.__reduce_ex__ defined, and how
does copy_reg._reduce_ex fit into the picture? PEP 307 states that the
default __reduce__ implementat
In implementing the IronPython _socket module, I've discovered some
puzzling behavior in the standard Python socket wrapper module:
socket._socketobject.close() doesn't actually close sockets; rather, it
just sets _sock to an instance of _closedsocket and lets the GC clean up
the real socket. (See
> > * getfqdn(): The function seems to not always return the FQDN. For
> >example, if I run the following code from 'mybox.mydomain.com', I get
> >strange output. Does getfqdn() remove the common domain between my
> >hostname and the one that I'm looking up?
> socket.getfqdn('otherbox')
> >
Hello,
I'm working on implementing a socket module for IronPython that aims to
be compatible with the standard CPython module documented at
http://docs.python.org/lib/module-socket.html. I have a few questions
about some corner cases that I've found. CPython results below are from
Python 2.4.3 (#6
10 matches
Mail list logo
