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

[Brett Cannon]

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? =)

-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/20140106/bbcf2928/attachment.html>