Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #6409 > unrolled thread

Re: [Python-ideas] Adding 'bytes' as alias for 'latin_1' codec.

Started byMRAB <python@mrabarnett.plus.com>
First post2011-05-27 17:21 +0100
Last post2011-05-27 17:21 +0100
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [Python-ideas] Adding 'bytes' as alias for 'latin_1' codec. MRAB <python@mrabarnett.plus.com> - 2011-05-27 17:21 +0100

#6409 — Re: [Python-ideas] Adding 'bytes' as alias for 'latin_1' codec.

FromMRAB <python@mrabarnett.plus.com>
Date2011-05-27 17:21 +0100
SubjectRe: [Python-ideas] Adding 'bytes' as alias for 'latin_1' codec.
Message-ID<mailman.2152.1306513320.9059.python-list@python.org>
On 27/05/2011 10:27, Nick Coghlan wrote:
> On Fri, May 27, 2011 at 6:46 PM, Stephen J. Turnbull<stephen@xemacs.org>  wrote:
>>   >  What method is invoked to convert the numbers to text? What encoding
>>   >  is used to convert those numbers to text? How does this operation
>>   >  avoid also converting the *bytes* object to text and then reencoding
>>   >  it?
>>
>> OTOH, Nick, aren't you making this harder than it needs to be?  After
>> all,
>
> To me, the defining feature of str.format() over str.__mod__() is the
> ability for types to provide their own __format__ methods, rather than
> being limited to a predefined set of types known to the interpreter.
> If bytes were to reuse the same name, then I'd want to see similar
> flexibility.
>
> Now, a *different* bytes method (bytes.interpolate, perhaps?), limited
> to specific types may make sense, but such an alternative *shouldn't*
> be conflated with the text formatting API.
>
> However, proponents of such an addition need to clearly articulate
> their use cases and proposed solution in a PEP to make it clear that
> they aren't merely trying to perpetuate the bytes/text confusion that
> plagues 2.x 8-bit strings.
>
> We can almost certainly do better when it comes to constructing byte
> sequences from component parts, but simply saying "oh, just add a
> format() method to bytes objects" doesn't cut it, since the associated
> magic methods for str.format are all string based, and bytes
> interpolation also needs to address encoding issues for anything that
> isn't already a byte sequence.
>
I would've thought that a "format" (or equivalent) method for bytes
would work like struct.pack, so b"{0}".format(23) wouldn't return
b'23', but you could have:

 >>> b'{0:b}'.format(23)
b'\x17'

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web