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
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
28 matches
Mail list logo
