[Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Nick Coghlan ncoghlan at gmail.com
Mon Jan 6 16:08:37 CET 2014


On 6 Jan 2014 22:56, "Brett Cannon" <brett at python.org> wrote:
>
>
>
>
> On Mon, Jan 6, 2014 at 9:45 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>
>> On 6 Jan 2014 22:15, "Brett Cannon" <brett at python.org> wrote:
>> >
>> >
>> >
>> >
>> > On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou <solipsis at pitrou.net>
wrote:
>> >>
>> >> On Tue, 7 Jan 2014 00:54:17 +1100
>> >> Chris Angelico <rosuav at gmail.com> wrote:
>> >> > On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou <solipsis at pitrou.net>
wrote:
>> >> > > BTW, there's a subtlety here: ``%s`` currently means "insert the
result
>> >> > > of calling __str__", but bytes formatting should *not* call
__str__.
>> >> >
>> >> > Since it derives from the C printf notation, it means "insert string
>> >> > here". The fact that __str__ will be called is secondary to that. I
>> >> > would say it's not a problem for bytes formatting to call __bytes__,
>> >> > or in some other way convert to bytes without calling __str__.
>> >> >
>> >> > Will it be confusing to have bytes and str supporting distinctly
>> >> > different format operations? Might it be better to instead create a
>> >> > separate and very different method on a bytes, just to emphasize the
>> >> > difference?
>> >>
>> >> The people who want bytes formatting, AFAICT, want something that is
>> >> reasonably 2.x-compatible. That means using the same method / operator
>> >> and calling conventions.
>> >
>> >
>> > Right, but that also doesn't mean that a library from the Cheeseshop
couldn't be provided which works around any Python 2/3 differences. But my
suspicion is anyone requesting this feature (e.g. Mercurial) want it
implemented in C for performance and so some pure Python library to help
with this won't get any traction.
>>
>> Right, but it seems to me that a new helper module that could be made
backwards compatible at least as far as 2.6 (if not further) would be more
useful for that than a builtin change that won't be available until 2015. I
think we have enough experience with Python 3 now to say yes, there are
still some significant gaps in the support it offers for wire protocol
development.
>
>
> True, or at least we should be very clear as to how we expect people to
do binary packing in Python 3 (Victor's PEP says struct doesn't work, so
should that be fixed, etc.). That will help figure out where the holes are
currently.
>
>>
>> We have been hoping others would volunteer to fill that gap, but it's
getting to the point where we need to start thinking about handling it
ourselves by providing a hybrid Python/C helper module specifically for
wire protocol programming.
>
> Probably. And it can work around any shortcomings we fix in Python 3.5.
>
>>
>> An encodedstr type wouldn't implicitly interoperate with the builtins
(until we finally fix the sequence operand coercion bug in CPython) but
could at least handle formatting operations like this.
>
>
> You really want that type, don't you? =)

I still don't think the 2.x  bytestring is inherently evil, it's just the
wrong type to use as the core text type because of the problems it has with
silently creating mojibake and also with multi-byte codecs and slicing. The
current python-ideas thread is close to convincing me even a stripped down
version isn't a good idea, though :P

Cheers,
Nick.

>
> -Brett
>
>>
>> Cheers,
>> Nick.
>>
>> >
>> > _______________________________________________
>> > Python-Dev mailing list
>> > Python-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/python-dev
>> > Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140107/213d1271/attachment.html>


More information about the Python-Dev mailing list