(original) (raw)


On 6 Jan 2014 22:56, "Brett Cannon" <brett@python.org> wrote:
\>
\>
\>
\>
\> On Mon, Jan 6, 2014 at 9:45 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
\>>
\>>
\>> On 6 Jan 2014 22:15, "Brett Cannon" <brett@python.org> wrote:
\>> >
\>> >
\>> >
\>> >
\>> > On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
\>> >>
\>> >> On Tue, 7 Jan 2014 00:54:17 +1100
\>> >> Chris Angelico <rosuav@gmail.com> wrote:
\>> >> > On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou <solipsis@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@python.org
\>> > https://mail.python.org/mailman/listinfo/python-dev
\>> > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
\>> >
\>
\>