Re: [Python-3000] PEP 3138- String representation in Python 3000

[Guido van Rossum]

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 the main difference why having encode/decode is a good idea,
> and having transform/untransform is a bad idea.
>
> Encoding names are in configuration data all the time, or even in the
> actual data (e.g. in MIME); they rarely are in configuration.
>
> You typically *don't* read the name of transformations from a
> configuration file. And even if they are in configuration, you
> typically have a fixed set of options, rather than an extensible
> one.
>
>> With a flat,
>> string-based codec namespace, those things are trivial to look up.
>> Having to mess around with __import__ just to support a "choose
>> compression method" configuration option would be fairly annoying.
>
> I wouldn't mess with import:
>
> import gzip, bz2
> compressors = {"gzip":gzip.StreamCompressor,
>   "bzip2":bz2.BZ2Compressor}
> decompressors={"gzip":gzip.StreamDecompressor,
>   "bzip2":bz2.BZ2Decompressor}
>
> It's not that people invent new compression methods every day.
>
> OTOH, these things have often more complex parameters than just
> a name; e.g. the compressors also take a compression level. In
> these cases, using
>
>  output_to = compressors[name](compresslevel=complevel)
>
> could work fine (as both might happen to support the compresslevel
> keyword argument).
>
>> The case for the special namespace is much stronger for the actual
>> unicode encodings, but it still has at least some force for the
>> bytes->bytes and str->str transforms.
>
> Not to me, no.

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 cases where
there are two or three possibilities from a fixed menu don't count --
so that would rule out Content-transfer-encoding.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] PEP 3138- String representation in Python 3000

[Joel Bender]

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-dictionary-to-function-pointer.  If they did, they would 
have to have some pretty severe constraints on what functions can be 
selected, so I would end up building my own context sensitive dictionary 
of available functions.   I'm in favor of:


gzipped = plaintext.transform(zlib.compress)
plaintext = gzipped.transform(zlib.decompress)

So, you may ask, why would that be any better that this...

gzipped = zlib.compress(plaintext)

...and the answer is that it depends on what you consider the most 
appropriate design pattern to follow.



I think the style should be EIBTI for "private" protocols, and TOOWDTI
for transforms that wrap well-known libraries.


I've been around socket libraries and protocol encoding/decoding stacks 
too long I guess, or I'm just jaded, but TOOWDTI is a pipe dream. 
There's Only One Blessed Way To Do It I can understand and appreciate.


EIBTI trumps TOOWDTI when it has to go through a registry.  I would be 
-1 on this design:


In module codecs:

from gzip import compress as _gzip_compress
...
_registry['gzip'] = _gzip_compress

Where there is a great deal of code that enforces TOOWDTI, effectively 
obfuscating the fact that all your passing to transform() nothing more 
magical than a reference to a function.



This is a non-starter, because you don't know what the representation
of strings is.


If you're working on that kind of application.  My applications have to 
know what the items in the sequence are, or they have to figure it out, 
but when it comes time to do the transformation, they know.



We could be right-thinking and mandate that in the
.transform() context the string representation is considered
big-endian (and for little-endian platforms the bytes are swabbed
before applying the transformation).


Yuck.


But that would annoy all the Wintel users because string.transform('zip')
would produce gobbledgook when unzipped from the command line.  And
of course assuming a little-endian representation is un-right-thinkable.


It would annoy me because mandating the format of the input is up to the 
transformation function, not the transform().


y = x.transform(f)

If there is some endian restriction on f, it should detect it and 
enforce it, or if it can't, document it.  If there is some platform 
strangeness, it should take that into account.



In this sense string-to-string and byte-to-byte *must* be kept
separate from "true" codecs.


I don't any codecs that aren't true.  Some may be more popular or 
command than others, and the more popular ones may be blessed by being 
presented as easily accessible, just like your gunzip === gzip_to_plaintext.



I think it would be a very bad idea to allow names to be shared
for, say, byte-to-byte and string-to-byte "gzip" for the reason
given above.


I don't agree, only because I've written plenty of functions that can 
take a variety of different kinds of inputs as a convenience.  If 
zlib.compress can take bytes or strings I would be fine with that, and 
if I could be more explicit, e.g.,


gzipped = plainbytes.transform(zlib.compress_bytes)

I would be even happier.   What is not available in Python that is in 
C++, and believe that I don't miss it all THAT much, is a way to select 
the appropriate function based on both the input and output. 
Annotations would have been a way to do it, but there's far too many 
people that don't like it for very good reasons.



Whether string-to-string and byte-to-byte need to share a namespace is
another question, but since we already need three (string->byte,
byte->string, byte->byte) that should be forced not to collide, I
don't think that there's that big a loss in requiring that
.transform('pig_latin') (string to string) be spelled differently from
.transform('pig_latin1') (byte to byte assuming ISO 8859/1 data).


I agree, and I don't think there's an advantage to passing string names.

import piglatin as pig
piggy = mytext.transform(pig.latin1_encode)

I'm -1 on transform.register('pig_latin1', pig.latin1_encode).


Do you have use cases where byte-to-byte and string-to-string
transformations should share the same name?


Not in the same module.


Joel

___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] Metaclass Vs Class Decorator

[Guido van Rossum]

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 equivalent to
>>
>> class X: ...
>> X = foo(X)
>>
>> This should be all you need to know in order to write a class decorator.
>
> I concur.

Technically, that's true, but an example wouldn't hurt. Examples also
help understanding the motivation. Even the difference between class
decorators and metaclasses could be explained with examples. (E.g. a
metaclass that auto-registers its classes vs. a class decorator that
registers a class.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] PEP 3138- String representation in Python 3000

[M.-A. Lemburg]

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. (And cases where
there are two or three possibilities from a fixed menu don't count --
so that would rule out Content-transfer-encoding.)


The .transform() methods are meant as interface to same type
codecs in general, not just compression algorithms.

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.

Of course, you can write everything directly against the codec
registry or some other specialized interface, but that's not
really what we're after here.

The methods are meant to make code easy to write in the
general use case, without having to worry about special
parameters or finding the right module and function names.

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 details in the documentation (ie. there
is a module for doing UU-encoding in the stdlib, but what's it's
name, what's the function, does it need extra logic) ?

The motivation is not driven by having the need to pass a
configuration parameter to a .transform() method.

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.

We're not adding those methods because there's no other way
to get the functionality. It's all about usability, readability
and PEP20 ("Beautiful is better than ugly.").

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 19 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] PEP 3138- String representation in Python 3000

[Raymond Hettinger]

[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 stick with the usual encode/decode methods?


Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] PEP 3138- String representation in Python 3000

[Joel Bender]

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 a 'model'.


sequence -> model -> sequence

...is different than...

sequence -> sequence

where 'sequence' is a string, bytes or stream.  In transformations there 
is no intermediate model.



OTOH, these things have often more complex parameters than just
a name; e.g. the compressors also take a compression level. In
these cases, using

  output_to = compressors[name](compresslevel=complevel)

could work fine (as both might happen to support the compresslevel
keyword argument).


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)

What do you expect the function signature of 'output_to' to be?  Is it 
callable?  Is it something that is going to be a stream wrapper, that 
has .read() and .write()?  Is it an intermediary, something that can be 
built as an object and bound between two streams bidirectionally?


f().transform(x, y)

Another case, which would suffer from as much if not more API confusion, 
would be encrypting and decrypting...


from Crypto.Cipher import DES

obj = DES.new('abcdefgh', DES.ECB)
plain = "Guido van Rossum is a space alien.XX"

In this case using .transform() would seem to be a good fit because 
there is no model, but 'obj' suffers from being directionless, so it 
becomes this...


ciph = plain.transform(obj.encrypt)

...which isn't substantially clearer than...

ciph = obj.encrypt(plain)

Parametric transformations don't bother me, but that would be an 
indication that there's a lot more going on, and perhaps there are 
better (and pre-existing) labels for these functions.



Joel
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] Metaclass Vs Class Decorator

[paul bedaride]

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, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> 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 equivalent to
> >>
> >> class X: ...
> >> X = foo(X)
> >>
> >> This should be all you need to know in order to write a class decorator.
> >
> > I concur.
>
> Technically, that's true, but an example wouldn't hurt. Examples also
> help understanding the motivation. Even the difference between class
> decorators and metaclasses could be explained with examples. (E.g. a
> metaclass that auto-registers its classes vs. a class decorator that
> registers a class.)
>
> --
> --Guido van Rossum (home page: 
> http://www.python.org/~guido/
> )
> ___
> Python-3000 mailing list
> Python-3000@python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/paul.bedaride%40gmail.com
>
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] Metaclass Vs Class Decorator

[Guido van Rossum]

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 PROTECTED]> wrote:
> 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, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>
>> 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 equivalent to
>> >>
>> >> class X: ...
>> >> X = foo(X)
>> >>
>> >> This should be all you need to know in order to write a class
>> >> decorator.
>> >
>> > I concur.
>>
>> Technically, that's true, but an example wouldn't hurt. Examples also
>> help understanding the motivation. Even the difference between class
>> decorators and metaclasses could be explained with examples. (E.g. a
>> metaclass that auto-registers its classes vs. a class decorator that
>> registers a class.)
>>
>> --
>> --Guido van Rossum (home page: http://www.python.org/~guido/)
>> ___
>> Python-3000 mailing list
>> Python-3000@python.org
>> http://mail.python.org/mailman/listinfo/python-3000
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-3000/paul.bedaride%40gmail.com
>
>
> ___
> Python-3000 mailing list
> Python-3000@python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] PEP 3138- String representation in Python 3000

[M.-A. Lemburg]

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').untransform('gzip')?


Yes.

BTW: Since the codecs do bytes->bytes conversion, I should have
written bytes.transform('gzip').transform('uu')


Why can't we use codecs and stick with the usual encode/decode methods?


That's what you can do in Python 2.x.

In Py 3.x, .encode() and .decode() have strict type requirements
on their return types. .transform() and .untransform() return the
same type, .encode() and .decode() return bytes and str resp.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 19 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] PEP 3138- String representation in Python 3000

[Terry Reedy]

"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 details in the documentation (ie. there
| is a module for doing UU-encoding in the stdlib, but what's it's
| name, what's the function, does it need extra logic) ?

This suggests to me the possibility of two more packages for the 
reorganized stdlib: b2b and s2s.  Or of considating most transform 
functions into one module, just as math and cmath consolidate float and 
complex transforms -- some with inverses and some not.

IOW, I think .transform may be the wrong solution to library 
disorganization.

| The motivation is not driven by having the need to pass a
| configuration parameter to a .transform() method.
|
| It's being able to write
|
| str.transform('gzip').transform('uu')

To me, this is to
uu(gzip(s))
as
somefloat.transform('cos').transform('sin')
is to
sin(cos(somefloat))

| which doesn't require knowledge about the modules doing the actual
| work behind the scenes.

It does require knowledge of the registered name.

| We're not adding those methods because there's no other way
| to get the functionality. It's all about usability, readability
| and PEP20 ("Beautiful is better than ugly.").

I think I find the direct function call more readable and prettier.

tjr



___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] PEP 3138- String representation in Python 3000

[M.-A. Lemburg]

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 escaping
text ('unicode-printable', 'xml-escape').

I'm using gzip, uu or base64 as examples, since those codecs
already exist in Python 2.x and currently cannot be used in
Python 3.x due to the type restrictions on the .encode() and
.decode() methods.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 19 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] PEP 3138- String representation in Python 3000

[Martin v. Löwis]

> 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.

> Of course, you can write everything directly against the codec
> registry or some other specialized interface, but that's not
> really what we're after here.

No need for writing directly against the codec registry.

Using some other specialized interface: yes, Yes, YES!

> 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) ?

Depends on what I do: when I invoke gzip from the command line,
I pass -9 all the time, as a habit.

Or did you mean "in Python"? It's a long time that I needed to
use the gzip module at all; and the last few times, I suppose
it was always through the tarfile module.

I use gzip so rarely that I find it wasteful that it gets its
own shortcut. If I had a (half-serious) wish for a string
method shortcut, it would be

"GET / HTTP/1.0\r\n\r\n".sendto("foo.bar.com", 80)

Perhaps I should write a codec for that:

"GET / HTTP/1.0\r\n\r\n".encode("http:foo.bar.com")

which sends the request and returns the response :-)

> Can you write code that applies UU encoding
> without looking up the details in the documentation (ie. there
> is a module for doing UU-encoding in the stdlib, but what's it's
> name, what's the function, does it need extra logic) ?

You mean, without looking into the HTML documentation? Sure enough.
"import uu" I remember, then I do help(uu), scroll to the end.

If you can't remember that the module's name is uu, then you probably
can't remember the codec, either:

py> "foo".encode("uuencode")
Traceback (most recent call last):
  File "", line 1, in 
LookupError: unknown encoding: uuencode

Regards,
Martin

___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] PEP 3138- String representation in Python 3000

[Martin v. Löwis]

>>   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)
> 
> What do you expect the function signature of 'output_to' to be?

People brought that up in the context of stacking streams. So output_to
would have a stream interface, so you would say

   (d) output_to.write(x)

(and yes, I do recognize that the ultimate receiver of the output,
e.g. the socket or such, is missing in my API)

> Is it
> callable?  Is it something that is going to be a stream wrapper, that
> has .read() and .write()?

That's what I meant it to be.

I'm not quite sure why you are asking these questions.

> In this case using .transform() would seem to be a good fit because
> there is no model, but 'obj' suffers from being directionless, so it
> becomes this...
> 
> ciph = plain.transform(obj.encrypt)
> 
> ...which isn't substantially clearer than...
> 
> ciph = obj.encrypt(plain)

It isn't substantially clearer, and *therefore* it is a good fit???

> Parametric transformations don't bother me, but that would be an
> indication that there's a lot more going on, and perhaps there are
> better (and pre-existing) labels for these functions.

If you are saying that we should call it .encrypt, not .transform:
I completely agree.

Regards,
Martin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] PEP 3138- String representation in Python 3000

[Stephen J. Turnbull]

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 cases where
 > there are two or three possibilities from a fixed menu don't count --
 > so that would rule out Content-transfer-encoding.)

I don't understand the motivation for this restriction.  I think we do
not want to share names across categories, so the size of any given
category is not important, it's the whole registry that is useful.  If
people want to filter on category, the registry entries could be given
a 'category' attribute.

Aside from that, the kind of application I have in mind is indeed
something like the email module and its clients (like Mailman).
Things like

language_charset_map = { 'japanese' : 'iso-2022-jp',
 'english' : 'iso-8859-1',
 'russian' : 'koi8-r',
 ... }

charset_transfer_encoding_map = { 'iso-2022-jp' : 'base64',
  'iso-8859-1' : 'quoted-printable',
  'koi8-r' : 'base64',
  ... }

mime_type_compression_map = { 'text/plain' : None,
  'img/bmp' : 'gzip',
  ... }

with the almost obvious definition of transform_mime_body().

This kind of table is often given in a file accessed by non-Python-
programmers.  For example, for encodings that are not mostly ASCII,
gzipped base64 may be a very economical way to transmit (and store) a
text part.  However, a non-English list that transmits a lot of code
might prefer quoted-printable to allow the code to be analyzed by some
kind of robot (obviously a legacy app!), and many lists will have
strong preferences between UTF-8 and a legacy encoding.  Japanese
companies often have corporate encodings containing characters not
available in JIS (and sometimes not in Unicode).  A list dedicated to
image processing may want to add image/* formats that haven't yet been
registered with the IANA, etc.

On the Mailman lists it is a FAQ that people don't understand the
difference between 'None' and None.  I don't think we can avoid None,
True, and False, but for many Mailman admins the difference between
'gzip' and Compressors.gzip.compress is non-obvious and annoying.
Giving string names to all these transforms would make the
administration interface perceptibly more regular.

On the other hand, suppose we have a web interface for configuration
so that the admins don't ever see the difference between a codec
registry key and a Python identifier.  Do we want to expose all the
possible compressors, codecs, transfer encodings, and what not in the
module that provides the configuration UI so that the list of names
can be provided?  How does the web interface avoid needing to know all
of those in advance?  How does the web interface know which functions
are which (eg, compressor v. decompressor)?

Of course the same questions apply to a registry, but as functionality
(answers to those questions) is added to the registry, the changes
needed to take advantage of it are much more localized and less
invasive than, say, requiring "compressors" to provide "compress" and
"uncompress" functions or methods, and a standard set of options.

The main thing that I sympathize with in Martin's post is the issue of
options to transforms, but it seems to me that keyword arguments deal
with that clearly and flexibly.

___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] PEP 3138- String representation in Python 3000

[Guido van Rossum]

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 transformation is typically given by
>  > some other input, rather than hard-coded in the app. (And cases where
>  > there are two or three possibilities from a fixed menu don't count --
>  > so that would rule out Content-transfer-encoding.)
>
> I don't understand the motivation for this restriction.  I think we do
> not want to share names across categories, so the size of any given
> category is not important, it's the whole registry that is useful.  If
> people want to filter on category, the registry entries could be given
> a 'category' attribute.
>
> Aside from that, the kind of application I have in mind is indeed
> something like the email module and its clients (like Mailman).
> Things like
>
> language_charset_map = { 'japanese' : 'iso-2022-jp',
> 'english' : 'iso-8859-1',
> 'russian' : 'koi8-r',
> ... }
>
> charset_transfer_encoding_map = { 'iso-2022-jp' : 'base64',
>  'iso-8859-1' : 'quoted-printable',
>  'koi8-r' : 'base64',
>  ... }
>
> mime_type_compression_map = { 'text/plain' : None,
>  'img/bmp' : 'gzip',
>  ... }
>
> with the almost obvious definition of transform_mime_body().
>
> This kind of table is often given in a file accessed by non-Python-
> programmers.  For example, for encodings that are not mostly ASCII,
> gzipped base64 may be a very economical way to transmit (and store) a
> text part.  However, a non-English list that transmits a lot of code
> might prefer quoted-printable to allow the code to be analyzed by some
> kind of robot (obviously a legacy app!), and many lists will have
> strong preferences between UTF-8 and a legacy encoding.  Japanese
> companies often have corporate encodings containing characters not
> available in JIS (and sometimes not in Unicode).  A list dedicated to
> image processing may want to add image/* formats that haven't yet been
> registered with the IANA, etc.
>
> On the Mailman lists it is a FAQ that people don't understand the
> difference between 'None' and None.  I don't think we can avoid None,
> True, and False, but for many Mailman admins the difference between
> 'gzip' and Compressors.gzip.compress is non-obvious and annoying.
> Giving string names to all these transforms would make the
> administration interface perceptibly more regular.

There's no reason that for this pretty unusual and specific case you
couldn't have your own function that is controlled by the string value
read from the map edited by the list admin.

I think the real abomination here is to expect list admins to use
Python syntax at all.

> On the other hand, suppose we have a web interface for configuration
> so that the admins don't ever see the difference between a codec
> registry key and a Python identifier.  Do we want to expose all the
> possible compressors, codecs, transfer encodings, and what not in the
> module that provides the configuration UI so that the list of names
> can be provided?  How does the web interface avoid needing to know all
> of those in advance?  How does the web interface know which functions
> are which (eg, compressor v. decompressor)?
>
> Of course the same questions apply to a registry, but as functionality
> (answers to those questions) is added to the registry, the changes
> needed to take advantage of it are much more localized and less
> invasive than, say, requiring "compressors" to provide "compress" and
> "uncompress" functions or methods, and a standard set of options.
>
> The main thing that I sympathize with in Martin's post is the issue of
> options to transforms, but it seems to me that keyword arguments deal
> with that clearly and flexibly.
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] PEP 3138- String representation in Python 3000

[Stephen J. Turnbull]

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
method name 'transform' as you would like to.

There's nothing in the registry proposal that prevents you from
calling functions by name, or writing polymorphic transformers, etc.

___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] Metaclass Vs Class Decorator

[Greg Ewing]

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 capabilities.

There is some overlap between the things they can do, but
trying to unify them would be a mistake.

--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Re: [Python-3000] PEP 3138- String representation in Python 3000

[Greg Ewing]

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 interface.

There are two independent issues here:

1) Should the functionality be provided in the form
   of a codec? (Yes, that's fine, IMO.)

2) Should all codecs live in a central registry and
   be callable via methods on strings and bytes?
   (I'm not convinced that's the case.)

--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com