Re: [Python-Dev] cpython (merge 3.2 -> default): Avoid codec spelling issues by just using the utf-8 default.
On Thu, 05 May 2011 20:38:27 +0200 raymond.hettinger <python-checkins@python.org> wrote:
http://hg.python.org/cpython/rev/2bc784057226 changeset: 69858:2bc784057226 parent: 69856:b06ad8458b32 parent: 69857:1a56775c6e54 user: Raymond Hettinger <python@rcn.com> date: Thu May 05 11:38:06 2011 -0700 summary: Avoid codec spelling issues by just using the utf-8 default.
files: Lib/random.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Lib/random.py b/Lib/random.py --- a/Lib/random.py +++ b/Lib/random.py @@ -114,7 +114,7 @@ if version == 2: if isinstance(a, (str, bytes, bytearray)): if isinstance(a, str): - a = a.encode("utf-8") + a = a.encode()
Isn't explicit better than implicit? By reading the new code it is not obvious that any thought was given to the choice of a codec, while stating "utf-8" explicitly hints that a decision was made. (also, I don't understand the spelling issue: "utf-8" just works) Regards Antoine.
On Thu, May 5, 2011 at 2:44 PM, Antoine Pitrou <solipsis@pitrou.net> wrote: ..
(also, I don't understand the spelling issue: "utf-8" just works)
This is probably referring to the fact that while encode() accepts many spelling variants, some are short-circuited in C code while others require codec lookup implemented in python.
Le jeudi 05 mai 2011 à 15:01 -0400, Alexander Belopolsky a écrit :
On Thu, May 5, 2011 at 2:44 PM, Antoine Pitrou <solipsis@pitrou.net> wrote: ..
(also, I don't understand the spelling issue: "utf-8" just works)
This is probably referring to the fact that while encode() accepts many spelling variants, some are short-circuited in C code while others require codec lookup implemented in python.
This sounds like a bug to fix (isn't it fixed it already, btw?) rather than add hackish workarounds for in stdlib code. Regards Antoine.
2011/5/5 Alexander Belopolsky <alexander.belopolsky@gmail.com>:
On Thu, May 5, 2011 at 2:44 PM, Antoine Pitrou <solipsis@pitrou.net> wrote: ..
(also, I don't understand the spelling issue: "utf-8" just works)
This is probably referring to the fact that while encode() accepts many spelling variants, some are short-circuited in C code while others require codec lookup implemented in python.
Isn't it cached after the first run? If this is the reasoning, I find it hard to believe that seed() is a large bottleneck in random. -- Regards, Benjamin
participants (3)
-
Alexander Belopolsky -
Antoine Pitrou -
Benjamin Peterson