Remove text about new pickling; refer to PEP 307 instead.
This commit is contained in:
Guido van Rossum
parent
628e37cde1
commit
9cdeaa0b57
110
pep-0283.txt
110
pep-0283.txt
|
|
@ -26,11 +26,11 @@ Abstract
|
|||
here's a fairly aggressive release schedule that follows the above
|
||||
guidelines:
|
||||
|
||||
alpha 2 -- late January
|
||||
beta 1 -- late February
|
||||
beta 2 -- late March
|
||||
rc 1 -- late April
|
||||
final -- early May
|
||||
alpha 2 -- mid February
|
||||
beta 1 -- mid March
|
||||
beta 2 -- mid April
|
||||
rc 1 -- mid May
|
||||
final -- end of May
|
||||
|
||||
|
||||
Release Manager
|
||||
|
|
@ -38,36 +38,6 @@ Release Manager
|
|||
Guido van Rossum.
|
||||
|
||||
|
||||
Open issues
|
||||
|
||||
There are some issues that may need more work and/or thought
|
||||
before the final release (and preferably before the first beta
|
||||
release). For example:
|
||||
|
||||
- Set API issues; is the sets module perfect?
|
||||
|
||||
I expect it's good enough to stop polishing it until we've had
|
||||
more widespread user experience.
|
||||
|
||||
- A nicer API to open text files, replacing the ugly (in some
|
||||
people's eyes) "U" mode flag. There's a proposal out there to
|
||||
have a new built-in type textfile(filename, mode, encoding).
|
||||
(Shouldn't it have a bufsize argument too?)
|
||||
|
||||
Ditto.
|
||||
|
||||
- Fredrik Lundh's basetime proposal:
|
||||
http://effbot.org/ideas/time-type.htm
|
||||
|
||||
I believe this is dead now.
|
||||
|
||||
- New widgets for Tkinter???
|
||||
|
||||
Has anyone gotten the time for this? *Are* there any new
|
||||
widgets in Tk 8.4? Note that we've got better Tix support
|
||||
already (though not on Windows yet).
|
||||
|
||||
|
||||
Completed features for 2.3
|
||||
|
||||
This list is not complete. See Doc/whatsnew/whatsnew23.tex in CVS
|
||||
|
|
@ -178,41 +148,7 @@ Planned features for 2.3
|
|||
feedback to python-dev@python.org; I hope to maintain this for the
|
||||
life of the 2.3 development process.
|
||||
|
||||
- reST is going to be used a lot in Zope3. Maybe it could become
|
||||
a standard library module?
|
||||
|
||||
- I really, really, really would like to improve pickling of
|
||||
new-style classes.
|
||||
|
||||
I've finally come to the conclusion that any solution to making
|
||||
pickled new-style class instances (and hence pickled datetime
|
||||
objects) more efficient will require adding new codes to the
|
||||
pickle protocol.
|
||||
|
||||
We can do that in Python 2.3. Because this is backwards
|
||||
incompatible, I propose that you have to request this protocol
|
||||
explicitly. I propose to "upgrade' the binary flag to a general
|
||||
"protocol version" flag, with values:
|
||||
|
||||
0 - original protocol
|
||||
1 - binary protocol
|
||||
2 - new protocol
|
||||
|
||||
The new protocol can contain an explicit pickle code for the new
|
||||
datetime objects. That's about all the thinking I've done so
|
||||
far. We need to decide on the new format, but first we must
|
||||
figure out ways how to efficiently pickle and unpickle subclass
|
||||
instances of (picklable) built-in types, preferably without
|
||||
having to copy all the data twice, and instances of new-style
|
||||
classes with slots. And we need to implement these twice: in
|
||||
Python for pickle.py and in C for cPickle.py.
|
||||
|
||||
- I'd also like to get rid of __safe_for_unpickling__ and all
|
||||
other pseudo security features. Attempting to unpickle pickles
|
||||
from an untrusted source is insane, and nothing can help us
|
||||
there; I'd rather make the marshal protocol bulletproof (all it
|
||||
needs is a few more checks for inconsistent data and a little
|
||||
better error handling).
|
||||
- A new pickling protocol. See PEP 307.
|
||||
|
||||
- For a class defined inside another class, the __name__ should be
|
||||
"outer.inner", and pickling should work.
|
||||
|
|
@ -247,8 +183,42 @@ Ongoing tasks
|
|||
- In general, lots of cleanup so it is easier to move forward.
|
||||
|
||||
|
||||
Open issues
|
||||
|
||||
There are some issues that may need more work and/or thought
|
||||
before the final release (and preferably before the first beta
|
||||
release). For example:
|
||||
|
||||
- Set API issues; is the sets module perfect?
|
||||
|
||||
I expect it's good enough to stop polishing it until we've had
|
||||
more widespread user experience.
|
||||
|
||||
- A nicer API to open text files, replacing the ugly (in some
|
||||
people's eyes) "U" mode flag. There's a proposal out there to
|
||||
have a new built-in type textfile(filename, mode, encoding).
|
||||
(Shouldn't it have a bufsize argument too?)
|
||||
|
||||
Ditto.
|
||||
|
||||
- Fredrik Lundh's basetime proposal:
|
||||
http://effbot.org/ideas/time-type.htm
|
||||
|
||||
I believe this is dead now.
|
||||
|
||||
- New widgets for Tkinter???
|
||||
|
||||
Has anyone gotten the time for this? *Are* there any new
|
||||
widgets in Tk 8.4? Note that we've got better Tix support
|
||||
already (though not on Windows yet).
|
||||
|
||||
|
||||
Features unlikely to make it into Python 2.3
|
||||
|
||||
- reST is going to be used a lot in Zope3. Maybe it could become
|
||||
a standard library module? (Since reST's author thinks it's too
|
||||
instable, I'm inclined not to do this.)
|
||||
|
||||
- Decide on a clearer deprecation policy (especially for modules)
|
||||
and act on it. For a start, see this message from Neil Norwitz:
|
||||
http://mail.python.org/pipermail/python-dev/2002-April/023165.html
|
||||
|
|
|
|||
Loading…
Reference in New Issue