<p dir="ltr"><br>
On 2 Apr 2014 22:01, "Donald Stufft" <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
><br>
><br>
> On Apr 2, 2014, at 7:40 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
><br>
>><br>
>> On 2 Apr 2014 12:52, "Ethan Furman" <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br>
>> ><br>
>> > On 04/01/2014 09:30 AM, Guido van Rossum wrote:<br>
>> ><br>
>> >>>> On Sat, Mar 29, 2014 at 7:17 PM, Nick Coghlan wrote:<br>
>> >>>>><br>
>> >>>>><br>
>> >>>>>  x = bytes.byte(data[0])<br>
>> >><br>
>> >><br>
>> >> Hm. I don't find that very attractive. You can't write Python 2/3 code using that idiom, and it's a lot longer than the<br>
>> >> original. The only redeeming feature is that it clearly fails when data is empty, and possibly that you don't have to<br>
>> >> compute the second index (which could be awkward if the first index is an expression).<br>
>> >><br>
>> >> I'm not denying that we need bytes.byte(), but this doesn't sound like much of a motivation. Just pointing to the need<br>
>> >> of bytes/bytestring equivalents for chr() makes more sense to me.<br>
>> ><br>
>> ><br>
>> > We already have ord() and chr() -- maybe we should just add byte().<br>
>><br>
>> I thought of that, but it seems like a recipe for typos and confusion. bytes.byte and bytearray.byte seem clearer and safer.<br>
>><br>
>> Cheers,<br>
>> Nick.<br>
>><br>
>><br>
><br>
> I don’t like byte(), way to much potential for confusion with bytes(), but maybe bchr() is a reasonable thing.</p>
<p dir="ltr">There's no need for it to be a builtin at all. The class method alternative constructor approach handles the problem just fine.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> -----------------<br>
> Donald Stufft<br>
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
><br>
</p>