On 2008-06-11 17:15, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-11 13:35, Barry Warsaw wrote:
So I had planned to do a bunch of work last night looking at the release blocker issues, but nature intervened. A bunch of severe thunderstorms knock out my 'net access until this morning.
I'll try to find some time during the day to look at the RB issues. Hopefully we can get Guido to look at them too and Pronounce on some of them. Guido please start with:
My plan is to begin building the betas tonight, at around 9 or 10pm EDT (0100 to 0200 UTC Thursday). If a showstopper comes up before then, I'll email the list. If you think we really aren't ready for beta, then I would still like to get a release out today. In that case, we'll call it alpha and delay the betas.
There are two things I'd like to get in to 3.0:
- .transform()/.untransform() methods (this is mostly done, just need to add the methods to PyUnicode, PyBytes and PyByteArray)
What would these methods do? Use the codec machinery without any type checks?
As discussed in another thread some weeks ago:
.transform() and .untransform() use the codecs to apply same-type conversions. They do apply type checks to make sure that the codec does indeed return the same type.
E.g. text.transform('xml-escape') or data.transform('base64').
I think for transformations we don't need the full codec machinery: ...
No need to invent another wheel :-) The codecs already exist for Py2.x and can be used by the .encode()/.decode() methods in Py2.x (where no type checks occur).
In Py3.x, .encode()/.decode() only allow conversions of the type unicode <-> bytes. .transform()/.untransform() add conversions of the type unicode <-> unicode or bytes <-> bytes.
All other conversions in Py3.x have to go through codecs.encode() and codecs.decode() which are the generic codec access functions from the codec registry.