On 01/19/2014 11:10 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
> > This argument is specious.
>
> I don't think so. I think it's a good argument for the future of
> Python code.
I agree that restricting bytes '%'-formatting to ASCII is a good idea,
but you should base your arg
Ethan Furman writes:
> > This argument is specious.
>
> I don't think so. I think it's a good argument for the future of
> Python code.
I agree that restricting bytes '%'-formatting to ASCII is a good idea,
but you should base your arguments on a correct description of what's
going on. It'
On 01/19/2014 06:56 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
Well, that means that this PEP just further strengthens the notion
that format is for text (as then a custom numeric type could easily
override the display even for :d, :h, etc.) and % is for bytes
(where such glyphs are no
Ethan Furman writes:
> Well, that means that this PEP just further strengthens the notion
> that format is for text (as then a custom numeric type could easily
> override the display even for :d, :h, etc.) and % is for bytes
> (where such glyphs are not natively representable anyway).
This ar
On 01/19/2014 03:37 AM, Steven D'Aprano wrote:
On Fri, Jan 17, 2014 at 05:51:05PM -0800, Ethan Furman wrote:
On 01/17/2014 05:27 PM, Steven D'Aprano wrote:
Numeric Format Codes
To properly handle int and float subclasses, int(), index(), and float()
will be called on the
On 01/19/2014 03:37 AM, Steven D'Aprano wrote:
On Fri, Jan 17, 2014 at 05:51:05PM -0800, Ethan Furman wrote:
On 01/17/2014 05:27 PM, Steven D'Aprano wrote:
Numeric Format Codes
To properly handle int and float subclasses, int(), index(), and float()
will be called on the
On Fri, Jan 17, 2014 at 05:51:05PM -0800, Ethan Furman wrote:
> On 01/17/2014 05:27 PM, Steven D'Aprano wrote:
> >>Numeric Format Codes
> >>
> >>
> >>To properly handle int and float subclasses, int(), index(), and float()
> >>will be called on the objects intended for (d, i, u
On 19 January 2014 12:34, Ethan Furman wrote:
> On 01/18/2014 05:21 PM, Neil Schemenauer wrote:
>>
>> Ethan Furman wrote:
>>>
>>> So, if %a is added it would act like:
>>>
>>> -
>>> "%a" % some_obj
>>> -
>>> tmp = str(some_obj)
>>> res = b''
>>> for ch in tmp:
>>>
On 01/18/2014 02:01 PM, Ethan Furman wrote:
where 'unicode_escape' would yield something like "\u0440" ?
Just to be clear, "\u0440" is the six bytes b'\\', b'u', b'0', b'4', b'4', b'0'.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
ht
On 01/18/2014 05:21 PM, Neil Schemenauer wrote:
Ethan Furman wrote:
So, if %a is added it would act like:
-
"%a" % some_obj
-
tmp = str(some_obj)
res = b''
for ch in tmp:
if ord(ch) < 256:
res += bytes([ord(ch)]
else:
res
Steven D'Aprano wrote:
>> To properly handle int and float subclasses, int(), index(), and float()
>> will be called on the objects intended for (d, i, u), (b, o, x, X), and
>> (e, E, f, F, g, G).
>
>
> -1 on this idea.
>
> This is a rather large violation of the principle of least surprise, and
Ethan Furman wrote:
> So, if %a is added it would act like:
>
> -
>"%a" % some_obj
> -
>tmp = str(some_obj)
>res = b''
>for ch in tmp:
>if ord(ch) < 256:
>res += bytes([ord(ch)]
>else:
>res += unicode_escape(ch)
> -
>
On 01/18/2014 05:48 AM, Nick Coghlan wrote:
On 18 Jan 2014 11:52, "Ethan Furman" wrote:
I'll admit to being somewhat on the fence about %a.
It seems there are two possibilities with %a:
1) have it be ascii(repr(obj))
2) have it be str(obj).encode('ascii', 'strict')
This gets very close
On 01/18/2014 03:40 AM, Antoine Pitrou wrote:
On Fri, 17 Jan 2014 08:49:21 -0800
Ethan Furman wrote:
PEP: 461
There are formatting issues in the HTML rendering, I think the ReST
code needs a bit massaging:
http:/
On 18 Jan 2014 11:52, "Ethan Furman" wrote:
>
> On 01/17/2014 05:27 PM, Steven D'Aprano wrote:
>>
>> On Fri, Jan 17, 2014 at 08:49:21AM -0800, Ethan Furman wrote:
>>>
>>>
>>> Overriding Principles
>>> =
>>>
>>> In order to avoid the problems of auto-conversion and Unicode
>>> e
On Fri, 17 Jan 2014 08:49:21 -0800
Ethan Furman wrote:
>
> PEP: 461
There are formatting issues in the HTML rendering, I think the ReST
code needs a bit massaging:
http://www.python.org/dev/peps/pep-0461/
> .. note:
Steven D'Aprano, 18.01.2014 02:27:
> On Fri, Jan 17, 2014 at 08:49:21AM -0800, Ethan Furman wrote:
>> %s is restricted in what it will accept::
>>
>> - input type supports Py_buffer?
>> use it to collect the necessary bytes
>
> Can you give some examples of what types support Py_buffer? Pres
Nick Coghlan writes:
> I also suggest introducing the phrase "ASCII compatible
> segments in binary formats" somewhere,
What is the use case for "ASCII *compatible* segments"? Can't you
just say "ASCII segments"?
I'm not sure exactly what PEP 461 says at this point, but most of the
discussion
+1 on the technical spec from me. The rationale needs work, but you already
know that :)
For API consistency, I suggest explicitly noting that bytearray will also
support the operation, generating a bytearray result.
I also suggest introducing the phrase "ASCII compatible segments in binary
forma
On 01/17/2014 06:03 PM, Chris Angelico wrote:
On Sat, Jan 18, 2014 at 12:51 PM, Ethan Furman wrote:
It seems there are two possibilities with %a:
1) have it be ascii(repr(obj))
Wouldn't that be redundant? ascii() is already repr()-like.
Good point.
--
~Ethan~
__
On Sat, Jan 18, 2014 at 12:51 PM, Ethan Furman wrote:
> It seems there are two possibilities with %a:
>
> 1) have it be ascii(repr(obj))
Wouldn't that be redundant? ascii() is already repr()-like.
ChrisA
___
Python-Dev mailing list
Python-Dev@python.
On 01/17/2014 05:27 PM, Steven D'Aprano wrote:
On Fri, Jan 17, 2014 at 08:49:21AM -0800, Ethan Furman wrote:
Overriding Principles
=
In order to avoid the problems of auto-conversion and Unicode
exceptions that could plague Py2 code, all object checking will
be done by duck
On Fri, Jan 17, 2014 at 08:49:21AM -0800, Ethan Furman wrote:
> Overriding Principles
> =
>
> In order to avoid the problems of auto-conversion and Unicode exceptions
> that
> could plague Py2 code, all object checking will be done by duck-typing, not
> by
> values contained
On 01/17/2014 08:53 AM, Brett Cannon wrote:
Don't abbreviate; spell out "Python 2".
Fixed.
Originally this PEP also proposed adding format style formatting, but it was
"format-style"
Fixed.
decided that format and its related machinery were all strictly text (aka
str)
ba
Mark Lawrence wrote:
> Using %b could cause problems in the future as b is used in new style
> formatting to mean output numbers in binary, so %B seems to me the
> obvious choice as it's also unused.
After updating my patch, I've decided that %s works better. My
patch implements PEP 461 as pro
On 01/17/2014 11:40 AM, Glenn Linderman wrote:
On 1/17/2014 8:49 AM, Ethan Furman wrote:
>>> b'%s' % 3.14
Traceback (most recent call last):
...
TypeError: 3.14 has no __bytes__ method
If you produce a helpful error message for str (re: encoding), might it not be
appropriate
On 1/17/2014 8:49 AM, Ethan Furman wrote:
%s is restricted in what it will accept::
- input type supports Py_buffer?
use it to collect the necessary bytes
- input type is something else?
use its __bytes__ method; if there isn't one, raise a TypeError
Examples:
>>> b'%s' % b'ab
On 01/17/2014 09:46 AM, Neil Schemenauer wrote:
Rational
"Rationale". "Rational" is an adjective, "Rationale" is a noun.
Pedantically yours,
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mail
On 17/01/2014 17:46, Neil Schemenauer wrote:
I think we should use %b instead of %s. In that case, I'm fine with
%b not accepting numbers. Using %b clearly indicates we are
inserting arbitrary bytes. It also proves a useful code review step
when translating from Python 2.x.
Using %b could
Ethan Furman wrote:
> Overriding Principles
>=
>
> In order to avoid the problems of auto-conversion and Unicode exceptions that
> could plague Py2 code, all object checking will be done by duck-typing, not by
> values contained in a Unicode representation [3]_.
I think a long
On Fri, Jan 17, 2014 at 11:49 AM, Ethan Furman wrote:
> Here's the text for your reading pleasure. I'll commit the PEP after I
> add some markup.
>
> Major change:
>
> - dropped `format` support, just using %-interpolation
>
> Coming soon:
>
> - Rationale section ;)
>
>
Here's the text for your reading pleasure. I'll commit the PEP after I add
some markup.
Major change:
- dropped `format` support, just using %-interpolation
Coming soon:
- Rationale section ;)
PEP: 461
Tit
32 matches
Mail list logo
