Martin, v. Löwis wrote:
>> How are users confused?
>
> Users do
>
> py> "Martin v. Löwis".encode("utf-8")
> Traceback (most recent call last):
> File "", line 1, in ?
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
> ordinal not in range(128)
>
> because they want to
Ron Adam <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Bengt Richter had a good idea with bytes.recode() for strictly bytes
> > transformations (and the equivalent for text), though it is ambiguous as
> > to the direction; are we encoding or decoding with bytes.recode()? In
> > my opinio
Aahz wrote:
> The problem is that they don't understand that "Martin v. L?wis" is not
> Unicode -- once all strings are Unicode, this is guaranteed to work.
This specific call, yes. I don't think the problem will go away as long
as both encode and decode are available for both strings and byte
arr
Josiah Carlson wrote:
> Bob Ippolito <[EMAIL PROTECTED]> wrote:
>>
>> On Feb 17, 2006, at 8:33 PM, Josiah Carlson wrote:
>>
>>> Greg Ewing <[EMAIL PROTECTED]> wrote:
Stephen J. Turnbull wrote:
>> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
> Guido> - b = bytes(t, en
On Fri, 17 Feb 2006 20:33:16 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
>Greg Ewing <[EMAIL PROTECTED]> wrote:
>>
>> Stephen J. Turnbull wrote:
>> >>"Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>>
>> > Guido> - b = bytes(t, enc); t = text(b, enc)
>> >
>> > +1 The cod
Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
>
> On Feb 17, 2006, at 8:33 PM, Josiah Carlson wrote:
>
> >
> > Greg Ewing <[EMAIL PROTECTED]> wrote:
> >>
> >> Stephen J. Turnbull wrote:
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
> >>
> >>> Guido> - b = bytes(t, enc); t =
On Fri, Feb 17, 2006, "Martin v. L?wis" wrote:
> Josiah Carlson wrote:
>>
>> How are users confused?
>
> Users do
>
> py> "Martin v. L?wis".encode("utf-8")
> Traceback (most recent call last):
> File "", line 1, in ?
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
> o
On Feb 17, 2006, at 8:33 PM, Josiah Carlson wrote:
>
> Greg Ewing <[EMAIL PROTECTED]> wrote:
>>
>> Stephen J. Turnbull wrote:
"Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>>
>>> Guido> - b = bytes(t, enc); t = text(b, enc)
>>>
>>> +1 The coding conversion operation has al
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Stephen J. Turnbull wrote:
> >>"Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>
> > Guido> - b = bytes(t, enc); t = text(b, enc)
> >
> > +1 The coding conversion operation has always felt like a constructor
> > to me, and in this parti
Stephen J. Turnbull wrote:
>>"Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
> Guido> - b = bytes(t, enc); t = text(b, enc)
>
> +1 The coding conversion operation has always felt like a constructor
> to me, and in this particular usage that's exactly what it is. I
> prefer the n
On Feb 17, 2006, at 4:20 PM, Martin v. Löwis wrote:
> Ian Bicking wrote:
>> Maybe it isn't worse, but the real alternative is:
>>
>> import zlib
>> import base64
>>
>> base64.b64encode(zlib.compress(s))
>>
>> Encodings cover up eclectic interfaces, where those interfaces fit a
>> basic patt
Martin v. Löwis wrote:
>>Maybe it isn't worse, but the real alternative is:
>>
>> import zlib
>> import base64
>>
>> base64.b64encode(zlib.compress(s))
>>
>>Encodings cover up eclectic interfaces, where those interfaces fit a
>>basic pattern -- data in, data out.
>
>
> So should I write
>
> 3
Ian Bicking wrote:
> Maybe it isn't worse, but the real alternative is:
>
> import zlib
> import base64
>
> base64.b64encode(zlib.compress(s))
>
> Encodings cover up eclectic interfaces, where those interfaces fit a
> basic pattern -- data in, data out.
So should I write
3.1415.encode("s
Martin v. Löwis wrote:
> Ian Bicking wrote:
>
>>That str.encode(unicode_encoding) implicitly decodes strings seems like
>>a flaw in the unicode encodings, quite seperate from the existance of
>>str.encode. I for one really like s.encode('zlib').encode('base64') --
>>and if the zlib encoding raise
Josiah Carlson wrote:
>>>If some users
>>>can't understand this (passing different arguments to a function may
>>>produce different output),
>>
>>It's worse than that. The return *type* depends on the *value* of
>>the argument. I think there is little precedence for that: normally,
>>the return val
Ian Bicking wrote:
> That str.encode(unicode_encoding) implicitly decodes strings seems like
> a flaw in the unicode encodings, quite seperate from the existance of
> str.encode. I for one really like s.encode('zlib').encode('base64') --
> and if the zlib encoding raised an error when it was passe
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > How are users confused?
>
> Users do
>
> py> "Martin v. Löwis".encode("utf-8")
> Traceback (most recent call last):
> File "", line 1, in ?
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
> o
Martin v. Löwis wrote:
> Users do
>
> py> "Martin v. Löwis".encode("utf-8")
> Traceback (most recent call last):
> File "", line 1, in ?
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
> ordinal not in range(128)
>
> because they want to convert the string "to Unicode
Josiah Carlson wrote:
> How are users confused?
Users do
py> "Martin v. Löwis".encode("utf-8")
Traceback (most recent call last):
File "", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
ordinal not in range(128)
because they want to convert the string "to
On Fri, 17 Feb 2006 21:35:25 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> wrote:
>M.-A. Lemburg wrote:
>> Just because some codecs don't fit into the string.decode()
>> or bytes.encode() scenario doesn't mean that these codecs are
>> useless or that the methods should be
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg wrote:
> > Just because some codecs don't fit into the string.decode()
> > or bytes.encode() scenario doesn't mean that these codecs are
> > useless or that the methods should be banned.
>
> No. The reason to ban string.decode and bytes
M.-A. Lemburg wrote:
> Just because some codecs don't fit into the string.decode()
> or bytes.encode() scenario doesn't mean that these codecs are
> useless or that the methods should be banned.
No. The reason to ban string.decode and bytes.encode is that
it confuses users.
Regards,
Martin
__
On Fri, 17 Feb 2006 00:33:49 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> wrote:
>Josiah Carlson wrote:
>> I would agree that zip is questionable, but 'uu', 'rot13', perhaps 'hex',
>> and likely a few others that the two of you may be arguing against
>> should stay as enc
Martin v. Löwis wrote:
> Josiah Carlson wrote:
>> I would agree that zip is questionable, but 'uu', 'rot13', perhaps 'hex',
>> and likely a few others that the two of you may be arguing against
>> should stay as encodings, because strictly speaking, they are defined as
>> encodings of data. They m
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
Guido> I'd say there are two "symmetric" API flavors possible (t
Guido> and b are text and bytes objects, respectively, where text
Guido> is a string type, either str or unicode; enc is an encoding
Guido> name):
Gui
On Feb 16, 2006, at 9:20 PM, Josiah Carlson wrote:
>
> Greg Ewing <[EMAIL PROTECTED]> wrote:
>>
>> Josiah Carlson wrote:
>>
>>> They may not be encodings of _unicode_ data,
>>
>> But if they're not encodings of unicode data, what
>> business do they have being available through
>> someunicodestri
On 2/15/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Actually users trying to figure out Unicode would probably be better served> if bytes.encode() and text.decode() did not exist.[...]It would be better if the signature of text.encode() always returned a
bytes object. But why deny the bytes
Josiah Carlson wrote:
> I would agree that zip is questionable, but 'uu', 'rot13', perhaps 'hex',
> and likely a few others that the two of you may be arguing against
> should stay as encodings, because strictly speaking, they are defined as
> encodings of data. They may not be encodings of _unico
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > They may not be encodings of _unicode_ data,
>
> But if they're not encodings of unicode data, what
> business do they have being available through
> someunicodestring.encode(...)?
I had always presumed that bytes objects ar
Josiah Carlson wrote:
> They may not be encodings of _unicode_ data,
But if they're not encodings of unicode data, what
business do they have being available through
someunicodestring.encode(...)?
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Jason Orendorff wrote:
>
> > Also the pseudo-encodings ('hex',
> > 'rot13', 'zip', 'uu', etc.) generally scare me.
>
> I think these will have to cease being implemented as
> encodings in 3.0. They should really never have been
> in the first place.
I wo
Jason Orendorff wrote:
> Also the pseudo-encodings ('hex',
> 'rot13', 'zip', 'uu', etc.) generally scare me.
I think these will have to cease being implemented as
encodings in 3.0. They should really never have been
in the first place.
--
Greg Ewing, Computer Science Dept, +---
On 2/15/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Jason Orendorff wrote:
> > Also the pseudo-encodings ('hex', 'rot13',
> > 'zip', 'uu', etc.) generally scare me.
>
> Those are not pseudo-encodings, they are regular codecs.
>
> It's a common misunderstanding that codecs are only seen as servin
On Wed, 2006-02-15 at 14:01 -0500, Jason Orendorff wrote:
> Instead of byte literals, how about a classmethod bytes.from_hex(),
> which works like this:
>
> # two equivalent things
> expected_md5_hash =
> bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
> expected_md5_hash = bytes([92, 83,
Jason Orendorff wrote:
> Instead of byte literals, how about a classmethod bytes.from_hex(), which
> works like this:
>
> # two equivalent things
> expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
> expected_md5_hash = bytes([92, 83, 80, 36, 202, 197, 25, 145, 83, 227,
Jason Orendorff wrote:
> expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
This looks good, although it duplicates
expected_md5_hash = binascii.unhexlify('5c535024cac5199153e3834fe5c92e6a')
Regards,
Martin
___
Python-Dev mailing
Jason Orendorff wrote:
> Instead of byte literals, how about a classmethod bytes.from_hex(), which
> works like this:
>
> # two equivalent things
> expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
I hope this will also be equivalent:
> expected_md5_hash = bytes.from_he
On 2/15/06, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> Instead of byte literals, how about a classmethod bytes.from_hex(), which
> works like this:
>
># two equivalent things
>expected_md5_hash =
> bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
>expected_md5_hash = bytes([92, 83,
Instead of byte literals, how about a classmethod bytes.from_hex(), which works like this:
# two equivalent things
expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
expected_md5_hash = bytes([92, 83, 80, 36, 202, 197, 25, 145, 83, 227, 131, 79, 229, 201, 46, 106])
It's
101 - 139 of 139 matches
Mail list logo
