Fwd: Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
Don't you think it is a bad idea to require people to subscribe to post to python-ideas of redirected there? -- anatoly t. ---------- Forwarded message ---------- From: <python-ideas-owner@python.org> Date: Mon, Jul 26, 2010 at 11:24 PM Subject: Re: [Python-Dev] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib) To: techtonik@gmail.com You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at python-ideas-owner@python.org. ---------- Forwarded message ---------- From: anatoly techtonik <techtonik@gmail.com> To: Alexandre Vassalotti <alexandre@peadrop.com> Date: Mon, 26 Jul 2010 23:24:15 +0300 Subject: Re: [Python-Dev] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib) On Mon, Jul 26, 2010 at 9:42 PM, Alexandre Vassalotti <alexandre@peadrop.com> wrote:
[+Python-ideas -Python-Dev]
import binascii def h(s): return binascii.unhexlify("".join(s.split()))
h("DE AD BE EF CA FE BA BE")
The idea is to make "print f.read(50)" usable. Your current solution is: -Beautiful is better than ugly. -Explicit is better than implicit. -Simple is better than complex. Complex is better than complicated. Flat is better than nested. -Sparse is better than dense. -Readability counts. Special cases aren't special enough to break the rules. -Although practicality beats purity. Errors should never pass silently. ... -- anatoly t.
-- Alexandre
On Mon, Jul 26, 2010 at 11:29 AM, anatoly techtonik <techtonik@gmail.com> wrote:
I find "\xXX\xXX\xXX\xXX..." notation for binary data totally unreadable. Everybody who uses and analyses binary data is more familiar with plain hex dumps in the form of "XX XX XX XX...".
I wonder if it is possible to introduce an effective binary string type that will be represented as h"XX XX XX" in language syntax? It will be much easier to analyze printed binary data and copy/paste such data as-is from hex editors/views.
On Mon, Jul 19, 2010 at 9:45 AM, Guido van Rossum <guido@python.org> wrote:
Sounds like a good idea to try to remove redundant cookies *and* to remove most occasional use of non-ASCII characters outside comments (except for unittests specifically trying to test Unicode features). Personally I would use \xXX escapes instead of spelling out the characters in shlex.py, for example.
Both with or without the coding cookies, many ways of displaying text files garble characters outside the ASCII range, so it's better to stick to ASCII as much as possible.
--Guido
On Mon, Jul 19, 2010 at 1:21 AM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
I was looking at the inspect module and noticed that it's source starts with "# -*- coding: iso-8859-1 -*-". I have checked and there are no non-ascii characters in the file. There are several other modules that still use the cookie:
Lib/ast.py:# -*- coding: utf-8 -*- Lib/getopt.py:# -*- coding: utf-8 -*- Lib/inspect.py:# -*- coding: iso-8859-1 -*- Lib/pydoc.py:# -*- coding: latin-1 -*- Lib/shlex.py:# -*- coding: iso-8859-1 -*- Lib/encodings/punycode.py:# -*- coding: utf-8 -*- Lib/msilib/__init__.py:# -*- coding: utf-8 -*- Lib/sqlite3/__init__.py:#-*- coding: ISO-8859-1 -*- Lib/sqlite3/dbapi2.py:#-*- coding: ISO-8859-1 -*- Lib/test/bad_coding.py:# -*- coding: uft-8 -*- Lib/test/badsyntax_3131.py:# -*- coding: utf-8 -*-
I understand that coding: utf-8 is strictly redundant in 3.x. There are cases such as Lib/shlex.py where using encoding other than utf-8 is justified. (See http://svn.python.org/view?view=rev&revision=82560). What are the guidelines for other cases? Should redundant cookies be removed? Since not all editors respect the -*- cookie, I think the answer should be "yes" particularly when the cookie is setting encoding other than utf-8. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/alexandre%40peadrop.com
Am 26.07.2010 22:28, schrieb anatoly techtonik:
Don't you think it is a bad idea to require people to subscribe to post to python-ideas of redirected there?
It doesn't matter *why* you post to a mailing list -- you just have to be subscribed to post. Whoever redirects you there is usually not in the position of automatically subscribing anyone, and most people wouldn't much like being subscribed automatically, don't you think? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
anatoly techtonik writes:
Don't you think it is a bad idea to require people to subscribe to post to python-ideas of redirected there?
No, it's an excellent compromise in the current environment. On lists I manage (with a similar audience to python-dev), my MTA-level filters get 95% of the spam, the member test catches essentially all of the rest. On support lists, I moderate, mostly because drive-by posters usually post in HTML which is another 95% accurate signal of spam. On the dev lists, they get rejected on the principle that drive-by posts to a dev list *are* spam. If you want to post a quick RFE, that's what the tracker is for; people will see your brainstorm when they get around to looking at the tracker, but it just isn't urgent at all. This works well, yours is the first complaint about this kind of policy that I've seen in four or five years.
participants (3)
-
anatoly techtonik -
Georg Brandl -
Stephen J. Turnbull