Showing content from http://mail.python.org/pipermail/python-dev/attachments/20140106/bbcf2928/attachment.html below:
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 6, 2014 at 9:45 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><p dir="ltr"><br>
On 6 Jan 2014 22:15, "Brett Cannon" <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
><br>
><br>
><br>
><br>
> On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>> wrote:<br>
>><br>
>> On Tue, 7 Jan 2014 00:54:17 +1100<br>
>> Chris Angelico <<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>> wrote:<br>
>> > On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>> wrote:<br>
>> > > BTW, there's a subtlety here: ``%s`` currently means "insert the result<br>
>> > > of calling __str__", but bytes formatting should *not* call __str__.<br>
>> ><br>
>> > Since it derives from the C printf notation, it means "insert string<br>
>> > here". The fact that __str__ will be called is secondary to that. I<br>
>> > would say it's not a problem for bytes formatting to call __bytes__,<br>
>> > or in some other way convert to bytes without calling __str__.<br>
>> ><br>
>> > Will it be confusing to have bytes and str supporting distinctly<br>
>> > different format operations? Might it be better to instead create a<br>
>> > separate and very different method on a bytes, just to emphasize the<br>
>> > difference?<br>
>><br>
>> The people who want bytes formatting, AFAICT, want something that is<br>
>> reasonably 2.x-compatible. That means using the same method / operator<br>
>> and calling conventions.<br>
><br>
><br>
> 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.</p>
</div></div><p dir="ltr">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.</p>
</blockquote><div><br></div><div>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.</div>
<div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">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.</p>
</blockquote><div>Probably. And it can work around any shortcomings we fix in Python 3.5.</div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">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.</p></blockquote>
<div><br></div><div>You really want that type, don't you? =)</div><div><br></div><div>-Brett</div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr"></p><div class="im">><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br></div>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com" target="_blank">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
><br>
<p></p>
</blockquote></div><br></div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4