[Python-checkins] python/nondist/peps pep-0307.txt,1.25,1.26

tim_one@users.sourceforge.net tim_one@users.sourceforge.net
Mon, 10 Feb 2003 15:21:09 -0800


Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1:/tmp/cvs-serv19376

Modified Files:
	pep-0307.txt 
Log Message:
+ Add XXX comments.  I'll clean those up later (or Guido and I both will).
+ Minor typo repair.
+ Added very brief sections about the other stuff that's new in protocol 2.


Index: pep-0307.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0307.txt,v
retrieving revision 1.25
retrieving revision 1.26
diff -C2 -d -r1.25 -r1.26
*** pep-0307.txt	10 Feb 2003 22:13:34 -0000	1.25
--- pep-0307.txt	10 Feb 2003 23:21:03 -0000	1.26
***************
*** 372,375 ****
--- 372,377 ----
      For new-style classes implemented in Python, the default
      __reduce__ implementation works as follows:
+     XXX We seem to be missing a section for new-style classes implemented
+     XXX in C.
  
        Let D be the class on the object to be pickled.  First, find the
***************
*** 393,396 ****
--- 395,405 ----
          state = B(obj)
  
+     XXX How does the above relate to the steps explained earlier for
+     XXX __reduce__?  For example, what here corresponds to the  earlier
+     XXX description's function(*arguments) step?
+ 
+     XXX Below, does __getstate__() customization replace the source of
+     XXX the value called "state" just above, or is this customization a
+     XXX distinct step?
      Objects for which this default __reduce__ implementation is used
      can customize it by defining __getstate__ and/or __setstate__
***************
*** 406,409 ****
--- 415,420 ----
      this condition.
  
+     XXX Is it the case that "pickling new-style class instances using
+     XXX protocols 0 or 1" ignores __getinitargs__?
  
  Case 3: pickling new-style class instances using protocol 2
***************
*** 546,551 ****
      such applications.
  
!     First of all, a few ranges of extension codes is reserved for
!     private use.  Any application can register codes in these ranges.
      Two applications exchanging pickles using codes in these ranges
      need to have some out-of-band mechanism to agree on the mapping
--- 557,562 ----
      such applications.
  
!     First, a few ranges of extension codes are reserved for private
!     use.  Any application can register codes in these ranges.
      Two applications exchanging pickles using codes in these ranges
      need to have some out-of-band mechanism to agree on the mapping
***************
*** 597,601 ****
          (module, name) pair may not be mapped to more than one code,
          nor may a code be mapped to more than one (module, name)
!         pair.  (XXX Aliasing may actually cause as problem for this
          requirement; we'll see as we go.)
  
--- 608,612 ----
          (module, name) pair may not be mapped to more than one code,
          nor may a code be mapped to more than one (module, name)
!         pair.  (XXX Aliasing may actually cause a problem for this
          requirement; we'll see as we go.)
  
***************
*** 657,660 ****
--- 668,702 ----
      To fix this, a __getnewargs__ method should be added that returns
      the appropriate argument tuple (excluding the class).
+ 
+ 
+ Pickling Python longs
+ 
+     Pickling and unpickling Python longs takes time quadratic in
+     the number of digits, in protocols 1 and 2.  Under protocol 2,
+     new opcodes support linear-time pickling and unpickling of longs.
+ 
+ 
+ Pickling bools
+ 
+     Protocol 2 introduces new opcodes for pickling True and False
+     directly.  Under protocols 0 and 1, bools are pickled as integers,
+     using a trick in the representation of the integer in the pickle
+     so that an unpickler can recognize that a bool was intended.
+ 
+ 
+ Pickling small tuples
+ 
+     Protocol 2 introduces new opcodes for more-compact pickling of
+     tuples of lengths 1, 2 and 3.  Protocol 1 previously introduced
+     an opcode for more-compact pickling of empty tuples.
+ 
+ 
+ Protocol identification
+ 
+     Protocol 2 introduces a new opcode, with which all protocol 2
+     pickles begin, identifying that the pickle is protocol 2.
+     Attempting to unpickle a protocol 2 pickle under older versions
+     of Python will therefore raise an "unknown opcode" exception
+     immediately.