On 13 Jan 2014 17:14, "Donald Stufft" <don...@stufft.io> wrote: > > > On Jan 13, 2014, at 1:59 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > > On 13 January 2014 16:52, Donald Stufft <don...@stufft.io> wrote: > >> > >> On Jan 13, 2014, at 12:45 AM, Glenn Linderman <v+pyt...@g.nevcal.com> wrote: > >> > >> So then the question is whether to proceed with 3.4, delay this feature to > >> 3.5, or to delay 3.4 to include this feature, both have been discussed, with > >> the justification for the latter being to make 3.4 the ultimate Python 3 > >> porting target for recalcitrant module authors, sooner than later. > >> > >> > >> I really hope this can make it in 3.4, needing to wait another 2 years or so > >> until this is available would be a shame. > > > > Indeed, it would be a shame to have to wait. Fortunately, people don't > > even need to wait until the release of Python 3.4, they can instead > > try to help out with the asciicompat project, which aims to provide > > this functionality in Python 3.3+: > > https://github.com/jeamland/asciicompat > > > > All it takes is to let go of the idea "I wish the Python 3 bytes type > > was more like the Python 2 str type" and instead think "hmm, the > > Python 3 bytes type doesn't seem like a great fit for my use case, > > maybe I need a different type”. > > It’s almost a fine fit for the usecase afaict the major thing it’s missing > is an easy way to handle this last use case. I don’t see how this proposal > is any different than cases such as int(b”1”). ASCII is already special, > giving an area that Python3 has made things worse a better way forward > isn’t comprising the text model, it’s recognizing the realities of the world.
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. 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. 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. 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. Regards, Nick.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
