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 at 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 at 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 at python.org.
---------- Forwarded message ----------
From: anatoly techtonik <techtonik at gmail.com>
To: Alexandre Vassalotti <alexandre at 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 at 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 at 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 at 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 at 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 at 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 at 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 at python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/alexandre%40peadrop.com
>>
>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4