Mailman 3 August 2000 - Python-Dev

Breaking Test Cases on Purpose
by Moshe Zadka Aug. 3, 2000

Aug. 3, 2000

Suppose I'm fixing a bug in the library. I want peer review for my fix, but I need none for my new "would have caught" test cases. Is it considered alright to check-in right away the test case, breaking the test suite, and to upload a patch to SF to fix it? Or should the patch include the new test cases? The XP answer would be "hey, you have to checkin the breaking test case right away", and I'm inclined to agree. I really want to break the standard library, just because I'm a sadist -- but … [View More]

7 15

Removing the 16 bit arg limit
by Vladimir.Marangozov＠inrialpes.fr Aug. 3, 2000

Aug. 3, 2000

I've looked at this and the best compromise solution I ended up with (before Py3K) is sketched here: opcode.h: #define EXTENDED_ARG 135 /* 16 higher bits of the next opcode arg */ ceval.c: case EXTENDED_ARG: do { oparg <<= 16; op = NEXTOP(); oparg += NEXTARG(); } while (op == EXTENDED_ARG); goto dispatch_opcode; compile.c: static void com_addoparg(struct compiling *c, int op, int arg) { if (arg < 0) { com_error(c, PyExc_SystemError, "com_addoparg: … [View More]

1 0

Summary or failing regression tests...
by Trent Mick Aug. 3, 2000

Aug. 3, 2000

Here is a list of the regrtests that are currently failing for me on Linux32 and Win32. Is anybody looking at test_mmap, test_userstring, test_winreg, and test_winreg2? Skip, You and Jeremy(?) were talking about test_posixpath on Linux. It looks like the sames errors you were talking about occur on Win32. I didn't look too closely, can you? Fredrik, are you aware of the test_sre failure on Win32? Am I doing something wrong to be getting this? On Linux32: - test_fork1 This fails/hangs/… [View More]crashes inconsistently because (some little bird told me) the fork stuff and threads are incompatible. Am I right? Now that we are turning threads on by default what is the proper thing to do here? SHould test_fork1 be changed to skip if threads are enabled? On Win32: - test_mmap one liner: test test_mmap crashed -- exceptions.WindowsError : [Errno 6] The handle is invalid full output: Position of foo: 1.0 pages Length of file: 2.0 pages Contents of byte 0: '\000' Contents of first 3 bytes: '\000\000\000' Modifying file's content... Contents of byte 0: '3' Contents of first 3 bytes: '3\000\000' Contents of second page: foobar Regex match on mmap (page start, length of match): 1.0 6 Seek to zeroth byte Seek to 42nd byte Seek to last byte Try to seek to negative position... Try to seek beyond end of mmap... Try to seek to negative position... Attempting resize() Traceback (most recent call last): File "..\Lib\test\test_mmap.py", line 114, in ? test_both() File "..\Lib\test\test_mmap.py", line 100, in test_both m.resize( 512 ) WindowsError: [Errno 6] The handle is invalid - test_posixpath one liner: test test_posixpath failed -- Writing: 'error!', expected: 'No err' full output: error! evaluated: posixpath.commonprefix(["/home/swenson/spam", "/home/swen/spam"]) should be: /home returned: /home/swen error! evaluated: posixpath.commonprefix(["/home/swen/spam", "/home/swen/eggs"]) should be: /home/swen returned: /home/swen/ 2 errors. - test_re one liner: test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou" full output: Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Traceback (most recent call last): File "..\Lib\test\test_re.py", line 122, in ? raise TestFailed, "symbolic reference" test_support.TestFailed: symbolic reference discussion: This has been discussed a litle by Mark Favas and Jeremy with no conclusion. http://www.python.org/pipermail/python-dev/2000-July/013963.html - test_sre one liner: test test_sre failed -- Writing: '=== Failed incorrectly', expected: "===grouping error ('(" full output: Running tests on sre.search and sre.match Running tests on sre.sub Running tests on symbolic references Traceback (most recent call last): File "..\Lib\test\test_sre.py", line 124, in ? raise TestFailed, "symbolic reference" test_support.TestFailed: symbolic reference discussion: This has been discussed a litle by Mark Favas and Jeremy with no conclusion http://www.python.org/pipermail/python-dev/2000-July/013963.html - test_userstring one liner: test test_userstring failed -- Writing: "'a'", expected: '' full output: 'a' <built-in method isalpha of string object at 007E1DF0> <class exceptions.TypeError at 007C5AAC> <> <class exceptions.AttributeError at 007C611C> 'A' <built-in method isalpha of string object at 00812CF0> <class exceptions.TypeError at 007C5AAC> <> <class exceptions.AttributeError at 007C611C> '\012' <built-in method isalpha of string object at 00812CC0> <class exceptions.TypeError at 007C5AAC> <> <class exceptions.AttributeError at 007C611C> 'abc' <built-in method isalpha of string object at 008118F0> <class exceptions.TypeError a t 007C5AAC> <> <class exceptions.AttributeError at 007C611C> 'aBc123' <built-in method isalpha of string object at 00812990> <class exceptions.TypeErro r at 007C5AAC> <> <class exceptions.AttributeError at 007C611C> 'abc\012' <built-in method isalpha of string object at 00812C60> <class exceptions.TypeErr or at 007C5AAC> <> <class exceptions.AttributeError at 007C611C> 'a' <built-in method isalnum of string object at 007E1DF0> <class exceptions.TypeError at 007C5AAC> <> <class exceptions.AttributeError at 007C611C> 'A' <built-in method isalnum of string object at 00812CF0> <class exceptions.TypeError at 007C5AAC> <> <class exceptions.AttributeError at 007C611C> '\012' <built-in method isalnum of string object at 00812CC0> <class exceptions.TypeError at 007C5AAC> <> <class exceptions.AttributeError at 007C611C> '123abc456' <built-in method isalnum of string object at 00812930> <class exceptions.TypeE rror at 007C5AAC> <> <class exceptions.AttributeError at 007C611C> 'a1b3c' <built-in method isalnum of string object at 00812900> <class exceptions.TypeError at 007C5AAC> <> <class exceptions.AttributeError at 007C611C> 'aBc000 ' <built-in method isalnum of string object at 008128D0> <class exceptions.TypeErr or at 007C5AAC> <> <class exceptions.AttributeError at 007C611C> 'abc\012' <built-in method isalnum of string object at 00812C60> <class exceptions.TypeErr or at 007C5AAC> <> <class exceptions.AttributeError at 007C611C> - test_winreg one liner: test test_winreg failed -- Unread: '\012' full output: (this works when run standalone) - test_winreg2 (crashes) full output: Fatal Python error: PyThreadState_Get: no current thread abnormal program termination Thanks, Trent -- Trent Mick TrentM(a)ActiveState.com [View Less]

16 44

Re: [Python-Dev] Breaking Test Cases on Purpose
by Michael Hudson Aug. 3, 2000

Aug. 3, 2000

Moshe Zadka <moshez(a)math.huji.ac.il> writes: > Suppose I'm fixing a bug in the library. I want peer review for my fix, > but I need none for my new "would have caught" test cases. Is it > considered alright to check-in right away the test case, breaking the test > suite, and to upload a patch to SF to fix it? Or should the patch include > the new test cases? > > The XP answer would be "hey, you have to checkin the breaking test case > right away", and I'm … [View More]

1 0

SRE 0.9.8 benchmarks
by Fredrik Lundh Aug. 3, 2000

Aug. 3, 2000

Guido asked me to update my old SRE benchmarks, and post them to python-dev. Summary: -- SRE is usually faster than the old RE module (PRE). -- SRE is faster than REGEX on anything but very trivial patterns and short target strings. And in some cases, it's even faster than a corresponding string.find... -- on real-life benchmarks like XML parsing and Python tokenizing, SRE is 2-3 times faster than PRE. -- using Unicode strings instead of 8-bit strings doesn't hurt performance (… [View More]for some tests, the Unicode version is 30-40% faster on my machine. Go figure...) -- PRE is still faster for some patterns, especially when using long target strings. I know why, and I plan to fix that before 2.0 final. enjoy /F -------------------------------------------------------------------- These tests were made on a P3/233 MHz running Windows 95, using a local build of the 0.9.8 release (this will go into 1.6b1, I suppose). -------------------------------------------------------------------- parsing xml: running xmllib.py on hamlet.xml (280k): sre8 7.14 seconds sre16 7.82 seconds pre 17.17 seconds (for the sre16 test, the xml file was converted to unicode before it was fed to the unmodified parser). for comparision, here's the results for a couple of fast pure-Python parsers: rex/pre 2.44 seconds rex/sre 0.59 seconds srex/sre 0.16 seconds (rex is a shallow XML parser, based on code by Robert Cameron. srex is an even simpler shallow parser, using sre's template mode). -------------------------------------------------------------------- parsing python: running tokenize.py on Tkinter.py (156k): sre8 3.23 seconds pre 7.57 seconds -------------------------------------------------------------------- searching for literal text: searching for "spam" in a string padded with "spaz" (1000 bytes on each side of the target): string.find 0.112 ms sre8.search 0.059 pre.search 0.122 unicode.find 0.130 sre16.search 0.065 (yes, regular expressions can run faster than optimized C code -- as long as we don't take compilation time into account ;-) same test, without any false matches: string.find 0.035 ms sre8.search 0.050 pre.search 0.116 unicode.find 0.031 sre16.search 0.055 -------------------------------------------------------------------- compiling regular expressions compiling the 480 tests in the standard test suite: sre 1.22 seconds pre 0.05 seconds or in other words, pre (using a compiler written in C) can compile just under 10,000 patterns per second. sre can only compile about 400 pattern per second. do we care? ;-) (footnote: sre's pattern cache stores 100 patterns. pre's cache hold 20 patterns, iirc). -------------------------------------------------------------------- benchmark suite to round off this report, here's a couple of "micro benchmarks". all times are in milliseconds. n= 0 5 50 250 1000 5000 ----- ----- ----- ----- ----- ----- ----- pattern 'Python|Perl', string '-'*n+'Perl'+'-'*n sre8 0.014 0.013 0.013 0.016 0.027 0.079 sre16 0.014 0.014 0.015 0.018 0.025 0.076 pre 0.107 0.109 0.114 0.116 0.135 0.259 regex 0.011 0.011 0.012 0.016 0.033 0.122 pattern 'Python|Perl', string 'P'*n+'Perl'+'P'*n sre8 0.013 0.016 0.030 0.100 0.358 1.716 sre16 0.014 0.015 0.030 0.094 0.347 1.649 pre 0.115 0.112 0.158 0.351 1.085 5.002 regex 0.010 0.016 0.060 0.271 1.022 5.162 (false matches causes problems for pre and regex) pattern '(Python|Perl)', string '-'*n+'Perl'+'-'*n sre8 0.014 0.016 0.030 0.099 0.362 1.684 sre16 0.015 0.016 0.030 0.094 0.340 1.623 pre 0.110 0.111 0.112 0.119 0.143 0.267 regex 0.012 0.012 0.013 0.017 0.034 0.124 (in 0.9.8, sre's optimizer doesn't grok named groups, and it doesn't realize that this pattern has to start with a "P") pattern '(?:Python|Perl)', string '-'*n+'Perl'+'-'*n sre8 0.013 0.013 0.014 0.016 0.027 0.079 sre16 0.015 0.014 0.016 0.018 0.026 0.075 pre 0.108 0.135 0.113 0.137 0.140 0.275 regex skip (anonymous groups work better) pattern 'Python', string '-'*n+'Python'+'-'*n sre8 0.013 0.013 0.014 0.019 0.039 0.148 sre16 0.013 0.013 0.014 0.020 0.043 0.187 pre 0.129 0.105 0.109 0.117 0.191 0.277 regex 0.011 0.025 0.018 0.016 0.037 0.127 pattern 'Python', string 'P'*n+'Python'+'P'*n sre8 0.040 0.012 0.021 0.026 0.080 0.248 sre16 0.012 0.013 0.015 0.025 0.061 0.283 pre 0.110 0.148 0.153 0.338 0.925 4.355 regex 0.013 0.013 0.041 0.155 0.535 2.628 (as we saw in the string.find test, sre is very fast when there are lots of false matches) pattern '.*Python', string '-'*n+'Python'+'-'*n sre8 0.016 0.017 0.026 0.067 0.217 1.039 sre16 0.016 0.017 0.026 0.067 0.218 1.076 pre 0.111 0.112 0.124 0.180 0.386 1.494 regex 0.015 0.022 0.073 0.408 1.669 8.489 pattern '.*Python.*', string '-'*n+'Python'+'-'*n sre8 0.016 0.017 0.030 0.089 0.315 1.499 sre16 0.016 0.018 0.032 0.090 0.314 1.537 pre 0.112 0.113 0.129 0.186 0.413 1.605 regex 0.016 0.023 0.076 0.387 1.674 8.519 pattern '.*(Python)', string '-'*n+'Python'+'-'*n sre8 0.020 0.021 0.044 0.147 0.542 2.630 sre16 0.019 0.021 0.044 0.154 0.541 2.681 pre 0.115 0.117 0.141 0.245 0.636 2.690 regex 0.019 0.026 0.097 0.467 2.007 10.264 pattern '.*(?:Python)', string '-'*n+'Python'+'-'*n sre8 0.016 0.017 0.027 0.065 0.220 1.037 sre16 0.016 0.017 0.026 0.070 0.221 1.066 pre 0.112 0.119 0.136 0.223 0.566 2.377 regex skip pattern 'Python|Perl|Tcl', string '-'*n+'Perl'+'-'*n sre8 0.013 0.015 0.034 0.114 0.407 1.985 sre16 0.014 0.016 0.034 0.109 0.392 1.915 pre 0.107 0.108 0.117 0.124 0.167 0.393 regex 0.012 0.012 0.013 0.017 0.033 0.123 (here's another sre compiler problem: it fails to realize that this pattern starts with characters from a given set [PT]. pre and regex both use bitmaps...) pattern 'Python|Perl|Tcl', string 'P'*n+'Perl'+'P'*n sre8 0.013 0.018 0.055 0.228 0.847 4.165 sre16 0.015 0.027 0.055 0.218 0.821 4.061 pre 0.111 0.116 0.172 0.415 1.354 6.302 regex 0.011 0.019 0.085 0.374 1.467 7.261 (but when there are lots of false matches, sre is faster anyway. interesting...) pattern '(Python|Perl|Tcl)', string '-'*n+'Perl'+'-'*n sre8 0.014 0.018 0.042 0.152 0.575 2.798 sre16 0.015 0.019 0.042 0.148 0.556 2.715 pre 0.112 0.111 0.116 0.129 0.172 0.408 regex 0.012 0.013 0.014 0.018 0.035 0.124 pattern '(?:Python|Perl|Tcl)', string '-'*n+'Perl'+'-'*n sre8 0.014 0.016 0.034 0.113 0.405 1.987 sre16 0.016 0.016 0.033 0.112 0.393 1.918 pre 0.109 0.109 0.112 0.128 0.177 0.397 regex skip pattern '(Python)\\1', string '-'*n+'PythonPython'+'-'*n sre8 0.014 0.018 0.030 0.096 0.342 1.673 sre16 0.015 0.016 0.031 0.094 0.330 1.625 pre 0.112 0.111 0.112 0.119 0.141 0.268 regex 0.011 0.012 0.013 0.017 0.033 0.123 pattern '(Python)\\1', string 'P'*n+'PythonPython'+'P'*n sre8 0.013 0.016 0.035 0.111 0.411 1.976 sre16 0.015 0.016 0.034 0.112 0.416 1.992 pre 0.110 0.116 0.160 0.355 1.051 4.797 regex 0.011 0.017 0.047 0.200 0.737 3.680 pattern '([0a-z][a-z0-9]*,)+', string '-'*n+'a5,b7,c9,'+'-'*n sre8 0.084 0.091 0.143 0.371 1.160 6.165 sre16 0.086 0.090 0.142 0.470 1.258 7.827 pre 0.155 0.140 0.185 0.200 0.280 0.523 regex 0.018 0.018 0.020 0.024 0.137 0.240 (again, sre's lack of "fastmap" is rather costly) pattern '(?:[0a-z][a-z0-9]*,)+', string '-'*n+'a5,b7,c9,'+'-'*n sre8 0.028 0.033 0.077 0.303 1.433 7.140 sre16 0.021 0.027 0.073 0.277 1.031 5.053 pre 0.131 0.131 0.174 0.183 0.227 0.461 regex skip pattern '([a-z][a-z0-9]*,)+', string '-'*n+'a5,b7,c9,'+'-'*n sre8 0.032 0.038 0.083 0.288 1.109 5.404 sre16 0.033 0.038 0.083 0.292 1.035 5.802 pre 0.195 0.135 0.176 0.187 0.233 0.468 regex 0.018 0.018 0.019 0.023 0.041 0.131 pattern '(?:[a-z][a-z0-9]*,)+', string '-'*n+'a5,b7,c9,'+'-'*n sre8 0.022 0.025 0.067 0.302 1.011 8.245 sre16 0.021 0.026 0.066 0.302 1.103 5.372 pre 0.262 0.397 0.178 0.193 0.250 0.817 regex skip pattern '.*P.*y.*t.*h.*o.*n.*', string '-'*n+'Python'+'-'*n sre8 0.021 0.084 0.118 0.251 0.965 5.414 sre16 0.021 0.025 0.063 0.366 1.192 4.639 pre 0.123 0.147 0.225 0.568 1.899 9.336 regex 0.028 0.060 0.258 1.269 5.497 28.334 -------------------------------------------------------------------- [View Less]

5 10

Buglist
by Thomas Wouters Aug. 3, 2000

Aug. 3, 2000

Just a little FYI and 'is this okay' message; I've been browsing the buglist the last few days, doing a quick mark & message sweep over the bugs that I can understand. I've mostly been closing bugs that look closed, and assigning them when it's very obvious who it should be assigned to. Should I be doing this already ? Is the bug-importing 'done', or is Jeremy still busy with importing and fixing bug status (stati ?) and such ? Is there something better to use as a guideline than my 'best … [View More]

2 3

printing xrange objects
by Fred L. Drake, Jr. Aug. 3, 2000

Aug. 3, 2000

At various points, there have been comments that xrange objects should not print as lists but as xrange objects. Taking a look at the implementation, I noticed that if you call repr() (by name or by backtick syntax), you get "the right thing"; the list representation comes up when you print the object on a real file object. The tp_print slot of the xrange type produces the list syntax. There is no tp_str handler, so str(xrange(...)) is the same as repr(xrange(...)). I propose ripping out … [View More]

3 5

Still no new license -- but draft text available
by Guido van Rossum Aug. 3, 2000

Aug. 3, 2000

We still don't have a new license for Python 1.6; Bob Kahn and Richard Stallman need to talk before a decision can be made about how to deal with the one remaining GPL incompatibility. While we're all waiting, we're preparing the CNRI 1.6 release at SourceForge (part of the deal is that the PythonLabs group finishes the 1.6 release for CNRI). The last thing I committed today was the text (dictated by Bob Kahn) for the new LICENSE file that will be part of the 1.6 beta 1 release. (Modulo any … [View More]changes that will be made to the license text to ensure GPL compatibility.) Since anyone with an anonymous CVS setup can now read the license anyway, I might as well post a copy here so that you can all get used to it... --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) ======== LICENSE ======================================================= A. HISTORY OF THE SOFTWARE Python originated in 1991 at Stichting Mathematisch Centrum (CWI) in the Netherlands as an outgrowth of a language called ABC. Its principal author was Guido van Rossum, although it included smaller contributions from others at CWI and elsewhere. The last version of Python issued by CWI was Python 1.2. In 1995, Mr. van Rossum continued his work on Python at the Corporation for National Research Initiatives (CNRI) in Reston, Virginia where several versions of the software were generated. Python 1.6 is the last of the versions developed at CNRI. B. TERMS AND CONDITIONS FOR ACCESSING OR OTHERWISE USING Python 1.6, beta 1 1. CNRI LICENSE AGREEMENT PYTHON 1.6, beta 1 CNRI OPEN SOURCE LICENSE AGREEMENT IMPORTANT: PLEASE READ THE FOLLOWING AGREEMENT CAREFULLY. BY CLICKING ON "ACCEPT" WHERE INDICATED BELOW, OR BY COPYING, INSTALLING OR OTHERWISE USING PYTHON 1.6, beta 1 SOFTWARE, YOU ARE DEEMED TO HAVE AGREED TO THE TERMS AND CONDITIONS OF THIS LICENSE AGREEMENT. 1. This LICENSE AGREEMENT is between the Corporation for National Research Initiatives, having an office at 1895 Preston White Drive, Reston, VA 20191 ("CNRI"), and the Individual or Organization ("Licensee") accessing and otherwise using Python 1.6, beta 1 software in source or binary form and its associated documentation, as released at the www.python.org Internet site on August 5, 2000 ("Python 1.6b1"). 2. Subject to the terms and conditions of this License Agreement, CNRI hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use Python 1.6b1 alone or in any derivative version, provided, however, that CNRI's License Agreement is retained in Python 1.6b1, alone or in any derivative version prepared by Licensee. Alternately, in lieu of CNRI's License Agreement, Licensee may substitute the following text (omitting the quotes): "Python 1.6, beta 1, is made available subject to the terms and conditions in CNRI's License Agreement. This Agreement may be located on the Internet using the following unique, persistent identifier (known as a handle): 1895.22/1011. This Agreement may also be obtained from a proxy server on the Internet using the URL:http://hdl.handle.net/1895.22/1011". 3. In the event Licensee prepares a derivative work that is based on or incorporates Python 1.6b1or any part thereof, and wants to make the derivative work available to the public as provided herein, then Licensee hereby agrees to indicate in any such work the nature of the modifications made to Python 1.6b1. 4. CNRI is making Python 1.6b1 available to Licensee on an "AS IS" basis. CNRI MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, CNRI MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 1.6b1 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 5. CNRI SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF THE SOFTWARE FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF USING, MODIFYING OR DISTRIBUTING PYTHON 1.6b1, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. SOME STATES DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY SO THE ABOVE DISCLAIMER MAY NOT APPLY TO LICENSEE. 6. This License Agreement will automatically terminate upon a material breach of its terms and conditions. 7. This License Agreement shall be governed by and interpreted in all respects by the law of the State of Virginia, excluding conflict of law provisions. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between CNRI and Licensee. This License Agreement does not grant permission to use CNRI trademarks or trade name in a trademark sense to endorse or promote products or services of Licensee, or any third party. 8. By clicking on the "ACCEPT" button where indicated, or by copying installing or otherwise using Python 1.6b1, Licensee agrees to be bound by the terms and conditions of this License Agreement. ACCEPT 2. CWI PERMISSIONS STATEMENT AND DISCLAIMER Copyright (c) 1991 - 1995, Stichting Mathematisch Centrum Amsterdam, The Netherlands. All rights reserved. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of Stichting Mathematisch Centrum or CWI not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. STICHTING MATHEMATISCH CENTRUM DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ======================================================================== [View Less]

2 6

(s)re crashing in regrtest (was SRE 0.9.8 benchmarks)
by Mark Favas Aug. 3, 2000

Aug. 3, 2000

[Guido] >> Hmm... here's an old problem that's returned (recursion on repeated >> group matches, I expect): >> >> >>> p=re.compile('(x)*') >> >>> p >> <SRE_Pattern object at 0x8127048> >> >>> p.match(500000*'x') >> Segmentation fault (core dumped) > >Ouch. > >Andrew, would you mind adding a test case for that to the re test >suite? It's important that this doesn't come back! In fact, on my machine … [View More]

3 3

Cookies.py in the core (was Tangent to Re: [Tutor] CGI and Python (fwd))
by Moshe Zadka Aug. 3, 2000

Aug. 3, 2000

Do we have a procedure for putting more batteries in the core? I'm not talking about stuff like PEP-206, I'm talking about small, useful modules like Cookies.py. -- Moshe Zadka <moshez(a)math.huji.ac.il> There is no IGLU cabal. http://advogato.org/person/moshez ---------- Forwarded message ---------- Date: Tue, 01 Aug 2000 12:03:12 PDT From: Brian Wisti <bwisti(a)hotmail.com> To: tutor(a)python.org Subject: Tangent to Re: [Tutor] CGI and Python >In contrast, i've been … [View More]

10 23