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