GeezerVisonThe World Wide Web, restored to 800 pixels of glory. |
| Home|About|Gaming cabinet|Archives|How it works|Starter sites |
GeezerVison is showing mail.python.org — Mailman 3 July 2000 - Python-Dev - python.org Python-Dev
Threads by month
July 2000
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
> 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/)
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
Re: [Python-Dev] test_fork1 on SMP? (was Re: [Python Dev] test_fork1 failing --with-threads (for some people)...)
by Jeremy Hylton Aug. 9, 2000 Aug. 9, 2000
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()
RE: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python
by Barry Scott Aug. 8, 2000 Aug. 8, 2000
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
>>> 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>
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.
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!
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
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/)
|
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |
