There has been a vast and echoing silence about the ascii.py module I posted here at Fred Drake's request. Is it really such a bad idea? -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy
On Thu, 1 Jun 2000, Eric S. Raymond wrote:
There has been a vast and echoing silence about the ascii.py module I posted here at Fred Drake's request. Is it really such a bad idea?
Don't look at me. I'm busy working on inspect and htmldoc. :) Actually, i guess i probably didn't respond because it isn't of immediate use to me. Maybe this is the sort of thing that might come in handy one day but that hordes of people aren't desperate for. Hmm. Perhaps it's because people are used to saying "in string.digits" instead of wanting isdigit() &c. Hmm. Perhaps it's also something that ought to be eventually handled via the Unicode character property route. Dunno. -- ?!ng "China is a big country, inhabited by many Chinese." -- Former French President Charles de Gaulle
On Thu, 1 Jun 2000, Eric S. Raymond wrote:
There has been a vast and echoing silence about the ascii.py module I posted here at Fred Drake's request. Is it really such a bad idea?
hehe... I'd say silence implies a +0 from people ("seems reasonable to go in, but I wouldn't be upset if it doesn't"). If people thought it was bad, then you'd hear about it :-) I took a quick look at it. Doesn't seem too bad, but I can't think of anything that I've done in a long while that would require it. So I can't really say "wow! put that baby in the distro!" YMMV, of course :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Greg Stein <gstein@lyra.org>:
I took a quick look at it. Doesn't seem too bad, but I can't think of anything that I've done in a long while that would require it. So I can't really say "wow! put that baby in the distro!"
It starts to get pretty useful in conjunction with curses -- for example, in writing interpreters for character-at-a-time command loops. I have a new version that adds the following: \begin{funcdesc}{ascii}{c} Return the ASCII value corresponding to the low 7 bits of c. \end{funcdesc} The following function takes either a single-character string or integer byte value; it returns a string. \begin{funcdesc}{unctrl}{c} Return a string representation of the ASCII character c. If c is printable, this string is the character itself. If the character is a control character (0x00-0x1f) the string consists of a caret (^) followed by the corresponding uppercase letter. If the character is an ASCII delete (0x7f) the string is "^?". If the character has its meta bit (0x80) set, the meta bit is stripped, the preceding rules applied, and "!" prepended to the result. \end{funcdesc} Finally, the module supplies a 33-element string array called controlnames that contains the ASCII mnemonics for the thirty-two ASCII control characters from 0 (NUL) to 0x1f (US), in order, plus the mnemonic "SP" for space. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Certainly one of the chief guarantees of freedom under any government, no matter how popular and respected, is the right of the citizens to keep and bear arms. [...] the right of the citizens to bear arms is just one guarantee against arbitrary government and one more safeguard against a tyranny which now appears remote in America, but which historically has proved to be always possible. -- Hubert H. Humphrey, 1960
On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote:
There has been a vast and echoing silence about the ascii.py module I posted here at Fred Drake's request. Is it really such a bad idea?
One misgiving I had was locales; is it a bug or a feature that locales aren't supported, as they are for the C isdigit(), isalpha(), &c, functions? I'm not entirely sure which it is. (The locale module doesn't expose the C is*() functions, though I think they're used in constructing string.letters.) --amk
Andrew Kuchling <akuchlin@cnri.reston.va.us>:
On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote:
There has been a vast and echoing silence about the ascii.py module I posted here at Fred Drake's request. Is it really such a bad idea?
One misgiving I had was locales; is it a bug or a feature that locales aren't supported, as they are for the C isdigit(), isalpha(), &c, functions? I'm not entirely sure which it is. (The locale module doesn't expose the C is*() functions, though I think they're used in constructing string.letters.)
It's a feature. That's why this module is called ascii, not string :-) -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),
Andrew Kuchling wrote:
On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote:
There has been a vast and echoing silence about the ascii.py module I posted here at Fred Drake's request. Is it really such a bad idea?
One misgiving I had was locales; is it a bug or a feature that locales aren't supported, as they are for the C isdigit(), isalpha(), &c, functions? I'm not entirely sure which it is. (The locale module doesn't expose the C is*() functions, though I think they're used in constructing string.letters.)
FYI, both strings and Unicode object already have a few .isXXX() methods: isdigit(), islower(), isspace(), istitle(), isupper() For strings these use the C APIs (which are locale aware), for Unicode the built in mappings are used. BTW, I haven't looked at the docs lately, but are the string and Unicode methods already documented ? All of them have doc-strings, so it should be easy extracting the data to build a TeX-file. On the topic of adding ascii.py, I'm +0 -- I don't currently have a need for it, but writing .append(ascii.CR + ascii.LF) does add to the readability of scripts. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
"Eric S. Raymond" wrote:
There has been a vast and echoing silence about the ascii.py module I posted here at Fred Drake's request. Is it really such a bad idea?
Without looking closely, or even being particularly knowledgable (how's that for a disclaimer!) my instinctive reaction was: "does the ASCII subset of Unicode need its own module just before we add Unicode to the language?" It may be that there are some semantics of ASCII that are not captured in the Unicode spec. and thus are not generalizable. I'm pretty confident that these ones ARE generalizable: isalnum isalpha isascii islower isupper isspace isxdigit How do Unicode users get this information from the famous Unicode database and why not merge the Unicode and ASCII versions in 1.6? -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html
Paul Prescod <paul@prescod.net>:
"Eric S. Raymond" wrote:
There has been a vast and echoing silence about the ascii.py module I posted here at Fred Drake's request. Is it really such a bad idea?
Without looking closely, or even being particularly knowledgable (how's that for a disclaimer!) my instinctive reaction was: "does the ASCII subset of Unicode need its own module just before we add Unicode to the language?"
It may be that there are some semantics of ASCII that are not captured in the Unicode spec. and thus are not generalizable.
ascii.ctrl is one such.
I'm pretty confident that these ones ARE generalizable:
isalnum isalpha isascii islower isupper isspace isxdigit
How do Unicode users get this information from the famous Unicode database and why not merge the Unicode and ASCII versions in 1.6?
Answer: ascii.py is not designed for text processing. I wrote it to package some functions useful for classifying *ASCII* data, especially in the context of roguelike programs that interpret keystrokes coming in through a curses interface. (Where this all touches ground is CML2, my replacement configuration system for the Linux kernel.) -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> ..every Man has a Property in his own Person. This no Body has any Right to but himself. The Labour of his Body, and the Work of his Hands, we may say, are properly his. .... The great and chief end therefore, of Mens uniting into Commonwealths, and putting themselves under Government, is the Preservation of their Property. -- John Locke, "A Treatise Concerning Civil Government"
Paul Prescod wrote:
"Eric S. Raymond" wrote:
There has been a vast and echoing silence about the ascii.py module I posted here at Fred Drake's request. Is it really such a bad idea?
Without looking closely, or even being particularly knowledgable (how's that for a disclaimer!) my instinctive reaction was: "does the ASCII subset of Unicode need its own module just before we add Unicode to the language?"
It may be that there are some semantics of ASCII that are not captured in the Unicode spec. and thus are not generalizable. I'm pretty confident that these ones ARE generalizable:
isalnum isalpha isascii islower isupper isspace isxdigit
How do Unicode users get this information from the famous Unicode database and why not merge the Unicode and ASCII versions in 1.6?
Note that many of the above are already implemented as string|Unicode methods. The Unicode database is accessible via the unicodedata module. The specs for the used APIs and constants can be found in the Unicode database description file on www.unicode.org. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
participants (8)
-
Andrew Kuchling -
Eric S. Raymond -
Eric S. Raymond -
Fred L. Drake, Jr. -
Greg Stein -
Ka-Ping Yee -
M.-A. Lemburg -
Paul Prescod