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
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
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-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 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
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-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
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:
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 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
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 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 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 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 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 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 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,
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-
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
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
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
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
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,
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
"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: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
I need help to finish implementing PEP 3108. While over 80 modules are
now deprecated in Python 2.6 (of which I did over 50 of), there are
still over 20 tasks left to do in relation to the PEP. My free time is
being sucked away since I have a conference paper deadline of June 1.
And I am moving May
28 matches
Mail list logo
