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
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), (b, o, x,
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
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
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
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
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's
On Fri, 17 Jan 2014 08:49:21 -0800
Ethan Furman et...@stoneleaf.us wrote:
PEP: 461
There are formatting issues in the HTML rendering, I think the ReST
code needs a bit massaging:
On 18 Jan 2014 11:52, Ethan Furman et...@stoneleaf.us 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
exceptions
On 01/18/2014 03:40 AM, Antoine Pitrou wrote:
On Fri, 17 Jan 2014 08:49:21 -0800
Ethan Furman et...@stoneleaf.us wrote:
PEP: 461
There are formatting issues in the HTML rendering, I think the ReST
code needs a
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
Ethan Furman et...@stoneleaf.us 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)
-
Steven D'Aprano st...@pearwood.info 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
On 01/18/2014 05:21 PM, Neil Schemenauer wrote:
Ethan Furman et...@stoneleaf.us 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:
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
On 19 January 2014 12:34, Ethan Furman et...@stoneleaf.us wrote:
On 01/18/2014 05:21 PM, Neil Schemenauer wrote:
Ethan Furman et...@stoneleaf.us wrote:
So, if %a is added it would act like:
-
%a % some_obj
-
tmp = str(some_obj)
res = b''
for ch in tmp:
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
On Fri, Jan 17, 2014 at 11:49 AM, Ethan Furman et...@stoneleaf.us 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 ;)
Ethan Furman et...@stoneleaf.us 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
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
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
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'abc'
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 to
Mark Lawrence breamore...@yahoo.co.uk 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
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)
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 in a
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
On Sat, Jan 18, 2014 at 12:51 PM, Ethan Furman et...@stoneleaf.us 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
On 01/17/2014 06:03 PM, Chris Angelico wrote:
On Sat, Jan 18, 2014 at 12:51 PM, Ethan Furman et...@stoneleaf.us 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~
+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
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
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? Presumably
32 matches
Mail list logo
