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?
I think for transformations we don't need the full codec machinery:
We probably don't need extensible error handling.
There are transformation that are not invertible, so it doesn't make sense to have both operations in one object. If the operation *is* invertible, two tranformers can be used.
Do we really need a registry that maps function named to functions?
A simple API might look like this:
class TransformInfo: # stateless transformer def transform(self, input):
# return stateful incremental transformer def incrementaltransformer(self):
# wrap stream in a transforming stream def streamtransformer(self, stream):
incrementaltransformer() would return an object that has one method:
def transform(self, input, final=False);