Mailman 3 December 2004 - Python-Dev

Trouble installing 2.4
by Andrew Koenig 01 Dec '04

01 Dec '04

I'm using Windows XP SP2. Uninstalled 2.3, installed 2.4 (running as me, not as administrator). No problems so far. Tried installing pywin32-203.win32-py2.4.exe When I try to install it as me, it gets as far as "ready to install." When I click Next, it says Can't load Python for pre-install script and quits, even though earlier it said it had found Python 2.4 in the registry. When I try to install it as Administrator, it quits immediately, saying that it couldn't locate a Python 2.4 installation. My hypothesis: When I install 2.4 as me, it puts it in my user registry, not the system-wide registry, and then pywin32 can't find it. I'm going to unstall and try again as Administrator.

4 3

Small subprocess patch
by Peter Åstrand 01 Dec '04

01 Dec '04

I'm planning to change the signature for subprocess.call slightly: -def call(*args, **kwargs): +def call(*popenargs, **kwargs): The purpose is to make it clearer that "args" in this context is not the same as the "args" argument to the Popen constructor. Two questions: 1) Is it OK to commit changes like this on the 2.4 branch, in addition to trunk? 2) Anyone that thinks that "kwargs" should be changed into "popenkwargs"? /Peter Åstrand <astrand(a)lysator.liu.se>

3 2

Difflib modifications [reposted]
by kiko＠async.com.br 01 Dec '04

01 Dec '04

[Reposted to python-dev!] Hello there, We've has done some customizations to difflib to make it work well with pagetests we are running on a project at Canonical, and we are looking for some guidance as to what's the best way to do them. There are some tricky bits that have to do with how the class inheritance is put together, and since we would want to avoid duplicating difflib I figured we'd ask and see if some grand ideas come up. A [rough first cut of the] patch is inlined below. Essentially, it does: - Implements a custom Differ.fancy_compare function that supports ellipsis and omits equal content - Hacks _fancy_replace to skip ellipsis as well. - Hacks best_ratio and cutoff. I'm a bit fuzzy on why this was changed, to be honest, and Celso's travelling today, but IIRC it had to do with how difflib grouped changes. Essentially, what we aim for is: - Ignoring ellipsisized(!) content - Omitting content which is equal I initially thought the best way to do this would be to inherit from SequenceMatcher and make it not return opcodes for ellipsis. However, there is no easy way to replace the class short of rewriting major bits of Differ. I suspect this could be easily changed to use a class attribute that we could override, but let me know what you think of the whole thing. --- /usr/lib/python2.3/difflib.py 2004-11-18 20:05:38.720109040 -0200 +++ difflib.py 2004-11-18 20:24:06.731665680 -0200 @@ -885,6 +885,45 @@ for line in g: yield line + def fancy_compare(self, a, b): + """ + >>> import difflib + >>> engine = difflib.Differ() + >>> got = ['World is Cruel', 'Dudes are Cool'] + >>> want = ['World ... Cruel', 'Dudes ... Cool'] + >>> list(engine.fancy_compare(want, got)) + [] + + """ + cruncher = SequenceMatcher(self.linejunk, a, b) + for tag, alo, ahi, blo, bhi in cruncher.get_opcodes(): + + if tag == 'replace': + ## replace single line + if a[alo:ahi][0].rstrip() == '...' and ((ahi - alo) == 1): + g = None + ## two lines replaced + elif a[alo:ahi][0].rstrip() == '...' and ((ahi - alo) > 1): + g = self._fancy_replace(a, (ahi - 1), ahi, + b, (bhi - 1), bhi) + ## common + else: + g = self._fancy_replace(a, alo, ahi, b, blo, bhi) + elif tag == 'delete': + g = self._dump('-', a, alo, ahi) + elif tag == 'insert': + g = self._dump('+', b, blo, bhi) + elif tag == 'equal': + # do not show anything + g = None + else: + raise ValueError, 'unknown tag ' + `tag` + + if g: + for line in g: + yield line + + def _dump(self, tag, x, lo, hi): """Generate comparison results for a same-tagged range.""" for i in xrange(lo, hi): @@ -926,7 +965,13 @@ # don't synch up unless the lines have a similarity score of at # least cutoff; best_ratio tracks the best score seen so far - best_ratio, cutoff = 0.74, 0.75 + #best_ratio, cutoff = 0.74, 0.75 + + ## reduce the cutoff to have enough similarity + ## between '<something> ... <something>' and '<a> blabla </a>' + ## for example + best_ratio, cutoff = 0.009, 0.01 + cruncher = SequenceMatcher(self.charjunk) eqi, eqj = None, None # 1st indices of equal lines (if any) @@ -981,7 +1026,11 @@ cruncher.set_seqs(aelt, belt) for tag, ai1, ai2, bj1, bj2 in cruncher.get_opcodes(): la, lb = ai2 - ai1, bj2 - bj1 - if tag == 'replace': + + if aelt[ai1:ai2] == '...': + return + + if tag == 'replace': atags += '^' * la btags += '^' * lb elif tag == 'delete': Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331

1 0

File encodings
by Gustavo Niemeyer 01 Dec '04

01 Dec '04

Greetings, Today, while trying to internationalize a program I'm working on, I found an interesting side-effect of how we're dealing with encoding of unicode strings while being written to files. Suppose the following example: # -*- encoding: iso-8859-1 -*- print u"á" This will correctly print the string 'á', as expected. Now, what surprises me, is that the following code won't work in an equivalent way (unless using sys.setdefaultencoding()): # -*- encoding: iso-8859-1 -*- import sys sys.stdout.write(u"á\n") This will raise the following error: Traceback (most recent call last): File "asd.py", line 3, in ? sys.stdout.write(u"á") UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0:ordinal not in range(128) This difference may become a really annoying problem when trying to internationalize programs, since it's usual to see third-party code dealing with sys.stdout, instead of using 'print'. The standard optparse module, for instance, has a reference to sys.stdout which is used in the default --help handling mechanism. Given the fact that files have an 'encoding' parameter, and that any unicode strings with characters not in the 0-127 range will raise an exception if being written to files, isn't it reasonable to respect the 'encoding' attribute whenever writing data to a file? The workaround for that problem is to either use the evil-considered sys.setdefaultencoding(), or to wrap sys.stdout. IMO, both options seem unreasonable for such a common idiom. -- Gustavo Niemeyer http://niemeyer.net

5 10

Python.org current docs
by Thomas Heller 30 Nov '04

30 Nov '04

http://www.python.org/doc/current/ and http://docs.python.org/ still point to 2.3.4 docs. Thomas

2 2