Mark a few PEP 3100 items as done, update PEP 358 wrt. bytes literals.
This commit is contained in:
parent
d50d640d85
commit
9884c6cbf2
18
pep-0358.txt
18
pep-0358.txt
|
@ -84,12 +84,10 @@ Specification
|
|||
return new
|
||||
|
||||
The .__repr__() method returns a string that can be evaluated to
|
||||
generate a new bytes object containing the same sequence of
|
||||
integers. The sequence is represented by a list of ints using
|
||||
hexadecimal notation. For example:
|
||||
generate a new bytes object containing a bytes literal:
|
||||
|
||||
>>> repr(bytes[10, 20, 30])
|
||||
'bytes([0x0a, 0x14, 0x1e])'
|
||||
>>> bytes([10, 20, 30])
|
||||
b'\n\x14\x1e'
|
||||
|
||||
The object has a .decode() method equivalent to the .decode()
|
||||
method of the str object. The object has a classmethod .fromhex()
|
||||
|
@ -98,14 +96,14 @@ Specification
|
|||
example:
|
||||
|
||||
>>> bytes.fromhex('5c5350ff')
|
||||
bytes([92, 83, 80, 255]])
|
||||
b'\\SP\xff'
|
||||
>>> bytes.fromhex('5c 53 50 ff')
|
||||
bytes([92, 83, 80, 255]])
|
||||
b'\\SP\xff'
|
||||
|
||||
The object has a .hex() method that does the reverse conversion
|
||||
(similar to binascii.hexlify):
|
||||
|
||||
>> bytes([92, 83, 80, 255]]).hex()
|
||||
>> bytes([92, 83, 80, 255]).hex()
|
||||
'5c5350ff'
|
||||
|
||||
The bytes object has some methods similar to list method, and
|
||||
|
@ -198,8 +196,6 @@ Open Issues
|
|||
|
||||
* Should all those list methods really be implemented?
|
||||
|
||||
* Now that a b"..." literal exists, shouldn't repr() return one?
|
||||
|
||||
* A case could be made for supporting .ljust(), .rjust(),
|
||||
.center() with a mandatory second argument.
|
||||
|
||||
|
@ -219,7 +215,7 @@ Open Issues
|
|||
Frequently Asked Questions
|
||||
|
||||
Q: Why have the optional encoding argument when the encode method of
|
||||
Unicode objects does the same thing.
|
||||
Unicode objects does the same thing?
|
||||
|
||||
A: In the current version of Python, the encode method returns a str
|
||||
object and we cannot change that without breaking code. The
|
||||
|
|
|
@ -103,7 +103,7 @@ Core language
|
|||
with __builtin__. Keeping both with confusingly similar spellings
|
||||
and semantics is evil.
|
||||
* Attributes on functions of the form ``func_whatever`` will be renamed
|
||||
``__whatever__`` [17]_
|
||||
``__whatever__`` [17]_ [done]
|
||||
* Set literals and comprehensions [19]_ [20]_ [done]
|
||||
{x} means set([x]); {x, y} means set([x, y]).
|
||||
{F(x) for x in S if P(x)} means set(F(x) for x in S if P(x)).
|
||||
|
@ -143,10 +143,9 @@ Atomic Types
|
|||
literals with 'L' or 'l' suffix disappear [1]_ [done]
|
||||
* Make all strings be Unicode, and have a separate bytes() type [1]_
|
||||
The new string type will be called 'str'.
|
||||
* Return iterators instead of lists where appropriate for atomic type methods
|
||||
* Return iterable views instead of lists where appropriate for atomic type methods
|
||||
(e.g. ``dict.keys()``, ``dict.values()``, ``dict.items()``, etc.); iter*
|
||||
methods will be removed.
|
||||
Better: make keys(), etc. return views ala Java collections???
|
||||
methods will be removed. [done]
|
||||
* Make ``string.join()`` stringify its arguments? [18]_
|
||||
* Fix file() so it returns a ValueError if the mode is bad rather than IOError.
|
||||
(This probably affects lots of places, we should review the exceptions
|
||||
|
|
Loading…
Reference in New Issue