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
|
here's a fairly aggressive release schedule that follows the above
|
||||||
guidelines:
|
guidelines:
|
||||||
|
|
||||||
alpha 2 -- late January
|
alpha 2 -- mid February
|
||||||
beta 1 -- late February
|
beta 1 -- mid March
|
||||||
beta 2 -- late March
|
beta 2 -- mid April
|
||||||
rc 1 -- late April
|
rc 1 -- mid May
|
||||||
final -- early May
|
final -- end of May
|
||||||
|
|
||||||
|
|
||||||
Release Manager
|
Release Manager
|
||||||
|
|
@ -38,36 +38,6 @@ Release Manager
|
||||||
Guido van Rossum.
|
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
|
Completed features for 2.3
|
||||||
|
|
||||||
This list is not complete. See Doc/whatsnew/whatsnew23.tex in CVS
|
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
|
feedback to python-dev@python.org; I hope to maintain this for the
|
||||||
life of the 2.3 development process.
|
life of the 2.3 development process.
|
||||||
|
|
||||||
- reST is going to be used a lot in Zope3. Maybe it could become
|
- A new pickling protocol. See PEP 307.
|
||||||
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).
|
|
||||||
|
|
||||||
- For a class defined inside another class, the __name__ should be
|
- For a class defined inside another class, the __name__ should be
|
||||||
"outer.inner", and pickling should work.
|
"outer.inner", and pickling should work.
|
||||||
|
|
@ -247,8 +183,42 @@ Ongoing tasks
|
||||||
- In general, lots of cleanup so it is easier to move forward.
|
- 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
|
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)
|
- Decide on a clearer deprecation policy (especially for modules)
|
||||||
and act on it. For a start, see this message from Neil Norwitz:
|
and act on it. For a start, see this message from Neil Norwitz:
|
||||||
http://mail.python.org/pipermail/python-dev/2002-April/023165.html
|
http://mail.python.org/pipermail/python-dev/2002-April/023165.html
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue