<div dir="ltr">On Tue, Jan 14, 2014 at 9:29 AM, Yury Selivanov <span dir="ltr"><<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - Try str(), and do ".encode(‘ascii’, ‘stcict’)” on the result.<br></blockquote><div><br></div><div style>please no -- that's the source of a lot of pain in py2 now.</div>

<div style><br></div><div style>having a failure as a result of the value, rather than the type, of an object just makes hard-to-test for bugs. Everything will be hunky dory for development and testing, then in deployment some idiot ( ;-) ) will pass in some non-ascii compatible string and you get  failure. And the person who gets the failure doesn't understand why, or they wouldn't have passed in non-ascii values in the first place...</div>

<div style><br></div><div style>Ease of porting is nice, but let's not make it easy to port bug-prone code.</div><div style><br></div><div style>-Chris</div><div style><br></div><div style><br></div><div style><br></div>

<div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
This way *most* of the use cases of python2 will be covered without<br>
touching the code. So:<br>
<br>
 - b’Hello {}’.format(‘world’) <br>
   will be the same as b’hello ‘ + str(‘world’).encode(‘ascii’, ‘strict’)<br>
<br>
 - b’Hello {}’.format(‘\u0394’) will throw UnicodeEncodeError<br>
<br>
 - b’Status: {}’.format(200)<br>
   will be the same as b’Status: ‘ + str(200).encode(‘ascii’, ‘strict’)<br>
<br>
 - b’Hello %s’ % (‘world’,) - the same as the first example<br>
<br>
 - b’Connection: {}’.format(b’keep-alive’) - works<br>
<br>
 - b’Hello %s’ % (b'\xce\x94’,) - will fail, not ASCII subset we accept<br>
<br>
I think it’s OK to check the buffers for ASCII-subset only. Yes, it<br>
will have some sort of sub-optimal performance, but then, it’s quite<br>
rare when string formatting is used to concatenate huge buffers.<br>
<br>
2. new operators {!b} and %b. This ones will just use ‘__bytes__’ and <br>
Py_buffer.<br>
<br>
--<br>
Yury Selivanov<br>
<br>
On January 14, 2014 at 11:31:51 AM, Brett Cannon (<a href="mailto:brett@python.org">brett@python.org</a>) wrote:<br>
><br>
> On Mon, Jan 13, 2014 at 5:14 PM, Guido van Rossum<br>
> wrote:<br>
><br>
> > On Mon, Jan 13, 2014 at 2:05 PM, Brett Cannon<br>
> wrote:<br>
> > > I have been going on the assumption that bytes.format() would<br>
> change what<br>
> > > '{}' meant for itself and would only interpolate bytes. That<br>
> convenient<br>
> > > between Python 2 and 3 since it represents what we want it to<br>
> (str and<br>
> > bytes<br>
> > > under the hood, respectively), so it just falls through. We<br>
> could also<br>
> > add a<br>
> > > 'b' conversion for bytes() explicitly so as to help people<br>
> not<br>
> > accidentally<br>
> > > mix up things in bytes.format() and str.format(). But I was<br>
> not<br>
> > suggesting<br>
> > > adding a specific format spec for bytes but instead making<br>
> bytes.format()<br>
> > > just do the .encode('ascii') automatically to help with compatibility<br>
> > when a<br>
> > > format spec was present. If people want fancy formatting for<br>
> bytes they<br>
> > can<br>
> > > always do it themselves before calling bytes.format().<br>
> ><br>
> > This seems hastily written (e.g. verb missing :-), and I'm not<br>
> clear<br>
> > on what you are (or were) actually proposing. When exactly would<br>
> > bytes.format() need .encode('ascii')?<br>
> ><br>
> > I would be happy to wait a few hours or days for you to to write it<br>
> up<br>
> > clearly, rather than responding in a hurry.<br>
><br>
><br>
> Sorry about that. Busy day at work + trying to stay on top of this<br>
> entire<br>
> conversation was a bit tough. Let me try to lay out what I'm suggesting<br>
> for<br>
> bytes.format() in terms of how it changes<br>
> <a href="http://docs.python.org/3/library/string.html#format-string-syntax" target="_blank">http://docs.python.org/3/library/string.html#format-string-syntax</a><br>
> for bytes.<br>
><br>
> 1. New conversion operator of 'b' that operates as PEP 460 specifies<br>
> (i.e.<br>
> tries to get a buffer, else calls __bytes__). The default conversion<br>
> changes from 's' to 'b'.<br>
> 2. Use of the conversion field adds an added step of calling<br>
> str.encode('ascii', 'strict') on the result returned from<br>
> calling<br>
> __format__().<br>
><br>
> That's it. So point 1 means that the following would work in Python<br>
> 3.5::<br>
><br>
> b'Hello, {}, how are you?'.format(b'Guido')<br>
> b'Hello, {!b}, how are you?'.format(b'Guido')<br>
><br>
> It would produce an error if you used a text argument for 'Guido'<br>
> since str<br>
> doesn't define __bytes__ or a buffer. That gives the EIBTI group<br>
> their<br>
> bytes.format() where nothing magical happens.<br>
><br>
> For point 2, let's say you have the following in Python 2::<br>
><br>
> 'I have {} bottles of beer on the wall'.format(10)<br>
><br>
> Under my proposal, how would you change it to get the same result<br>
> in Python<br>
> 2 and 3?::<br>
><br>
> b'I have {:d} bottles of beer on the wall'.format(10)<br>
><br>
> In Python 2 you're just being more explicit about the format,<br>
> otherwise<br>
> it's the same semantics as today. In Python 3, though, this would<br>
> translate<br>
> into (under the hood)::<br>
><br>
> b'I have {} bottles of beer on the wall'.format(format(10,<br>
> 'd').encode('ascii', 'strict'))<br>
><br>
> This leads to the same bytes value in Python 2 (since it's just<br>
> a string)<br>
> and in Python 3 (as everything accepted by bytes.format() is<br>
> either bytes<br>
> already or converted to from encoding to ASCII bytes). While<br>
> Python 2 users<br>
> would need to make sure they used a format spec to get the same result<br>
> in<br>
> both Python 2 and 3 for ASCII bytes, it's a minor change which also<br>
> makes<br>
> the format more explicit so it's not an inherently bad thing.<br>
> And for those<br>
> that don't want to utilize the automatic ASCII encoding they<br>
> can just not<br>
> use a format spec in the format string and just pass in bytes directly<br>
> (i.e. call __format__() themselves and then call str.encode()<br>
> on their<br>
> own). So PBP people get to have a simple way to use bytes.format()<br>
> in<br>
> Python 2 and 3 when dealing with things that can be represented<br>
> as ASCII<br>
> (just as the bytes methods allow for currently).<br>
><br>
> I think this covers your desire to have numbers and anything else<br>
> that can<br>
> be represented as ASCII be supported for easy porting while covering<br>
> my<br>
> desire that any automatic encoding is clearly explicit in the<br>
> format string<br>
> and in no way special-cased for only some types (the introduction<br>
> of a 'c'<br>
> converter from PEP 460 is also fine with me).<br>
><br>
> How you would want to translate this proposal with the % operator<br>
> I'm not<br>
> sure since it has been quite a while since I last seriously used<br>
> it and so<br>
> I don't think I'm in a good position to propose a shift for it.<br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">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>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com" target="_blank">https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com</a><br>
><br>
<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">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>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov" target="_blank">https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>

Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a>
</div></div>