Atuso
you are not really addressing my arguments in your reply.
My main concern is that repr(unicode) as well as '%r' is used
a lot in logging and debugging of applications.
In the 2.x series of Python, the output of repr() has traditionally
always been plain ASCII and does not require any spec
On 2008-05-09 18:06, Guido van Rossum wrote:
On Fri, May 9, 2008 at 3:54 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
On 2008-05-08 22:55, Terry Reedy wrote:
Functions that map unicode->unicode or bytes->bytes could be called
transcoders. Each type could be given a .transcode method to go alon
M.-A. Lemburg schrieb:
On 2008-05-09 18:06, Guido van Rossum wrote:
On Fri, May 9, 2008 at 3:54 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
On 2008-05-08 22:55, Terry Reedy wrote:
Functions that map unicode->unicode or bytes->bytes could be called
transcoders. Each type could be given a .tra
On Wed, May 14, 2008 at 9:33 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Will this get use the hex, base64 etc. "codecs" back? If yes, great!
If someone does the work, yes. There will need to be some way to add
metadata to codecs to indicate which of the following they support:
str<->bytes, str
On 2008-05-14 18:33, Georg Brandl wrote:
M.-A. Lemburg schrieb:
In summary, I'd just like to see the following happen:
* revert the type restrictions on the PyCodec_* API
* enforce the restrictions on the .encode() and .decode()
methods of PyUnicode and PyString objects (str and bytes)
*
On 2008-05-14 18:55, Guido van Rossum wrote:
On Wed, May 14, 2008 at 9:33 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
Will this get use the hex, base64 etc. "codecs" back? If yes, great!
If someone does the work, yes. There will need to be some way to add
metadata to codecs to indicate which
> Hardwiring the encoding is not a good idea, esp. since there
> are lots of alternatives for you to get readable output from
> PyUnicode object now and without any changes to the interpreter.
>
> E.g.
>
> print '%s' % u.encode('utf-8')
We are talking about Python 3 here, so it is fairly importa
On 5/14/08, Georg Brandl <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg schrieb:
>>> On Fri, May 9, 2008 at 3:54 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
On 2008-05-08 22:55, Terry Reedy wrote:
> Functions that map unicode->unicode or bytes->bytes could be called
> transcoders.
bytes-
On 2008-05-14 19:43, Martin v. Löwis wrote:
Hardwiring the encoding is not a good idea, esp. since there
are lots of alternatives for you to get readable output from
PyUnicode object now and without any changes to the interpreter.
E.g.
print '%s' % u.encode('utf-8')
We are talking about Pytho
M.-A. Lemburg wrote:
On 2008-05-14 18:33, Georg Brandl wrote:
M.-A. Lemburg schrieb:
Fine, so we need new methods for PyUnicode and PyString objects
which allow encoding and decoding using the same type (and enforce
the return types).
Any suggestions ?
How about these:
str.str_encode() -> st
On Wed, May 14, 2008 at 2:39 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg wrote:
>>
>> On 2008-05-14 18:33, Georg Brandl wrote:
>>>
>>> M.-A. Lemburg schrieb:
Fine, so we need new methods for PyUnicode and PyString objects
which allow encoding and decoding using the sa
Wasn't there a big discussion once before about whether
encode/decode should be usable for things other than
unicode<->non-unicode transformations? I thought the
conclusion reached back then was that they shouldn't.
Is there some reason the transformations being talked
about can't just be provide
Jim Jewett writes:
> Maybe I'm missing something, but it seems to me that there are only a
> few logical combinations;
There are lots of logical combinations, but most of them fall into
"general transform", is that what you mean?
> if the below is wrong, maybe that is one
> reason unicode se
On Wed, May 14, 2008 at 5:16 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Wasn't there a big discussion once before about whether
> encode/decode should be usable for things other than
> unicode<->non-unicode transformations? I thought the
> conclusion reached back then was that they shouldn't.
Tha
Greg Ewing writes:
> Wasn't there a big discussion once before about whether
> encode/decode should be usable for things other than
> unicode<->non-unicode transformations? I thought the
> conclusion reached back then was that they shouldn't.
That group prevailed, but it was more like a WBA t
On Wed, May 14, 2008 at 8:00 PM, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> This discussion isn't about whether it could be done or not, it's
> about where people expect to find such functionality. Personally, if
> I can find .encode('euc-jp') on a string object, I would expect to
> find .en
16 matches
Mail list logo
