M.-A. Lemburg wrote:
It's being able to write
str.transform('gzip').transform('uu')
which doesn't require knowledge about the modules doing the actual
work behind the scenes.
That doesn't preclude those modules exporting their
functionality in the form of codecs having the standard
codec
paul bedaride wrote:
it's why I wonder, if this can't be good if metaclass and class
decorator have the same
interface, then we can use a class as a metaclass or as a decorator ??
That doesn't make sense -- metaclasses and class decorators
are very different things and have very different cap
Joel Bender writes:
A lot, but I don't understand why. You seem to have a completely
different pattern (and Python 2, not Python 3) in mind, but in fact as
far as I can see the only point of conflict is that if the "registry
of string names" proposal were adopted, you'd have trouble using the
met
On Mon, May 19, 2008 at 3:27 PM, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Guido van Rossum writes:
>
> > Hm, Martin is pretty convincing here. Before we go ahead and accept
> > .transform() and friends (by whatever name) we should look for
> > convincing use cases where the transformatio
Guido van Rossum writes:
> Hm, Martin is pretty convincing here. Before we go ahead and accept
> .transform() and friends (by whatever name) we should look for
> convincing use cases where the transformation is typically given by
> some other input, rather than hard-coded in the app. (And case
>> output_to = compressors[name](compresslevel=complevel)
>>
> Your example seems to indicate a model->sequence operation, that I would
> call 'encode'. Now the question becomes, given 'f', what makes more sense:
>
> (a) y = x.transform(f)
> (b) y = x.encode(f)
> (c) y = f(x)
>
> They are convenience methods to the codecs registry
> with the added benefit of applying type checks which the codecs
> registry does not guarantee since it only manages codecs.
I argue that things that could be parameters to .transform don't
belong into the codec registry in the first place.
>
On 2008-05-19 20:12, Terry Reedy wrote:
IOW, I think .transform may be the wrong solution to library
disorganization.
Those methods are not meant to help with the library reorg.
They are needed as an easy way to access codecs that perform
str->str or bytes->bytes encoding/decoding, e.g. for es
"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Motivation: When was the last time you used a gzip compression
| option (ie. yes there are options, but do you use them in the
| general use case) ? Can you write code that applies UU encoding
| without looking up the d
On 2008-05-19 19:19, Raymond Hettinger wrote:
[MAL]
It's being able to write
str.transform('gzip').transform('uu')
>>
which doesn't require knowledge about the modules doing the actual
work behind the scenes.
What is the reverse operation for the above example:
str.untransform('uu').u
You ought to ask this on c.l.py. The designers of the feature were
well aware of the similarities, and also of the differences, and the
decision was made to have both. Explaining this to every person who
asks is not a good use of our time.
On Mon, May 19, 2008 at 10:34 AM, paul bedaride <[EMAIL PR
I think about it, and I think that it's two differents way of applying a
similar thing,
it's why I wonder, if this can't be good if metaclass and class decorator
have the same
interface, then we can use a class as a metaclass or as a decorator ??
paul bedaride
On Mon, May 19, 2008 at 6:10 PM, Gu
Martin v. Löwis wrote:
And that's the main difference why having encode/decode is a good idea,
and having transform/untransform is a bad idea.
I agree that 'untransform' is a bad name for the inverse of transform,
but I don't think 'transform' is bad. For me the distinction is
existence of
[MAL]
It's being able to write
str.transform('gzip').transform('uu')
which doesn't require knowledge about the modules doing the actual
work behind the scenes.
What is the reverse operation for the above example:
str.untransform('uu').untransform('gzip')?
Why can't we use codecs and st
On 2008-05-19 17:14, Guido van Rossum wrote:
Hm, Martin is pretty convincing here. Before we go ahead and accept
.transform() and friends (by whatever name) we should look for
convincing use cases where the transformation is typically given by
some other input, rather than hard-coded in the app.
On Sun, May 18, 2008 at 8:36 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>> It's why a want to know how to express the class decorator for making a
>>> comparison
>
> [Georg]
>>
>> A class decorator works exactly like a function decorator, that is,
>>
>> @foo
>> class X: ...
>>
>> is equivale
Stephen J. Turnbull wrote:
But why be verbose *and* ignore the vernacular?
gzipped = plaintext.transform('gzip')
plaintext = gzipped.transform('gunzip')
I'm generally resistant to a registry, none of my applications are so
general that they would take advantage of a
string-key-to-di
On Sun, May 18, 2008 at 12:30 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Selecting an encoding is the kind of thing that will often come from the
>> application's environment, or user preferences or configuration options,
>> rather than being hardcoded at development time.
>
> And that's t
18 matches
Mail list logo
