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:
>>
>> http://bugs.python.org/issue643841
>>
>> 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);
> [...]
Servus,
Walter
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4