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
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 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
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.
[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
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
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
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
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
"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 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
> 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.
>
>> 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)
>
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
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
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
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
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
18 matches
Mail list logo
