[Python-Dev] PEP 460 reboot

Nick Coghlan ncoghlan at gmail.com
Mon Jan 13 12:08:36 CET 2014

On 13 Jan 2014 17:14, "Donald Stufft" <donald at stufft.io> wrote:
> On Jan 13, 2014, at 1:59 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On 13 January 2014 16:52, Donald Stufft <donald at stufft.io> wrote:
> >>
> >> On Jan 13, 2014, at 12:45 AM, Glenn Linderman <v+python at g.nevcal.com>
> >>
> >> 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
> >> 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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140113/a47eaba6/attachment.html>

More information about the Python-Dev mailing list