Mailman 3 June 2003 - Python-Dev

Py2.3 Todo List
by Raymond Hettinger June 25, 2003

June 25, 2003

Here is my todo list for Py2.3. Feel free to comment on whether it is too late to pursue these or whether I should continue to work on them for the second beta. 1) PEP 42 lists a request to add timeout settings to the higher level net libraries. Should this still be done? In Py2.3, sockets offers a setdefaulttimeout() function that provides an indirect way of meeting the same goal. 2) Jack Diedrich is working on two patches for itertools: itertools.window(iterable, n=2) --> (a0, a1), (a1, a2), (a2, a3), ... itertools.roundrobin(*iterables) which loops over the iterables returning one element from each and then cycles back to the first until all of the iterables are exhausted: itertools.roundrobin('ab', 'cde') --> a, c, b, d, e Both functions were discussed on comp.lang.python and have been requested by multiple users. Neither is easily implemented in terms of the existing tools. OTOH, the more tools you add, the harder it is to comprehend the toolset as a whole. 3) difflib now has functions to create a context diff or unified diff. A natural next step is to add a patch() function that applies the diff and finishes the roundtrip. It also helps fulfill the original reason for adding the context/unified diffs which was to make it easier for general python users to either create or apply patches. 4) I've had a long outstanding patch to add methods like isalpha() to string objects. The goal was to make sure that replacements exist for all the tools in the string module. The hold-up has been in making UniCode equivalents. If this is still wanted, I'll finish it up. Raymond Hettinger

14 38

Patch 595601
by Tim Peters June 25, 2003

June 25, 2003

http://www.python.org/sf/595601 has been in limbo a long time. Looks like it popped up in real life, in Zope last week. Quickie: if you let run this long enough, it will die with a segfault (and under any version of Python): """ import threading class Worker(threading.Thread): def __init__(self, f): threading.Thread.__init__(self) self.f = f def run(self): for i in xrange(100): self.f.write('abc') def doit(): f = file('junk.txt', 'wb') w = Worker(f) w.start() f.close() w.join() if __name__ == '__main__': while True: print '.', doit() """ Who here cares?

8 14

Python on dual-processor Macs?
by Greg Ewing June 24, 2003

June 24, 2003

I seem to remember a while back there was mention of a bug that prevented Python from working on dual-processor Macintoshes. Can anyone tell me: * Does this bug still exist? * If so, is it just the classic and/or carbon versions of MacPython that are affected, or does it apply to the unix command-line version as well? This is rather important to me right now, since I'm thinking of getting a new Mac, and I don't want to end up with something that won't run Python! Thanks, Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg(a)cosc.canterbury.ac.nz +--------------------------------------+

2 2

Re: curses module has_key emulation
by Mats Wichmann June 23, 2003

June 23, 2003

> the Lib/curses/has_key.py code looks questionable I've uploaded a trivial patch for this as 759208 in case anyone has a chance to take a look.

1 0

More work on SRE
by Gustavo Niemeyer June 22, 2003

June 22, 2003

There's a new version of the patch http://www.python.org/sf/757624 I understood there was some problems with the first implementation, and changed some aspects of how the new implementation works to fix them. This new implementation is more complex than the other implementations (mine, and the original), given the many details it covers, but is probably faster than these implementations in all situations (tests very welcome). Additionally, it introduces new features like infinite loop protection (*matching* the REs, not preventing their use). Here is a list of valid REs not accepted by the original implementation, and gracefully working on the new implementation (these used to blow up SRE with an infinite loop, not because the implementation was recursive). re.match("(a?)+ab", "ab") re.match("^(a|b?)+a$", "a") re.match("(a*)+?ac", "ab") re.match("((a)*)+?ac", "ab") re.match("(?=a)*", "a") Here is a list of unusual REs I've built while I was understanding how complex the operations could be. All of them work. re.search('(.*?)(?<!-):', 'bc-:') re.match("(.+)+B", "AB") re.match("^(a+){2}b$", "aaaaab").groups() re.match("^(a+)+a$", "aaaaaa").groups() re.match("^((a|b?)a)+a$", "aa").groups() The following RE is a good example of how *not to* build a regular expression. The current implementation hangs for a *long* time while executing it (more than many minutes.. I wasn't able to wait). The new implementation takes as long as 2 seconds. Notice that even the new implementation hangs (exponentially) with larger strings. re.match("(a+?)+?ac", "a"*1000+"b") The following SF issues were fixed, without being specifically addressed (IOW, they just work :-): * 695688 * 753711 * 725149 As a matter of giving credits, I've included part of the lastmark patch by Greg Chapman (712900). Now, I understand that this is complex stuff, thus any kind of help is very welcome. Here is how you can help: * provide benchmarks, good or bad, or provide "ready-to-benchmark" code; * provide information about tests you've done, good or bad, or provide "ready-to-test" code; Also, I don't know about any bugs in the SRE engine which are not fixed in the new implementation. If you have any non-working code or some SF bug I'm not aware of, please let me know. Ahhh.. now I'll relax a little bit. :-) -- Gustavo Niemeyer http://niemeyer.net

2 2

Update for os.path.expandvars bug 49589
by Behrang Dadsetan June 22, 2003

June 22, 2003

Here follows the comment I just added to bug "[ 494589 ] os.path.expandvars deletes things on w32". It concerns some mismatching (buggy) implementation / docstrings / comments for the ntpath.py and dospath.py. (Especially) As it is my first post as well as bugfix try for any open-source project, I am very happy receiving constructiv critic. tim_one is right. There is plenty of dodgy things hiding behind the os.path world, especially when it comes to os.path.expandvars() There are two problems here. - Mismatch in between the doc strings of the different implementation of expandvars and the "official" os.path.expandvars documentation. - the ntpath and dospath implementations are buggy when compared to their comments/docstrings. About the first problem, the inconsistency created some time ago in between the different implementations tasks makes it difficult to choose a solution. Everyone will probably agree that all the platform specific implementations of expandvars should have the same functionality. The one that should be taken over will probably need to be announced by the BDFL. Some rule which should not have let this here happen, and on which I believe we all will agree on: Same interface=same documentation->same functionality To implement either copy paste exactly the same expandvars definition from one platform to another (NT, DOS, POSIX), or somehow rather arrange that when there is no specific implementation for the platform, a "default" python implementation is used on the os.path level. To maximize the fruits of my small work, I would of course prefer that the version below becomes the standard and that the documentation get updated. To be complete, shall the documentation remain unchanged and the implementation of dos and nt gets adapted (copied from posix), the mac implementation could remain unchanged. But I feel its docstring and its documentation should be in line with the rest of the implementations. So my view point-> same interface, same documentation For the second problem - as of now a real bug whatever we decide, I wrote within this comment (hereafter) a new expandvars version which fits the docstring documentation of dospath.py and the comments of ntpath.py. Sorry you will be getting no patch from me at the moment since sourceforge's anonymous CVS access does not like me. Please note that my version borrows alot from the posixpath.py implementation and my changes are the ones of a python amateur who is open to critic. #expandvars() implementation _varprog = None _findquotes = None def expandvars(path): """Expand paths containing shell variable substitutions. The following rules apply: - no expansion within single quotes - no escape character, except for '$$' which is translated into '$' - ${varname} is accepted. - varnames can be made out of letters, digits and the character '_'""" global _varprog, _findquotes if '$' not in path: return path if not _varprog: import re _varprog = re.compile(r'\$(\w+|\{[^}]*\}|\$)') _findquotes = re.compile("'.*?'") quoteareas = [] i = 0 while 1: quotearea = _findquotes.search(path, i) if not quotearea: break (i, j) = quotearea.span(0) quoteareas.append((i, j)) i = j i = 0 while 1: m = _varprog.search(path, i) if not m: break i, j = m.span(0) insidequotes=None for (quotebegin, quoteend) in quoteareas: if quotebegin < i and quoteend > i: insidequotes=1 break if insidequotes: i = j continue name = m.group(1) if name[:1] == '$': path = path[:i] + '$' + path[j:] i = i + 1 else: if name[:1] == '{' and name[-1:] == '}': name = name[1:-1] if os.environ.has_key(name): tail = path[j:] path = path[:i] + os.environ[name] i = len(path) path = path + tail else: i = j return path Regards, Ben.

1 0

Weekly Python Bug/Patch Summary
by Skip Montanaro June 22, 2003

June 22, 2003

Bug/Patch Summary ----------------- 361 open / 3746 total bugs (-2) 164 open / 2229 total patches (+7) New Bugs -------- AssertionError from urllib.retrieve / httplib (2003-06-15) http://python.org/sf/755080 Tutorial: 4.7.2 Keyword Arguments **name output order wrong (2003-06-16) http://python.org/sf/755564 os module: Need a better description of "mode" (2003-06-16) http://python.org/sf/755617 complex pow() crash on Alpha (2003-06-17) http://python.org/sf/756093 Calling socket.recv() with a large number breaks (2003-06-17) http://python.org/sf/756104 Recursion limit too high for MacOSX (2003-06-18) http://python.org/sf/756576 Ms VC 2003 not supported (2003-06-18) http://python.org/sf/756842 SIGSEGV causes hung threads (Linux) (2003-06-18) http://python.org/sf/756924 can't CNTRL-C when running os.system in a thread (2003-06-18) http://python.org/sf/756940 FutureWarning: %u/%o/%x/%X of negative int will return a sig (2003-06-19) http://python.org/sf/757365 irreproducable segfault on int(1e100) (2003-06-19) http://python.org/sf/757520 Need to register PythonLauncher as handler for .py (2003-06-19) http://python.org/sf/757542 Mac/OSX/README outdated (2003-06-19) http://python.org/sf/757567 logging module docs (2003-06-20) http://python.org/sf/757821 Additional index items, other minor details (2003-06-20) http://python.org/sf/757822 socket timeout exception unhelpful (2003-06-20) http://python.org/sf/758239 asyncore with non-default map problems (2003-06-20) http://python.org/sf/758241 test_sax fails on python 2.2.3 & patch for regrtest.py (2003-06-21) http://python.org/sf/758504 IDE needs to remember status of interactive window (2003-06-21) http://python.org/sf/758565 IDE preferences cleanup (2003-06-21) http://python.org/sf/758566 cgi module should handle large post attack (2003-06-21) http://python.org/sf/758665 New Patches ----------- SSL crash interpreter on error (2003-06-15) http://python.org/sf/754870 Generate rpm filelist including directories (2003-06-16) http://python.org/sf/755286 allow HTMLParser to continue after a parse error (2003-06-16) http://python.org/sf/755660 improve HTMLParser attribute processing regexps (2003-06-16) http://python.org/sf/755670 755617: better docs for os.chmod (2003-06-16) http://python.org/sf/755677 Allow socket.inet_aton("255.255.255.255") on Windows (2003-06-17) http://python.org/sf/756021 re reads an uninitialized memory (2003-06-17) http://python.org/sf/756032 itertools roundrobin() and window() (2003-06-17) http://python.org/sf/756253 test_itertools for roundrobin() and window() (2003-06-17) http://python.org/sf/756255 Bare except in ZipFile.testzip() (2003-06-18) http://python.org/sf/756996 Fixing recursive problem in SRE (2003-06-19) http://python.org/sf/757624 Using __slots__ with str derived classes can cause segfault (2003-06-20) http://python.org/sf/757997 Closed Bugs ----------- Programs using Tkinter sometimes can't shut down (Windows) (2000-10-06) http://python.org/sf/216289 Codec naming scheme and aliasing support (2000-12-12) http://python.org/sf/225476 WIN32 os.path.normpath('./') incorrect (2002-01-31) http://python.org/sf/511261 raw_input non-ascii failure on Linux/KDE (2002-03-07) http://python.org/sf/527022 Framework.mainloop() - multiple threads (2002-04-05) http://python.org/sf/539990 Hint for speeding up cPickle (2002-08-07) http://python.org/sf/592112 IDE look and feel (2002-09-11) http://python.org/sf/607814 Can't run script from IDLE (2002-12-01) http://python.org/sf/646730 make error reporting better like cgi (2002-12-16) http://python.org/sf/654558 Freeze can not be made to exclude implicits (2003-02-11) http://python.org/sf/684679 Compiler Limits (indentation) (2003-03-10) http://python.org/sf/700827 Lookup of Mac error string can mess up resfile chain (2003-03-29) http://python.org/sf/711967 app-building with Bundlebuilder for framework builds (2003-04-18) http://python.org/sf/723562 OSX installer .pkg file permissions (2003-05-02) http://python.org/sf/731631 IMAP4_SSL broken (2003-05-19) http://python.org/sf/739909 _locale in Python-2.3b1/Tru64Unix 5.1A doesn't link (2003-05-22) http://python.org/sf/741843 exec documentation not updated (2003-06-06) http://python.org/sf/750092 Thread in threading.py can only be started once (2003-06-09) http://python.org/sf/751260 cPickle doesn't raise error, pickle does (recursiondepth) (2003-06-09) http://python.org/sf/751276 2.2.3 Latex documentation missing from web page? (2003-06-10) http://python.org/sf/751933 graminit.[ch] don't build on windows (2003-06-10) http://python.org/sf/751956 Object destruction is broken for slots (2003-06-10) http://python.org/sf/751998 print in __getattr__ causes seg fault (2003-06-10) http://python.org/sf/752221 classmethod abuse --> SystemError (2003-06-12) http://python.org/sf/753451 Installing idle from new location (2003-06-12) http://python.org/sf/753518 Closed Patches -------------- plain text enhancement for cgitb (2002-06-15) http://python.org/sf/569574 zlib.decompressobj under-described. (2002-11-18) http://python.org/sf/640236 Build _tkinter in setup.jaguar.py (2002-11-27) http://python.org/sf/644920 Don't FPE on FreeBSD... (2002-11-28) http://python.org/sf/645382 DESTDIR improvement (2003-05-12) http://python.org/sf/736413 Put DEFS back to Makefile.pre.in (2003-05-12) http://python.org/sf/736417 Bug fix 750092: exec doesn't need newline (2003-06-08) http://python.org/sf/751038

1 0

Re: Python language standard; LSB
by Mats Wichmann June 22, 2003

June 22, 2003

Tobias writes: >one thing that prevents the linux standard base to include Python (or Perl >for that matter) is that there is no formal language standard with test >cases. (For the LSB a subset might be enough.) >http://www.linuxbase.org/futures/faq.html#scope > >Exists there anywhere a rudimentary standard or are there plans to create >one? well, stop paying attention for a bit (well, for months to be honest) and see what happens. As Tobias knows, working on the LSB is my "day job", although he probably doesn't know I hang out here, too. The LSB standardization process has a number of steps in it; one of the key ones is demand. We're not really blocked on a language standard or test suite, as has been pointed out elsewhere, just picking a version and its' matching test suite is close to good enough. But what we don't have is any really burning need to add more dynamic languages to the LSB specification (a "posix shell" is included for installation script purposes, so there is one). What does it mean to be part of this standard? It means an application developer can count on specific functionality to be present on a conforming system. There are already two answers for that: you can bundle Python with your project, Zope-style, or you can build your package to require an lsb-conforming Python of a specific version to be installed as a condition of installation (e.g., rpm dependency). The LSB project already builds such a version of Python as part of the "LSB application battery". The LSB application battery is used as a testbed of various functionality, and part of that process is installing lsb-python and running the Python regression test suite (in fact, it was chosen - by me - for the existence of that test suite which managed to beat on some things we don't have any more formal tests for). Perl is not part of this at the moment, by the way. Plus, of course, most systems that are targets of this already include Python, and a bit of care in coding ought to make it possible to use the native version. So until someone builds a "business case" that there's a problem that can only be solved by trying to create a "standard" for Python within the LSB, I don't see a lot of reason for the LSB committee to worry about it... Cheers, Mats Wichmann

2 1

SF CVS hosed?
by Anthony Baxter June 21, 2003

June 21, 2003

Attempting a cvs up at the moment is failing with: cvs server: failed to create lock directory for `/cvsroot/python/python/dist/src' (/cvsroot/python/python/dist/src/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/cvsroot/python/python/dist/src' cvs [server aborted]: read lock failed - giving up ... or is it just me? Anthony

5 5

A vote against dict(keyword=value) sugar + musing on how to do it
by bokr＠oz.net June 20, 2003

June 20, 2003

I'd rather have unambiguous use of it for subclasses of dict. def md(**kw):return kw d = dict(md(keyword=value)) is not that much work. Unambiguous simple use in subclasses is more important IMO. <musing> If there were a way to partition arguments into multiple arg lists so __new__ could optionally have separable lists for passing to base class constructors vs using for the subclass __new__ vs letting __init__ maybe do something. E.g., you could separate multiple lists with ';' class D(dict): def __new__(cls, *args, **kw; number=123,**subclass_kw): #XXX# currently illegal self = dict.__new__(cls, *args, **kw) #XXX# shouldn't be legal unless self.color = subclass_kw.get('color','blue') # we can partition arg lists, IMO self.number = number return self ... d1 = D(key=value, key2=value2) #XXX# means default args for number, subclass_kw d2 = D(; 456, color='red') #XXX# empty base dict, other non-default attributes I.e., D is drop-in compatible for base-class-compatible construction calls, and has to be different anyway for special subclass parameters, so the ';' seems ok. Or is there a hidden gotcha? <tangential> BTW, since a (name,value) tuple sequence also works, maybe it would be nice to be able to construct such a sequence without quotes on the even-index elements. E.g., with new keyword assoc: assoc(name0, val0, name1, val1, etc, etc) => [('name0',val0), ('name1',val1), ('etc', etc)] This would provide the unquoted naming in an ordered context as well as the unordered keyword=value pairings. Or course, in source you can spell that zip('name0 name1 etc'.split(), [name0,name1,etc]) but that ugly for longer sequences where it's harder to match the pairs, not to mention other considerations. </tangential> </musing> Regards, Bengt Richter (copy to python-dev(a)python.org, per advice in c.l.p "Subject: a clean way to define dictionary" thread.) Regards, Bengt Richter

1 0