Jim Jewett writes:
> On 5/26/08, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> > Jim Jewett writes:
>
> > > The only reason for this change is that __repr__ gets used when
> > > __str__ *should* be used instead.
>
> > That's not what the advocates say.
>
> I still haven't seen a
Jim Jewett wrote:
PEP 3138 says that repr should start printing unicode glyphs.
I say that repr should (insetad) start recognizing when it was called
in place of __str__, and should revert back to __str__ when it
recurses down to the next level.
But we *don't* all agree that the only case whe
M.-A. Lemburg wrote:
AFAIK, eval(repr(obj)) is no longer a requirement... simply because
it has always only worked for a small subset of objects and in
reality, you wouldn't want to call eval() on anything too often
due to the security implications.
Yes, I actually think that sentence in the d
Jim Jewett wrote:
So I suggest that he or she use str, rather than repr -- and that we
fix containers to make this possible.
And hope that every other author of a Python container class on the
planet does the same thing?
Recursing downwards with str() instead of repr() will break as soon as
On Tue, May 27, 2008 at 03:04:02PM -0500, Jeffrey Yasskin wrote:
> On Tue, May 27, 2008 at 2:33 PM, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > I say that repr should (insetad) start recognizing when it was called
> > in place of __str__, and should revert back to __str__ when it
> > recurses down to
On Tue, May 27, 2008 at 2:33 PM, Jim Jewett <[EMAIL PROTECTED]> wrote:
> I say that repr should (insetad) start recognizing when it was called
> in place of __str__, and should revert back to __str__ when it
> recurses down to the next level.
That sounds like a PEP you should write, which, if acce
On 5/27/08, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-05-27 05:02, Stephen J. Turnbull wrote:
> > ... repr() Spanish and Chinese users are going to feel more or less
> > differently from Americans about which characters should be escaped.
> I'm not sure that's always the case, but users
On 5/27/08, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Mon, May 26, 2008 at 8:13 PM, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > The problem is classes where str(x) != repr(x), and how they get
> > messed up when a container holding (one of their) instances is
> > printed.
> class A:
> >>
On 5/26/08, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Jim Jewett writes:
> > The only reason for this change is that __repr__ gets used when
> > __str__ *should* be used instead.
> That's not what the advocates say.
I still haven't seen a use case where it *should* be using repr *and*
On 5/26/08, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Jim Jewett wrote:
> > The problem is classes where str(x) != repr(x), and how they get
> > messed up when a container holding (one of their) instances is
> > printed.
> This is NOT a bug, since str([1, 2, 3]) and str(list("123")) SHOULD produc
Jim Jewett writes:
> > Otherwise, they might grumble about the fact that what
> > they're seeing isn't English, but it doesn't matter whether it's
> > hex-escaped or kanji.
>
> I'm more worried that it might look like English, yet be subtly (and
> importantly) different.
Let me remind y
> Not that difficult. Suppose I have the character Ó, I just do
>
> py> unicodedata.name(u"Ó")
> 'CYRILLIC CAPITAL LETTER SCHWA'
>
> I used cut-n-paste to insert the character into the interactive prompt;
> that worked just fine.
I suppose, if I knew about unicodedata.name(), and if my cursed
> The nice thing about hex-escaped characters is that I can look up the
> character code to find out what the character is. Hard to do that
> with a glyph that I don't recognize.
Not that difficult. Suppose I have the character Ә, I just do
py> unicodedata.name(u"Ә")
'CYRILLIC CAPITAL LETTER SCH
> Atsuo Ishimoto writes:
>
> > Yes. My question is "Which do you feel comfortable, printing collect
> > glyphs or hex-escaped ASCII ?". I prefer printed glyphs for foreign
> > characters, but I had feeling that western people prefer hex-escaped
> > ASCII in general. But from responses I saw, p
On Sat, May 24, 2008 at 09:18:14PM +0400, Oleg Broytmann wrote:
> On Sat, May 24, 2008 at 12:53:08PM -0400, Jim Jewett wrote:
> > if I want pretty, I'll use print (or pprint).
>
>str(container_of_strings) uses repr(), so you loose prettiness on either
> print or '%s' % container_of_strings. Ex
On Sat, May 24, 2008 at 12:53:08PM -0400, Jim Jewett wrote:
> if I want pretty, I'll use print (or pprint).
str(container_of_strings) uses repr(), so you loose prettiness on either
print or '%s' % container_of_strings. Exceptions use repr() for file names,
e.g., which is very inconvenient, IMHO
On 5/24/08, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Atsuo Ishimoto writes:
> > Yes. My question is "Which do you feel comfortable, printing collect
> > glyphs or hex-escaped ASCII ?". I prefer printed glyphs for foreign
> > characters, but I had feeling that western people prefer he
Atsuo Ishimoto writes:
> Yes. My question is "Which do you feel comfortable, printing collect
> glyphs or hex-escaped ASCII ?". I prefer printed glyphs for foreign
> characters, but I had feeling that western people prefer hex-escaped
> ASCII in general. But from responses I saw, perhaps this
Terry Reedy wrote:
"Atsuo Ishimoto" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Yes. My question is "Which do you feel comfortable, printing collect
| glyphs or hex-escaped ASCII ?". I prefer printed glyphs for foreign
| characters, but I had feeling that western people prefer
"Atsuo Ishimoto" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Yes. My question is "Which do you feel comfortable, printing collect
| glyphs or hex-escaped ASCII ?". I prefer printed glyphs for foreign
| characters, but I had feeling that western people prefer hex-escaped
| ASCII
On Fri, May 23, 2008 at 7:04 PM, Atsuo Ishimoto <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 5:42 AM, Stephen J. Turnbull <[EMAIL PROTECTED]>
> wrote:
>> Atsuo Ishimoto writes:
>> > 2008/5/23 Guido van Rossum <[EMAIL PROTECTED]>:
>> > > Personally, I can live with it. I rarely generate J
On Sat, May 24, 2008 at 5:42 AM, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Atsuo Ishimoto writes:
> > 2008/5/23 Guido van Rossum <[EMAIL PROTECTED]>:
> > > Personally, I can live with it. I rarely generate Japanese text so I
> > > doubt it'll be a problem. I can also change the console en
Atsuo Ishimoto writes:
> 2008/5/23 Guido van Rossum <[EMAIL PROTECTED]>:
> > Personally, I can live with it. I rarely generate Japanese text so I
> > doubt it'll be a problem. I can also change the console encoding and
> > error handler.
>
> While you rarely generate Japanese text, but I gue
2008/5/23 Guido van Rossum <[EMAIL PROTECTED]>:
> Personally, I can live with it. I rarely generate Japanese text so I
> doubt it'll be a problem. I can also change the console encoding and
> error handler.
While you rarely generate Japanese text, but I guess you often get
non-ASCII text data e.g.
On Fri, May 23, 2008 at 12:28 AM, Atsuo Ishimoto <[EMAIL PROTECTED]> wrote:
> On Fri, May 23, 2008 at 1:30 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
>>> One point still remains is default error handler for sys.stdout. I can
>>> live with 'strict' error handler, but I think raising exception
On Fri, May 23, 2008 at 1:30 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> One point still remains is default error handler for sys.stdout. I can
>> live with 'strict' error handler, but I think raising exceptions for
>> evenry un-supported characters by default is too exacting.
>
> I think t
On Thu, May 22, 2008 at 6:46 PM, Atsuo Ishimoto <[EMAIL PROTECTED]> wrote:
> On Fri, May 23, 2008 at 6:18 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
2. If you don't want any non-ASCII printed to a file, set the file's
encoding to ASCII and the error handler to backslashescape.
>>
>
On Fri, May 23, 2008 at 6:18 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>> 2. If you don't want any non-ASCII printed to a file, set the file's
>>> encoding to ASCII and the error handler to backslashescape.
>
> On Thu, May 22, 2008 at 12:59 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>> S
> Le jeudi 22 mai 2008 à 10:55 -0700, Guido van Rossum a écrit :
>> Is this thread reaching a conclusion yet? I am hoping I can soon
>> accept some variant of the following:
>>
>> 1. repr() returns a Unicode string containing only printable Unicode
>> characters, using \x\u\U escapes for characters
On Thu, May 22, 2008 at 1:56 PM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> On Thu, May 22, 2008 at 10:41:34PM +0200, "Martin v. L?wis" wrote:
>> Would "encoding/errorhandler" sound like a useful syntax?
>
> encoding:errorhandler
Whichever character is guaranteed never to be part of an encoding
On Thu, May 22, 2008 at 10:41:34PM +0200, "Martin v. L?wis" wrote:
> Would "encoding/errorhandler" sound like a useful syntax?
encoding:errorhandler
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die, they just GOSUB without
> Is Martin's proposal to allow forcing the default stdin/stdout/stderr
> encodings through environment variables related? (It should allow for
> setting the error handler too.)
It's related only if it supports setting the error handler as well.
Would "encoding/errorhandler" sound like a useful s
> The Unicode consortium usually uses the terms "UCS2" and "UCS4"
> when referring to Unicode as "character set", but even there
> you have an ordering which makes it an encoding.
The Unicode consortium uses the term "coded character set" to describe
the assignment of characters in the set to numb
Le jeudi 22 mai 2008 à 10:55 -0700, Guido van Rossum a écrit :
> Hi folks,
>
> Is this thread reaching a conclusion yet? I am hoping I can soon
> accept some variant of the following:
>
> 1. repr() returns a Unicode string containing only printable Unicode
> characters, using \x\u\U escapes for c
On 2008-05-22 19:55, Guido van Rossum wrote:
Hi folks,
Is this thread reaching a conclusion yet? I am hoping I can soon
accept some variant of the following:
1. repr() returns a Unicode string containing only printable Unicode
characters, using \x\u\U escapes for characters that are not
conside
On 2008-05-22 19:52, Stephen J. Turnbull wrote:
M.-A. Lemburg writes:
> On 2008-05-22 13:58, Antoine Pitrou wrote:
> > M.-A. Lemburg egenix.com> writes:
> >> It's all a matter of perspective. You can say you're encoding Latin-1
> >> to Unicode, or you can say your encoding Unicode to Latin-1
Hi folks,
Is this thread reaching a conclusion yet? I am hoping I can soon
accept some variant of the following:
1. repr() returns a Unicode string containing only printable Unicode
characters, using \x\u\U escapes for characters that are not
considered printable according to some version of the
M.-A. Lemburg writes:
> On 2008-05-22 13:58, Antoine Pitrou wrote:
> > M.-A. Lemburg egenix.com> writes:
> >> It's all a matter of perspective. You can say you're encoding Latin-1
> >> to Unicode, or you can say your encoding Unicode to Latin-1.
> >
> > Except that Latin-1 is an encoding wh
On 2008-05-22 13:58, Antoine Pitrou wrote:
M.-A. Lemburg egenix.com> writes:
It's all a matter of perspective. You can say you're encoding Latin-1
to Unicode, or you can say your encoding Unicode to Latin-1.
Except that Latin-1 is an encoding while Unicode is not. So I don't see how you
can e
M.-A. Lemburg egenix.com> writes:
>
> It's all a matter of perspective. You can say you're encoding Latin-1
> to Unicode, or you can say your encoding Unicode to Latin-1.
Except that Latin-1 is an encoding while Unicode is not. So I don't see how you
can encode to Unicode. Of course you can enco
> So you would like to force users to write e.g.
>
> def uu(input,errors='strict',filename='',mode=0666):
> from cStringIO import StringIO
> from binascii import b2a_uu
> # using str() because of cStringIO's Unicode undesired Unicode
> behavior.
> infile = StringIO(str(input))
>
On 2008-05-19 23:03, Martin v. Löwis wrote:
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
On 2008-05-20 03:59, Greg Ewing wrote:
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 f
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
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
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.
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
> 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/untr
Greg Ewing writes:
> So it already needs some application-specific notion of
> what constitutes a probable compression method built
> into it, and if that list is to be extensible, it needs
> an application-specific registry to manage it. Once
> you've got that, the general codec registry doe
Stephen J. Turnbull wrote:
Do you really think that .transform clients will really choose
'base64' when they want 'lzma'?
It depends on who the "client" is. An application popping
up a list of compression methods is just going to confuse
users if it lists "base64" as a possibility.
So it alre
Greg Ewing writes:
> If you're choosing a compression method, it makes sense
> to choose 'zip', 'gzip', or 'bzip2', but less sense to
> choose 'hex' or 'base64',
Doesn't "consenting adults" cover choosing a nonsensical compressor?
Do you really think that .transform clients will really choose
Greg Ewing wrote:
Nick Coghlan wrote:
Having to mess around with __import__ just to support a "choose
compression method" configuration option would be fairly annoying.
Perhaps, but even then, I'm not sure it makes sense to
lump them all into the same namespace.
If you're choosing a compress
On 2008-05-17 10:26, Greg Ewing wrote:
Nick Coghlan wrote:
Having to mess around with __import__ just to support a "choose
compression method" configuration option would be fairly annoying.
Perhaps, but even then, I'm not sure it makes sense to
lump them all into the same namespace.
Note th
Nick Coghlan wrote:
Having to mess around with __import__ just to support a "choose
compression method" configuration option would be fairly annoying.
Perhaps, but even then, I'm not sure it makes sense to
lump them all into the same namespace.
If you're choosing a compression method, it make
Joel Bender writes:
> > Fiddling with the name of the antonym doesn't help.
> > The direction of "untransform" or whatever it's
> > called is only as clear as the direction of
> > "transform".
>
> How about making the transformation parameter more descriptive?
>
> gzipped = plaintext
I wrote:
...and it doesn't have to be reflexive if that...
Umm, that should have said 'have an inverse', which is different than
reflexive or symmetric. I get a little lost on 'surjective' and
'injective', having been taught the terms 'onto' and 'one-to-one'. But
I digress.
For wrapping
Greg Ewing wrote:
There's nothing wrong with that, but what it doesn't
answer is why it's not sufficient just to do things
like
from gzip import gzip_codec
stream2 = BytesTransform(gzip_codec, stream1)
i.e. why there has to be a special kind of namespace
for codecs.
Selecting an encoding is t
Fiddling with the name of the antonym doesn't help.
The direction of "untransform" or whatever it's
called is only as clear as the direction of
"transform".
How about making the transformation parameter more descriptive?
gzipped = plaintext.transform(plaintext_to_gzip)
plaintext = gzipped
On 16 May 2008, at 08:31, Greg Ewing wrote:
Fiddling with the name of the antonym doesn't help.
How about adding a direction indicator?
gzipped = plaintext.transformto("gzip")
plaintext = gzipped.transformfrom("gzip")
Mark
___
Python-3000
Terry Reedy wrote:
Would you prefer re_transform, which is English?
Fiddling with the name of the antonym doesn't help.
The direction of "untransform" or whatever it's
called is only as clear as the direction of
"transform".
--
Greg
___
Python-3000
On Thu, May 15, 2008 at 10:21 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Greg Ewing" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | Guido van Rossum wrote:
> |
> | > Really? Don't you think it's pretty obvious that b.transform("gzip")
> | > compresses and b.untransform("gzip
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Guido van Rossum wrote:
|
| > Really? Don't you think it's pretty obvious that b.transform("gzip")
| > compresses and b.untransform("gzip") decompresses? Or that
| > b.transform("base64") generates base64 format?
|
| Well,
On Thu, May 15, 2008 at 10:46 PM, Greg Ewing
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
>> Really? Don't you think it's pretty obvious that b.transform("gzip")
>> compresses and b.untransform("gzip") decompresses? Or that
>> b.transform("base64") generates base64 format?
>
> Well, maybe
Guido van Rossum wrote:
Really? Don't you think it's pretty obvious that b.transform("gzip")
compresses and b.untransform("gzip") decompresses? Or that
b.transform("base64") generates base64 format?
Well, maybe. I think the problem is that the word
"transform" is inherently direction-neutral,
Paul Moore wrote:
The key point for me is that
print(repr(arbitrary_string)) is *guaranteed* to display correctly,
even on my limited-capability terminal, precisely because it only uses
ASCII and no matter how dumb, all terminals I know of display ASCII.
That still sounds like something that th
On Thu, May 15, 2008 at 4:30 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg wrote:
>>
>> str.transform() -> str (uses the encode function of the codec)
>> str.untransform() -> str (uses the decode function of the codec)
>
> Not sure I like those names. It's rather unclear which
> d
Nick Coghlan wrote:
What this approach allows you to do is have
generic 'transformation' layers in your IO stack, so you can just build
up your IO stack as something like:
XMLParserIO('myschema')
BufferedTextIO('utf-8')
BytesTransform('gzip')
RawSocketIO
There's nothing wrong with that, but
M.-A. Lemburg wrote:
str.transform() -> str (uses the encode function of the codec)
str.untransform() -> str (uses the decode function of the codec)
Not sure I like those names. It's rather unclear which
direction is "transform" and which is "untransform".
People seem to have trouble eno
Paul Moore wrote:
On 15/05/2008, Atsuo Ishimoto <[EMAIL PROTECTED]> wrote:
I would like to call it "improve", not break :)
Please can you help me understand the impact here. I am running
Windows XP (UK English - console code page 850, which is some variety
of Latin 1). Currently, printing non-
On Fri, May 16, 2008 at 1:49 AM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 15/05/2008, Atsuo Ishimoto <[EMAIL PROTECTED]> wrote:
>> I would like to call it "improve", not break :)
>
> Please can you help me understand the impact here. I am running
> Windows XP (UK English - console code page 850,
On Thu, May 15, 2008 at 05:53:39PM +0100, Paul Moore wrote:
> One point I forgot to clarify is that I'm fully aware that
> print(arbitrary_string) may display garbage, if the string contains
> Unicode that my display can't handle. The key point for me is that
> print(repr(arbitrary_string)) is *gua
On Thu, May 15, 2008 at 05:49:06PM +0100, Paul Moore wrote:
> Like it or not, a large proportion of Python's users still work in
> environments where much of the Unicode character space is not
> displayed readably.
How large is that "large proportion"? 10%? 50%? 90%? How often users
working in
On 15/05/2008, Paul Moore <[EMAIL PROTECTED]> wrote:
> My apologies if I misunderstood your proposal - I have almost no
> Unicode experience, and that probably shows :-)
One point I forgot to clarify is that I'm fully aware that
print(arbitrary_string) may display garbage, if the string contains
U
On 15/05/2008, Atsuo Ishimoto <[EMAIL PROTECTED]> wrote:
> I would like to call it "improve", not break :)
Please can you help me understand the impact here. I am running
Windows XP (UK English - console code page 850, which is some variety
of Latin 1). Currently, printing non-latin1 characters gi
On Thu, May 15, 2008 at 1:18 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> 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 ou
On Thu, May 15, 2008 at 3:06 AM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 15/05/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> Consider code that gets an encoding passed in as a
>> variable e. It knows it has a bytes instance b. To encode b from bytes
>> to str (unicode), it can use s = b.d
On 2008-05-15 15:42, Nick Coghlan wrote:
M.-A. Lemburg wrote:
The .transform() methods would simply check for the corresponding
type combination, ie. str.transform() would check for (str, str).
str.encode() would check for (str, bytes), bytes.decode() for
(bytes, str).
Alternatively, we could j
M.-A. Lemburg wrote:
The .transform() methods would simply check for the corresponding
type combination, ie. str.transform() would check for (str, str).
str.encode() would check for (str, bytes), bytes.decode() for
(bytes, str).
Alternatively, we could just not check the type combinations
at all
On 2008-05-15 13:01, Nick Coghlan wrote:
M.-A. Lemburg wrote:
I'll write up a PEP once we have a better understanding of the
details, e.g. of how the codec type information should be
defined...
Here's a straight-forward approach:
codecinfo.encode_type_combinations = [(bytes, bytes), (str, str)
M.-A. Lemburg wrote:
I'll write up a PEP once we have a better understanding of the
details, e.g. of how the codec type information should be
defined...
Here's a straight-forward approach:
codecinfo.encode_type_combinations = [(bytes, bytes), (str, str)]
codecinfo.decode_type_combinations = [(b
On 2008-05-15 12:06, Paul Moore wrote:
On 15/05/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Consider code that gets an encoding passed in as a
variable e. It knows it has a bytes instance b. To encode b from bytes
to str (unicode), it can use s = b.decode(e).
To encode, you use .decode?
Greg Ewing wrote:
Stephen J. Turnbull 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 .encode('gzip') on a bytes object, too.
W
On 2008-05-15 11:12, Stephen J. Turnbull wrote:
Greg Ewing writes:
> What I'm not seeing is a clear rationale on where you
> draw the line. Out of all the possible transformations
> between a string and some other kind of data, which
> ones deserve to be available via this rather strange
>
On 15/05/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Consider code that gets an encoding passed in as a
> variable e. It knows it has a bytes instance b. To encode b from bytes
> to str (unicode), it can use s = b.decode(e).
To encode, you use .decode? It's nice to know it's not just me wh
On 2008-05-14 23:42, Guido van Rossum wrote:
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 d
Greg Ewing writes:
> What I'm not seeing is a clear rationale on where you
> draw the line. Out of all the possible transformations
> between a string and some other kind of data, which
> ones deserve to be available via this rather strange
> and special interface, and why?
I don't know nuth
Stephen J. Turnbull 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 .encode('gzip') on a bytes object, too.
What I'm not seeing
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
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 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
1 - 100 of 124 matches
Mail list logo
