Mailman 3 July 2000 - Python-Dev

Application for developer status
by Eric S. Raymond 09 Oct '00

09 Oct '00

May I have developer status on the SourceForge CVS, please? I maintain two standard-library modules (shlex and netrc) and have been involved with the development of several others (including Cmd, smtp, httplib, and multifile). My only immediate plan for what to do with developer access is to add the browser-launch capability previously discussed on this list. My general interest is in improving the standard class library, especially in the areas of Internet-protocol support (urllib, ftp, telnet, pop, imap, smtp, nntplib, etc.) and mini-language toolkits and frameworks (shlex. netrc, Cmd, ConfigParser). If the Internet-protocol support in the library were broken out as a development category, I would be willing to fill the patch-handler slot for it. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs. -- Dave Barry

8 16

Re: [I18n-sig] Unicode experience
by Guido van Rossum 05 Sep '00

05 Sep '00

> Toby Dickenson wrote: > > > > I'm just nearing the end of getting Zope to play well with unicode > > data. Most of the changes involved replacing a call to str, in > > situations where either a unicode or narrow string would be > > acceptable. > > > > My best alternative is: > > > > def convert_to_something_stringlike(x): > > if type(x)==type(u''): > > return x > > else: > > return str(x) > > > > This seems like a fundamental operation - would it be worth having > > something similar in the standard library? Marc-Andre Lemburg replied: > You mean: for Unicode return Unicode and for everything else > return strings ? > > It doesn't fit well with the builtins str() and unicode(). I'd > say, make this a userland helper. I think this would be helpful to have in the std library. Note that in JPython, you'd already use str() for this, and in Python 3000 this may also be the case. At some point in the design discussion for the current Unicode support we also thought that we wanted str() to do this (i.e. allow 8-bit and Unicode string returns), until we realized that there were too many places that would be very unhappy if str() returned a Unicode string! The problem is similar to a situation you have with numbers: sometimes you want a coercion that converts everything to float except it should leave complex numbers complex. In other words it coerces up to float but it never coerces down to float. Luckily you can write that as "x+0.0" while converts int and long to float with the same value while leaving complex alone. For strings there is no compact notation like "+0.0" if you want to convert to string or Unicode -- adding "" might work in Perl, but not in Python. I propose ustr(x) with the semantics given by Toby. Class support (an __ustr__ method, with fallbacks on __str__ and __unicode__) would also be handy. > BTW, could you elaborate a bit on your experience with adding > Unicode support to Zope ? Such a report would certainly make > a nice complement to the Unicode tutorial and help other > people adding Unicode support to their apps. Yes, that's what we need. Thanks to Toby for pioneering this! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/)

11 17

Python-dev summary: Jul 1-15
by Andrew Kuchling 18 Aug '00

18 Aug '00

Note: this is an experiment in whether I can make a useful, interesting, somewhat coherent summary of python-dev activity. Things I'm not sure of: * Accuracy. I skipped past some threads such as the list comprehensions one, and may be unaware of a resolution. * How many links are needed? Should I try to link to several posts per thread, SF patches, etc.? That makes more work for me, but also makes the summary more useful. * Bi-weekly OK? I think it's a reasonable frequency. I'll check my e-mail tomorrow; if no one screams loudly, I'll post it. (My connectivity is poor enough that I don't want to do major editing on it, or be able to respond to many e-mails in detail.) ================== Python-dev summary, July 1-15, 2000: The 2-week period started with reactions to Guido's June 30 announcement that the 2.0b1 release would be delayed for an indefinite period due to legal wrangling. This gave everyone a second chance to contribute more patches while waiting for the release, and the activity level remained high. Two dominant issues for this time period were Unicode-related issues, and list comprehensions. The Unicode issues, as usual, turned on the question of where strings and Unicode strings should be interchangeable. A discussion in the thread "Minidom and Unicode" considered whether it's legal to return a Unicode string from __repr__. The consensus was that it should be legal, despite fears of breaking code that expects only an 8-bit string, and the CVS tree was patched accordingly. Python's interpreter mode uses repr() to display the results of expressions, and it will convert Unicode strings to ASCII, using the unicode-escape encoding. The following code, typed into the interpreter, will print 'abc\u3456'. class C: def __repr__(self): return u'abc\u3456' print repr( C() ) Hashing also presented a problem. As M.-A. Lemburg explained in http://www.python.org/pipermail/python-dev/2000-July/012150.html: The problem comes from the fact that the default encoding can be changed to a locale specific value (site.py does the lookup for you), e.g. given you have defined LANG to be us_en, Python will default to Latin-1 as default encoding. This results in 'äöü' == u'äöü', but hash('äöü') != hash(u'äöü'), which is in conflict with the general rule about objects having the same hash value if they compare equal. The resolution seems to be simply removing the ability to change the default encoding and adopt ASCII as the fixed default; if you want to use other encodings, you must specify them explicitly. List comprehensions originated as a patch from Greg Ewing that's now being kept up-to-date versus the CVS tree by Skip Montanaro. Originally they weren't on the roadmap for 1.6, but with the greater version number jump to 2.0, GvR is more willing to incorporate larger changes. List comprehensions provide a more concise way to create lists in situations where map() and filter() would currently be used. To take some examples from the patched-for-list-comphrensions version of the Python Tutorial: >>> spcs = [" Apple", " Banana ", "Coco nut "] >>> print [s.strip() for s in spcs] ['Apple', 'Banana', 'Coco nut'] >>> vec1 = [2, 4, 6] >>> vec2 = [4, 3, -9] >>> print [x*y for x in vec1 for y in vec2] [8, 6, -18, 16, 12, -36, 24, 18, -54] A lengthy subthread about intuitiveness sprang from the second example, and from a patch from Thomas Wouters that implements parallel 'for' loops. The patch makes "for x in [1,2]; y in ['a','b']" cause x,y to be 1,'a', and then 2,'b'. The thread circulated around whether people would expect this syntax to produce the Cartesian product of the two lists: (1,'a'), (1, 'b'), (2, 'a'), (2, 'b'). No clear answer or final syntax has emerged yet, though Greg Wilson has been trying out syntaxes on Python-unaware people and asking them what they'd expect: http://www.python.org/pipermail/python-dev/2000-July/012810.html It was also suggested to add a new built-in function for parallel 'for' loops instead of new syntax, so you would code 'for x,y in zip([1,2], ['a','b']):'. A lengthy and very dull discussion ensued about the name 'zip': should it be 'plait', 'knit', 'parallel', or even 'marry'? Some new procedures for Python development were set out: Tim Peters wrote some guidelines for using SourceForge's patch manager: http://www.python.org/pipermail/python-dev/2000-July/012635.html Barry Warsaw announced a series of Python Extension Proposal (PEP) documents, which play the role of RFCs for significant changes to Python: http://www.python.org/pipermail/python-dev/2000-July/013059.html Mark Hammond gave the first glimpse of a fourth Python implementation: "This new compiler could be compared, conceptually, with JPython - it is a completely new implementation of Python. It has a compiler that generates native Windows .DLL/.EXE files. It uses a runtime that consists of a few thousand lines of C# (C-Sharp) code. The Python programs can be debugged at the source level with Visual Studio 7, as well as stand-alone debuggers for this environment. Python can sub-class VB or C# classes, and vice-versa." http://www.python.org/pipermail/python-dev/2000-July/013019.html Other bits: Skip Montanaro experimented with using code coverage tools to measure the effectiveness of the Python test suite, by seeing which lines of code (both C and Python) that are exercised by the tests. A summary of the results is at: http://www.musi-cal.com/~skip/python/Python/dist/src/summary.html Skip also added support to the readline module for saving and loading command histories. ESR suggested adding a standard lexer to the core, and /F suggested an extension to regular expressions that would make them more useful for tokenizing: http://www.python.org/pipermail/python-dev/2000-July/012032.html CVS problems were briefly a distraction, with dangling locks preventing commits to the Lib/ and Modules/ subdirectories for a few days. Despite such glitches, the move to SourceForge has accelerated development overall, as more people can make check-ins and review them. For some time Tim Peters has been suggesting removing the Py_PROTO macro and making the sources require ANSI C; mostly this is because the macro breaks the C cross-referencing support in Tim's editor. :) The ball finally started rolling on this, and snowballed into a massive set of patches to use ANSI C prototypes everywhere. Fred Drake and Peter Schneider-Kamp rose to the occasion and edited the prototypes in dozens of files. Jeremy Hylton pointed out that "Tuple, List, String, and Dict have a Py*_Size method. The abstract object interface uses PySequence_Length. This is inconsistent and hard to remember," and suggested that *_Size be made the standard form, and *_Length will be deprecated. Just before the cutoff date, Paul Prescod proposed a new help() function for interactive use, and began implementing it: http://www.python.org/pipermail/python-dev/2000-July/013346.html Huaiyu Zhu suggested adding new operators to support matrix math: http://www.python.org/pipermail/python-dev/2000-July/013364.html A slew of minor patches and bugfixes were made, too. Some highlights: * Ka-Ping Yee improved the syntax error messages. * ESR made various changes to ConfigParser.py * Some of Sam Rushing's patches from Medusa were applied to add os.setreuid() and friends; AMK is working on adding the poll() system call. * /F was his usual "patching machine" self, integrating PythonWin's win32popen function so that os.popen will now work correctly on Windows as well as Unix, writing PyErr_SafeFormat() to prevent buffer overflows, and proposing some patches to reduce the 600K size of the Unicode character database. Some fun posts came up during the near-endless zip()/plait()/whatever naming thread: http://www.python.org/pipermail/python-dev/2000-July/012920.html: "BTW: How comes, that Ping very often invents or introduces very clever ideas and concepts, but also very often chooses unclear names for them? Is it just me not being a native english speaker?" "I don't know. Perhaps my florx bignal zupkin isn't very moognacious?" -- Peter Funk and Ka-Ping Yee, 12 Jul 2000 http://www.python.org/pipermail/python-dev/2000-July/013050.html, while everyone was trying to think up alternative names for zip(): "Let me throw one more out, in honor of our fearless leader's recent life change: marry(). Usually only done in pairs, and with two big sequences, I get the image of a big Unification Church event :)" "Isn't it somewhat of a political statement to allow marriages of three or more items? I always presumed that this function was n-ary, like map." -- Barry Warsaw and Paul Prescod

9 9

Re: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...)
by Jeremy Hylton 09 Aug '00

09 Aug '00

This message duplicates some of my previous messages about the thread/fork deadlock. (Received report that some of my earlier messages appear to be lost.) I'm running a simpler version of Neil's test program that uses the thread module instead of the threading module. It's attached at the end of the message (test_fork2.py). It spawns five threads; then each thread, including the main thread, go into a while 1: loop that forks. The program locks up after about 100-200 forks. The process structure looks like this: > ps --forest PID TTY TIME CMD 684 pts/0 00:00:00 bash 783 pts/0 00:00:00 python 784 pts/0 00:00:00 \_ python 785 pts/0 00:00:00 | \_ python 786 pts/0 00:00:00 | \_ python 951 pts/0 00:00:00 | | \_ python <defunct> 787 pts/0 00:00:05 | \_ python 788 pts/0 00:00:04 | \_ python 953 pts/0 00:00:00 | | \_ python 789 pts/0 00:00:00 | \_ python 952 pts/0 00:00:00 | \_ python <defunct> 950 pts/0 00:00:00 \_ python <defunct> 964 pts/0 00:00:00 ps top reports the following CPU activity: PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 787 jeremy 19 0 2048 2048 1940 R 0 52.8 0.7 0:06 python 788 jeremy 17 0 2048 2048 1940 R 0 44.2 0.7 0:06 python If I attached to process 787 with gdb, this is the stack trace I can see: #0 pthread_cond_wait (cond=0x80f297c, mutex=0x80f2988) at queue.h:25 #1 0x806fee3 in PyThread_acquire_lock (lock=0x80f2978, waitflag=1) at ../../Python/thread_pthread.h:311 #2 0x8054ec1 in PyEval_RestoreThread (tstate=0x80fb2f0) at ../../Python/ceval.c:171 #3 0x80c1242 in posix_wait (self=0x0, args=0x80f1cac) at ../../Modules/posixmodule.c:2849 #4 0x8059b83 in call_builtin (func=0x8103578, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2369 #5 0x8059a41 in PyEval_CallObjectWithKeywords (func=0x8103578, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2337 #6 0x80583b1 in eval_code2 (co=0x8144ec0, globals=0x80f25d4, locals=0x0, args=0x80f1cb8, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ../../Python/ceval.c:1675 #7 0x805a01d in call_function (func=0x8144cdc, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2491 #8 0x8059a21 in PyEval_CallObjectWithKeywords (func=0x8144cdc, arg=0x80f1cac, kw=0x0) at ../../Python/ceval.c:2335 #9 0x80b03aa in t_bootstrap (boot_raw=0x8142ad8) at ../../Modules/threadmodule.c:193 #10 0x4001ceca in pthread_start_thread (arg=0xbf3ffe60) at manager.c:213 After I collect the stack trace and restart the program, several other processes start running again: PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 786 jeremy 14 0 2048 2048 1928 R 0 24.6 0.7 0:09 python 788 jeremy 15 0 2048 2048 1928 R 0 24.6 0.7 0:34 python 787 jeremy 17 0 2048 2048 1928 R 0 24.4 0.7 0:34 python 783 jeremy 15 0 2048 2048 1928 R 0 23.8 0.7 0:09 python If I run the process again with thread debugging enabled (Py_DEBUG defined at compiel time and THREADDEBUG set to 1), I get the following trace: PyThread_init_thread called PyThread_allocate_lock() -> 0x80f2010 PyThread_acquire_lock(0x80f2010, 1) called PyThread_acquire_lock(0x80f2010, 1) -> 1 PyThread_release_lock(0x80f2010) called PyThread_allocate_lock called PyThread_allocate_lock() -> 0x80f6c58 PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 Adding parser accelerators ... Done. PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_acquire_lock(0x80f6c58, 0) called PyThread_acquire_lock(0x80f6c58, 0) -> 1 PyThread_release_lock(0x80f6c58) called PyThread_allocate_lock called PyThread_allocate_lock() -> 0x80f6498 PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_start_new_thread called [lots of stuff omitted] 2051 2127 PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 1024 2130 PyThread_release_lock(0x80f6498) called PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_acquire_lock(0x80f6498, 1) called PyThread_acquire_lock(0x80f6498, 1) -> 1 PyThread_release_lock(0x80f6498) called [blocks] In this case, the deadlock occurs much more quickly. (Perhaps the extra I/O produced by the debugging output exacerbates the problem.) Jeremy PS If you don't have access to a Linux machine, you can use one of the Linux test machines on the SF compile farm. Log into linux.compile.sourceforge.net. import os import thread def f(): while 1: if os.fork() == 0: print "%s %s" % (thread.get_ident(), os.getpid()) os._exit(0) os.wait() thread.start_new_thread(f, ()) thread.start_new_thread(f, ()) thread.start_new_thread(f, ()) thread.start_new_thread(f, ()) thread.start_new_thread(f, ()) f()

4 3

RE: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python
by Barry Scott 08 Aug '00

08 Aug '00

Mark's comment about what I'd come up with being too complex inspired this simpler solution. Change the init function name to a new name PythonExtensionInit_ say. Pass in the API version for the extension writer to check. If the version is bad for this extension returns without calling any python functions. Add a return code that is true if compatible, false if not. If compatible the extension can use python functions and report and problems it wishes. int PythonExtensionInit_XXX( int invoking_python_api_version ) { if( invoking_python_api_version != PYTHON_API_VERSION ) { /* python will report that the module is incompatible */ return 0; } /* setup module for XXX ... */ /* say this extension is compatible with the invoking python */ return 1; } All 1.5 extensions fail to load on later python 2.0 and later. All 2.0 extensions fail to load on python 1.5. All new extensions work only with python of the same API version. Document that failure to setup a module could mean the extension is incompatible with this version of python. Small code change in python core. But need to tell extension writers what the new interface is and update all extensions within the python CVS tree. Barry

6 14

SRE incompatibility
by Sjoerd Mullender 07 Aug '00

07 Aug '00

>>> regexp = '(([a-z]+):)?([a-z]+)$' >>> import re >>> re.match(regexp, 'smil').group(0,1,2,3) ('smil', None, 's', 'smil') >>> import pre >>> pre.match(regexp, 'smil').group(0,1,2,3) ('smil', None, None, 'smil') Needless to say, I am relying on the third value being None... (My regular expression was actually more like '(?:(?P<prefix>[a-z]+):)?(?P<suffix>[a-z]+)$' and I check for result.group('prefix')) -- Sjoerd Mullender <sjoerd.mullender(a)oratrix.com>

2 2

New winreg module really an improvement?
by Mark Hammond 07 Aug '00

07 Aug '00

Ive just updated the test suite so that test_winreg2.py actually works. It appears that the new winreg.py module is still in a state of flux, but all work has ceased. The test for this module has lots of placeholders that are not filled in. Worse, the test code was checked in an obviously broken state (presumably "to be done", but guess who the bunny who had to do it was :-( Browsing the source made it clear that the module docstrings are still incomplete (eg "For information on the key API, open a key and look at its docstring."). As far as I can tell, there is no documentation in the library reference for this module (but the underlying _winreg module does have reasonable documentation) This is the first time I have had a serious look at the new winreg module, and the first time I have had to use it. I found it quite unintuitive, and it took me quite some time to update the test suite for what should have been a trivial case: Eg, the specific example I had a problem with was: key[value] Returns a result that includes the key index! This would be similar to a dictionary index _always_ returning the tuple, and the first element of the tuple is _always_ the key you just indexed. Has anyone else actually looked at or played with this, and still believe it is an improvement over _winreg? I personally find it unintuitive, and will personally continue to use _winreg. If we can't find anyone to complete it, document it, and stand up and say they really like it, I suggest we pull it. Still-can't-see-the-added-value-ly, Mark.

10 23

PEP 203 Augmented Assignment
by Thomas Wouters 04 Aug '00

04 Aug '00

No, this isn't the first full draft of the PEP :P While writing up the proposed VM changes, I came to the conclusion my patch was all wrong, and I would like some input in case I forgot something. The current patch introduces the following bytecodes: GETSET_SUBSCR GETSET_SLICE GETSET_SLICE+1 GETSET_SLICE+2 GETSET_SLICE+3 GETSET_ATTR GETSET_NAME GETSET_FAST GETSET_GLOBAL Each bytecode does the loading of the object, the actual operation it is supposed to perform, and the storing in the original place. All opcodes get an argument to specify which operation should be performed, which is also where the need for 2-argument opcodes comes from: the NAME/FAST/GLOBAL opcodes need both a name-index and an opcode argument. My excuse for this design is similar to Guido's excuse for the current Python parser: I was young, I was foolish, and I didn't know how to reuse things, only how to *add* things ;) I was also intimidated by the whole idea of a stack, having never really programmed in a low-level programming language before. I now realize only 11 new opcodes are necessary, and it can even be reduced to 1, by splitting the operation into seperate LOAD, <operation>, and STORE instructions, with a few ROT_TWO and ROT_THREE's mixed in. <operation> could be a new bytecode for each operation (11 in total) or a single 'AUGOP' bytecode with an argument to specify the operation. I think it's less elegant from the bytecode point of view, but it does require a lot less changes in ceval/compile. There is only one significant difference between the current version and this, and that's behaviour in the face of threads. I had originally seen augmented assignment as a way to increment a counter 'thread-safe': the load and store operation are done in one bytecode, and can thus not be interrupted by a thread switch. But after thinking about it, it doesn't make that much sense. It only works for builtin types, not for classes defining a __op_ab__, and possibly not for extention types. In fact, there might be some possibility for a thread switch even in builtin types, though I have never looked at that. Opinions ? Is the semi-reliability in the face of threads a good idea ? Did I miss anything important about the current implementation ? Should I forget about this idea and keep the patch as it is (and go back to my PEP) or should I rewrite the patch and then rewrite the PEP ? This alternate implementation would eradicate my next-to-last objection to including the patch, I think, but we'll discuss the last one, the naming of the __hooks__, after I finish the bloody PEP ;-) -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

19 88

Summary or failing regression tests...
by Trent Mick 03 Aug '00

03 Aug '00

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/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

16 44

Should repr() of string should observe locale?
by Guido van Rossum 01 Aug '00

01 Aug '00

There have been some requests (Francois Pinard, recently Alexander Voinov) that repr() of a string should not use escape sequences for characters that are printable according to the locale. I don't have the time to write a PEP or implement it (although it should be simple enough) but it needs to be recorded as a feature that I think is good (that's at least a +0). --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

5 7