[Python-Dev] PEP 461 Final? (original) (raw)
Steven D'Aprano steve at pearwood.info
Sat Jan 18 02:27:53 CET 2014
- Previous message: [Python-Dev] PEP 461 Final?
- Next message: [Python-Dev] PEP 461 Final?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 Unicode representation [3].
I don't understand this paragraph. What does "values contained in a Unicode representation" mean?
[...]
%s is restricted in what it will accept::
- input type supports Pybuffer? use it to collect the necessary bytes
Can you give some examples of what types support Py_buffer? Presumably bytes. Anything else?
- input type is something else? use its bytes method; if there isn't one, raise a TypeError
I think you should explicitly state that this is a new special method, and state which built-in types will grow a bytes method (if any).
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, 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 radically different from the behaviour of Python 3 str. In Python 3, '%d' interpolation calls the str method, so if you subclass, you can get the behaviour you want:
py> class HexInt(int): ... def str(self): ... return hex(self) ... py> "%d" % HexInt(23) '0x17'
which is exactly what we should expect from a subclass.
You're suggesting that bytes should ignore any custom display implemented by subclasses, and implicitly coerce them to the superclass int. What is the justification for this? You don't define or even describe what you consider "properly handle".
Unsupported codes -----------------
%r (which calls repr), and %a (which calls ascii() on repr) are not supported.
+1 on not supporting b'%r' (i.e. I agree with the PEP).
Why not support b'%a'? That seems to be a strange thing to prohibit.
Everythng else, well done and thank you.
-- Steven
- Previous message: [Python-Dev] PEP 461 Final?
- Next message: [Python-Dev] PEP 461 Final?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]