<div dir="ltr"><p dir="ltr">On 13 Jan 2014 17:14, "Donald Stufft" <<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>> wrote:<br>
><br>
><br>
> On Jan 13, 2014, at 1:59 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> > On 13 January 2014 16:52, Donald Stufft <<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>> wrote:<br>
> >><br>
> >> On Jan 13, 2014, at 12:45 AM, Glenn Linderman <<a href="mailto:v%2Bpython@g.nevcal.com" target="_blank">v+python@g.nevcal.com</a>> wrote:<br>
> >><br>
> >> So then the question is whether to proceed with 3.4, delay this feature to<br>
> >> 3.5, or to delay 3.4 to include this feature, both have been discussed, with<br>
> >> the justification for the latter being to make 3.4 the ultimate Python 3<br>
> >> porting target for recalcitrant module authors, sooner than later.<br>
> >><br>
> >><br>
> >> I really hope this can make it in 3.4, needing to wait another 2 years or so<br>
> >> until this is available would be a shame.<br>
> ><br>
> > Indeed, it would be a shame to have to wait. Fortunately, people don't<br>
> > even need to wait until the release of Python 3.4, they can instead<br>
> > try to help out with the asciicompat project, which aims to provide<br>
> > this functionality in Python 3.3+:<br>
> > <a href="https://github.com/jeamland/asciicompat" target="_blank">https://github.com/jeamland/asciicompat</a><br>
> ><br>
> > All it takes is to let go of the idea "I wish the Python 3 bytes type<br>
> > was more like the Python 2 str type" and instead think "hmm, the<br>
> > Python 3 bytes type doesn't seem like a great fit for my use case,<br>
> > maybe I need a different type”.<br>
><br>
> It’s almost a fine fit for the usecase afaict the major thing it’s missing<br>
> is an easy way to handle this last use case. I don’t see how this proposal<br>
> is any different than cases such as int(b”1”). ASCII is already special,<br>
> giving an area that Python3 has made things worse a better way forward<br>
> isn’t comprising the text model, it’s recognizing the realities of the world.</p>
<p dir="ltr">The difference between this and int() is that there's no structural ambiguity introduced in the case of int(): the output is always an integer, regardless of the input type.</p>
<p dir="ltr">Arbitrary binary data and ASCII  compatible binary data are *different things* and the only argument in favour of modelling them with a single type is because Python 2 did it that way.</p>
<p dir="ltr">The Python 3 text model was built on the notion of "no implicit encoding and decoding", and Guido's more lenient proposal brings that back by stealth: the semantics proposed for the integer codes are that they be essentially equivalent to performing the operation in the text domain and then encoding with ASCII.</p>
<p>However, I'm OK with the idea if there are separate formatb/formatb_map APIs that allow the encoding support to be bypassed entirely - that way, using mod-formatting, format or format_map *is* explicit, since the only reason to use them over formatb/formatb_map would be for the implicit ASCII encoding support, eliminating the ambiguity.<br>
</p><p dir="ltr"></p>

<p dir="ltr">Regards,<br>
Nick.<br>
</p>
</div>