Mailman 3 June 2000 - Python-Dev

[Fwd: Re: Case sensitivity]
by Paul Prescod 08 Jun '00

08 Jun '00

Here's a good summary of how XML's case sensitivity came to be. -------- Original Message -------- Subject: Re: Case sensitivity Date: Mon, 3 Apr 2000 12:44:37 -0400 From: Steve DeRose <Steven_DeRose(a)brown.edu> To: xml-dev(a)lists.oasis-open.org References: <B50E2EFA.1B57%soord(a)vda.nl> Languages with no need for case folding are not much of a problem: the case-folding table or program would merely have no effect on characters belonging to such languages: It would change 26 of our 26 alphabetic code points, and no others. After all, in English we already use lots of characters that don't get case-folded (like digits). The serious problems are subtler: The practical problem that with Unicode your folding table gets really big; on the order of 128Kbytes instead of 256 bytes (barring compresson): this is a pain on small devices (like a cell-phone browser), a pain to load, a pain to implement compression for, etc. The theoretical problem is more important: it's not the caseless languages that pose problems, but the complicated case-folding ones. For example, lots of languages only apply diacritical marks to lower-case letters: for example, "a" may come with 6 different accents, but "A" takes none -- which makes case-folding unreversible. If there are languages that operate the other way as well, then neither fold-to-upper nor fold-to-lower can work for all languages: either way would trash some languages. That said, I think it incumbent on XML *search engines* to support case-folding (as well as decent treatment of accents, types of hyphens, etc) for text content searches: Making English speakers search for "the" | "thE" | "tHe" | "tHE" | "The" | "ThE" | "THe" | "THE" or "[tT][hH][eE] is patently absurd; and besides, there is no user cost to (say) a Japanese speaker if an engine *does* case-fold. Also, many languages use Roman characters occasionally, as for acronyms; so their speakers also pay a price if searches aren't smart enough. And the primary problems with case-folding do not weigh so heavily in the search engine world (for example, AltaVista isn't likely to run their main servers on cell phones for a while yet).

1 0

Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26
by Greg Stein 08 Jun '00

08 Jun '00

On Wed, Jun 07, 2000 at 05:08:17PM -0700, Greg Ward wrote: > Update of /cvsroot/python/distutils/distutils/command > In directory slayer.i.sourceforge.net:/tmp/cvs-serv15881 > > Modified Files: > sdist.py > Log Message: > Made all debug output go through the 'debug_print()' method instead of > directly printing to stdout. This was a bit more work than it sounds like > it should have been: > * turned 'select_pattern()' and 'exclude_pattern()' from functions into > methods, so they can refer to 'self' to access the method You wouldn't have to do this if you make debug_print() a function. There is nothing in debug_print() that requires "self", so its existence as a method is suspect in the first place. Considering the fallout changes, I'd say move debug_print() to a plain function (in "utils"). Unless you were planning on more stuff in there; if so, then a comment in debug_print would be nice. >... > *************** > *** 297,301 **** > if (cur_dir == dir and > (pattern_re is None or pattern_re.match (cur_base))): > ! print "removing %s" % self.files[i] > del self.files[i] > > --- 298,302 ---- > if (cur_dir == dir and > (pattern_re is None or pattern_re.match (cur_base))): > ! self.debug_print("removing %s" % self.files[i]) > del self.files[i] Gah... "pattern_re.match (cur_base)" ... You do realize that God intended there to be no spaces between a function name and the opening paren? Heretic! :-) Really -- I have noticed this throughout a lot of the distutils code. That space in there is really awful. It reduces the "binding" of the name to the paren, which changes the meaning during a quick read. Put another way: when you skim code, NAME( is a function call and NAME ( is something else. A space after a name usually indicates the name is participating in an expression, rather than being used as a function name. Then, you hit the paren and go "what the heck? <pause> oh. a function call." Please... can they be removed? Cheers, -g -- Greg Stein, http://www.lyra.org/

3 2

Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.21,2.22
by Greg Stein 08 Jun '00

08 Jun '00

On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects > > Modified Files: > unicodeobject.c > Log Message: > Marc-Andre Lemburg <mal(a)lemburg.com>: > Change the default encoding to 'ascii' (it was previously > defined as UTF-8). > > Note: The implementation still uses UTF-8 to implement > the buffer protocol, so C APIs will still see UTF-8. This > is on purpose: rather than fixing the Unicode implementation, > the C APIs should be made Unicode aware. I'm a little confused on where this gets applied. Is this when somebody says "str(unicode_ob)", they get back ASCII rather than UTF-8? Or is this when somebody says "unicode(str)" and we expect <str> to be ASCII? Cheers, -g -- Greg Stein, http://www.lyra.org/

2 1

Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5)
by pf＠artcom-gmbh.de 08 Jun '00

08 Jun '00

Hi, Marc-Andre Lemburg: [...] > Added a new locale name aliasing engine which also supports > locale encodings, a feature which is used by the new default > encoding support in site.py. > > Index: locale.py [...] > + ### C lib locale APIs > + > + from _locale import * Wouldn't it be clever to provide some dummy stubs on those platforms, where the _locale module was not enabled? try: from _locale import * except: def setlocale(.... def localeconv(.... ... Especially the MacOS 1.5.2 release provided by Jack Jansen was compiled without '_locale'. And at least in Python 1.6a2 '_locale' is still disabled per default in 'Modules/Setup.in'. I didn't had a look into the current CVS though, so this may have changed. I think the name aliasing tables might be also useful on those systems lacking locale support in their C-library. Regards, Peter

3 3

Package ambiguities
by andy＠robanal.demon.co.uk 08 Jun '00

08 Jun '00

We hit some very weird behaviour recently while setting up a package hierarchy. Robin Becker managed to distil this into a simple example. Can anyone shed any light on what is happening below? Is Python behaving as it should? Create a package A, empty __init__.py, with modules as follows: --------parent.py---------- class Parent: pass --------child.py------------ from parent import Parent class Child(Parent): pass ---------test.py-------- from parent import * class Examiner: def examine(self, arg): print 'examining argument:' print 'class of arg =', arg.__class__ print 'bases of arg =', arg.__class__.__bases__ print 'arg =', arg if isinstance(arg, Parent): print "arg is an instance of Parent" else: print "arg IS NOT an instance of Parent" print if __name__=='__main__': from traceback import print_exc import sys def run0(): from A.child import Child e = Examiner() e.examine(Child()) def run1(): from A.child import Child from A.test import Examiner e = Examiner() e.examine(Child()) run0() run1() Running this script produces the following output: C:\users\andy\A>test.py examining argument: class of arg = A.child.Child bases of arg = (<class A.parent.Parent at 7f9150>,) arg = <A.child.Child instance at 7f9410> arg IS NOT an instance of Parent examining argument: class of arg = A.child.Child bases of arg = (<class A.parent.Parent at 7f9150>,) arg = <A.child.Child instance at 7f83c0> arg is an instance of Parent Many thanks, Andy Robinson

7 10

Package Style Guide
by Andy Robinson 08 Jun '00

08 Jun '00

Thanks for all the replies. We really need a 'style guide' on package use, so I hope this example can be thrashed out and used to help others. We need to decide something and release next week, and also provide good docs for other users who will be new to Python. Apart from the ambiguity, which was a surprise but which we can work around, I have some general questions on the "right thing". Here are my examples: 1. use of __init__ to save users work ------------------------------------ ReportLab has a subpackage called 'platypus' which we have just reorganized and not yet released. The division into subpackages is clear - each exposes a different kind of functionality - but the division of each package into modules is based on keeping a sane length for each and not on providing a friendly user interface. reportlab pdfgen canvas.py defines class Canvas textobject.py defines class TextObject pathobject.py defines class PathObject platypus (the same problem, but 3x worse) lib (loads of modules, all independent) We reached a point where users need to import eight or ten classes to do useful work and were having to put eight or ten different import lines at the top of every script. This just feels dumb and wrong. So, the 'least messy' idea was to put __init__.py methods in each subpackage which explicitly import what they need. (We have not used "import *") ---reportlab/pdfgen/__init__.py-------- from canvas import Canvas from textobject.py import TextObject from pathobject.py impory PathObject Then users can just do: from reportlab.pdfgen import Canvas, PathObject, TextObject It seems that this (a) makes life easier for users, and (b) gives us freedom to refactor code as it grows, without changing the user interface. Is this style evil? If so, why? 2. Ambiguities running scripts within package --------------------------------------------- We have various test functions scattered throughout our distribution. A control script iterates through the lot and kicks them off before every release, executing everything with an 'if __name__=='__main__' handler. If these were standalone scripts just for testing, they could import "reportlab.platypus.tables" or whatever. But if I just want to put a test routine at the end of "reportlab.platypus.tables" then I seem destined to run into exactly the ambiguity outlined before. Should test scripts all be moved out of the package? Indeed, is Python behaving the way it ought to? 3. Preferred subpackage import technique ---------------------------------------- I have two scripts 'spam.py' and 'eggs.py' in subpackage 'A.B'. spam imports eggs. Should it say... import eggs or... import A.B.eggs? Both work sometimes, but can lead to different behavious sometimes. Which is the preferred style? Thanks, Andy Robinson

4 4

release forms? (was: [Patches] New sys method to return total reference count in debug builds.)
by Greg Stein 08 Jun '00

08 Jun '00

Given the New World Order, how does that impact the need for these release statements and/or wet signatures? Or a better way to put it, who "owns" Python now? Given a "who", then we can ask that person/entity whether they want release statements. Given that Python is now on SourceForge, and there are multiple people (at CNRI and otherwise) that can directly make modifications, then the release below is certainly a bit "off". For example, David Ascher has commit privs, so at his "sole discretion, [he may] decide whether or not to incorporiate this contribution..." :-) Thoughts? Cheers, -g p.s. IMO, I'd like to see Guido own the Copyright for all current and future Python development -- Greg Stein, http://www.lyra.org/ ---------- Forwarded message ---------- Date: Mon, 5 Jun 2000 09:18:30 +1000 From: Mark Hammond <mhammond(a)skippinet.com.au> To: patches(a)python.org Subject: [Patches] New sys method to return total reference count in debug builds. [... snip ...] Release info: I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. Mark. _______________________________________________ Patches mailing list Patches(a)python.org http://www.python.org/mailman/listinfo/patches

5 7

Re: [Python-Dev] hey, who broke the array module?
by Jack Jansen 07 Jun '00

07 Jun '00

Recently, Guido van Rossum <guido(a)python.org> said: > > On Thu, May 18, 2000 at 12:01:16PM +0200, Jack Jansen wrote: > > > > I broke it with my patches to test overflow for some of the PyArg_Parse > *() > > > > formatting characters. The upshot of testing for overflow is that now t > hose > > > > formatting characters ('b', 'h', 'i', 'l') enforce signed-ness or > > > > unsigned-ness as appropriate (you have to know if the value is signed o > r > > > > unsigned to know what limits to check against for overflow). Two > > > > possibilities presented themselves: > > > > > > I think this is a _very_ bad idea. I have a few thousand (literally) rout > ines > > > calling to Macintosh system calls that use "h" for 16 bit flag-word value > s, > > > and the constants are all of the form > > > > > > kDoSomething = 0x0001 > > > kDoSomethingElse = 0x0002 > > > ... > > > kDoSomethingEvenMoreBrilliant = 0x8000 > > > > > > I'm pretty sure other operating systems have lots of calls with similar > > > problems. I would strongly suggest using a new format char if you want > > > overflow-tested integers. > > > > Sigh. What do you think Guido? This is your call. > > > > 1. go back to no bounds testing > > 2. bounds check for [SHRT_MIN, USHRT_MAX] etc (this would allow signed and > > unsigned values but is sort of false security for bounds checking) > > 3. keep it the way it is: 'b' is unsigned and the rest are signed > > 4. add new format characters or a modifying character for signed and unsign > ed > > versions of these. > > Sigh indeed. Ideally, we'd introduce H for unsigned and then lock > Jack in a room with his Macintosh computer for 48 hours to fix all his > code... Hmm, hmm. As stated before I'm not too fond of this as it is a gratuitous change that breaks lots of things (not only in Mac modules: the array module was what started this discussion, test_cPickle and test_pkg crash, socketmodule, os.stat() and I assume all code that uses structmodule will also have to be looked at, and quite possibly there's a lot more) and for which I don't really see all that much benefit. As a datapoint: a quick search for 8-digit hex numbers starting with digit 8-F and not suffixed with an L throughout the Python files in the distribution found a stunning 464 matches. Add another 1147 4-digit hex numbers with the sign bit on and there are an awful lot of candidates for breaking... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Revised 1.6 jobs list
by Andrew Kuchling 07 Jun '00

07 Jun '00

I've slightly revised the 1.6 jobs list at http://www.python.net/crew/amk/python/1.6-jobs.html . Things still on the TODO list, maybe: Import hooks revamp (or is this a post-1.6 thing?) Update the documentation to match 1.6 changes. Document more undocumented modules (goes without saying, really...) : codecs, unicodedata, mmap, pyexpat, curses, regrtest. Unicode: Compress the size of unicodedatabase Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch) Unicode: the various XXX itemsin Misc/unicode.txt (or are they done?) Delete obsolete subdirectories in Demo/ directory Refurbish Demo subdirectories to be properly documented, match modern coding style, etc. Fix ./ld_so_aix installation problem on AIX Make test.regrtest.py more usable outside of thePython test suite Conservative garbage collection of cycles (maybe -- I don't know what GvR thinks about this) Changes to PyExpat module Test the hell out of SRE The end of coding may be in sight, leaving only the job of documenting everything new. I'm getting kind of worried about the lengthening backlog of patches, though; maybe next week we can start cutting it down? (Quick, while Guido's away, everyone come up with new keywords and check them in!) --amk

13 27

Fwd: Hmmmm... (Jim Anderson)
by Jeremy Hylton 07 Jun '00

07 Jun '00

You guys haven't seen more Perl traffic on this list have you? :-) Jeremy

1 0