[ python-Bugs-1682940 ] os.walk should traverse outward symlinks
Bugs item #1682940, was opened at 2007-03-18 02:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682940&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Tasci Synx (synx13) Assigned to: Nobody/Anonymous (nobody) Summary: os.walk should traverse outward symlinks Initial Comment: To my dismay, I discovered that os.walk will ignore all symlinks, even symlinks that link to somewhere outside of the directory being walked. So I made a little patch to os.py, I hope you apply it, or some figment thereof. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-18 08:19 Message: Logged In: YES user_id=849994 Originator: NO The detection of "outward" symlinks is unreliable because there may be a link there which links "back" into the walked hierarchy. For 2.6, os.walk already has a "followlinks" keyword argument, which will follow *all* symlinks. You can easily restrict them by removing them from the "dirs" list yielded to the caller. Closing as outdated. IMO, the one thing that could be improved is to have a cache of visited directories, and to not visit one if it's in the cache. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682940&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1663329 ] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi
Bugs item #1663329, was opened at 2007-02-19 12:17
Message generated for change (Comment added) made by pjdelport
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: H. von Bargen (hvbargen)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi
Initial Comment:
If the value of sysconf("SC_OPEN_MAX") is high
and you try to start a subprocess with subprocess.py or os.popen2 with
close_fds=True, then starting the other process is very slow.
This boils down to the following code in subprocess.py:
def _close_fds(self, but):
for i in xrange(3, MAXFD):
if i == but:
continue
try:
os.close(i)
except:
pass
resp. the similar code in popen2.py:
def _run_child(self, cmd):
if isinstance(cmd, basestring):
cmd = ['/bin/sh', '-c', cmd]
for i in xrange(3, MAXFD):
try:
os.close(i)
except OSError:
pass
There has been an optimization already (range has been replaced by xrange to
reduce memory impact), but I think the problem is that for high values of
MAXFD, usually a high percentage of the os.close statements will fail, raising
an exception (which is an "expensive" operation).
It has been suggested already to add a C implementation called "rclose" or
"close_range" that tries to close all FDs in a given range (min, max) without
the overhead of Python exception handling.
I'd like emphasize that this is not a theoretical, but a real world problem:
We have a Python application in a production environment on Sun Solaris. Some
other software running on the same server needed a high value of 26 for
SC_OPEN_MAX (set with ulimit -n XXX or in some /etc/-file (don't know which
one).
Suddenly calling any other process with subprocess.Popen (..., close_fds=True)
now took 14 seconds (!) instead of some microseconds.
This caused a huge performance degradation, since the subprocess itself only
needs only a few seconds.
See also:
Patches item #1607087 "popen() slow on AIX due to large FOPEN_MAX value".
This contains a fix, but only for AIX - and I think the patch does not support
the "but" argument used in subprocess.py.
The correct solution should be coded in C, and should
do the same as the _close_fds routine in subprocess.py.
It could be optimized to make use of (operating-specific) system calls to close
all handles from (but+1) to MAX_FD with "closefrom" or "fcntl" as proposed in
the patch.
--
Comment By: Piet Delport (pjdelport)
Date: 2007-03-18 18:43
Message:
Logged In: YES
user_id=1607528
Originator: NO
I've been bitten by this too: close_fds turns my a trivial little
monitoring daemon (that reads the output of another status-reporting
command once a second or so) into a monster that hogs the entire server.
As H. von Bargen says, this kind of degradation should at least come with
a warning (or, better, be fixed by C/Pyrex-ifying close_fds).
--
Comment By: H. von Bargen (hvbargen)
Date: 2007-02-22 22:16
Message:
Logged In: YES
user_id=1008979
Originator: YES
Of course I am already closing any files as soon as possible.
I know that I could use FD_CLOEXEC. But this would require that I do it
explicitly for each descriptor that I use in my program. But this would be
a tedious work and require platform-specific coding all around the program.
And the whole bunch of python library functions (i.e. the logging module)
do not use FD_CLOEXEC as well.
Right now, more or less the only platform specific code in the program is
where I call subprocesses, and I like to keep it that way.
The same is true for the socket module. All sockets are by default
inherited to child processes.
So, the only way to prevent unwanted handles from inheriting to child
processes, is in fact to specify close_fds=True in subprocess.py.
If you think that a performance patch similar to the patch #16078087 makes
no sense, then the close_fds argument should either be marked as deprecated
or at least the documentation should mention that the implementation is
slow for large values of SC_OPEN_MAX.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-02-21 20:18
Message:
Logged In: YES
user_id=21627
Originator: NO
I understand you don't want the subprocess to inherit "incorrect" file
descriptors. However, there are other ways to prevent that fro
[ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run
Bugs item #1581906, was opened at 2006-10-21 13:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) >Assigned to: Thomas Heller (theller) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip -- >Comment By: Skip Montanaro (montanaro) Date: 2007-03-18 12:20 Message: Logged In: YES user_id=44345 Originator: YES Thomas, I assigned this to you simply so you can cast your eye on the problem and see if you think there might be anything ctypes-related in the problem I've reported. I've ignored it up 'til now, but I bumped up against it again trying to get the Pybots SQLAlchemy test suite running on my Mac. During my previous encounter with this problem Ronald Oussouren reported on a possible connection with GLUT: http://mail.python.org/pipermail/python-dev/2006-October/069523.html Assuming there is no obvious ctypes connection you can determine (it's not clear to me that there is any current directory funny business going on) just assign it back to me and I'll try to find a pysqlite expert to take a look. Thx, Skip -- Comment By: Skip Montanaro (montanaro) Date: 2006-10-21 13:04 Message: Logged In: YES user_id=44345 Another article here: http://article.gmane.org/gmane.comp.python.devel/84487 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1650903 ] PyFloat_FromString deprecated form
Bugs item #1650903, was opened at 2007-02-02 19:41 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: PyFloat_FromString deprecated form Initial Comment: PyFloat_FromString takes two arguments, and the only purpose of the second is to avoid changing the API. Extracts from Tim's 2000 comment: Since we can't change the interface of a public API function, pend is still supported but now *officially* useless: if pend is not NULL, *pend is set to NULL. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-18 18:35 Message: Logged In: YES user_id=849994 Originator: NO Okay, I fixed this case in rev. 54433. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-18 03:55 Message: Logged In: YES user_id=6380 Originator: NO I think I should relax that statement a bit. IMO it's OK to change the signature (for Py3k) since the compiler will report an error if you call it with the old signature. What's *not* OK is to keep the signature (or to keep it compatible anyway) but change the *behavior*, as that would cause bugs that are only caught (if at all) at runtime, and will hence be hard to debug. Examples of bad changes would be changing the reference count behavior of an API, changing the type of object returned (if a specific type was previously documented) or making it possible to return NULL where this was previous not possible. -- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-07 00:06 Message: Logged In: YES user_id=764593 Originator: YES I didn't realize that a decision had been made about the C API stability. I would indeed propose changing it, but probably not if it the rest of the API (even for strings and unicode?) is supposed to stay stable. -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:54 Message: Logged In: YES user_id=849994 Originator: NO (cont'd) C API functions shouldn't even change signature in Py 3000. Therefore, a new name would be needed... -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:53 Message: Logged In: YES user_id=849994 Originator: NO What do you propose to do? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1527705 ] optparse should support arbitrary number of arguments
Feature Requests item #1527705, was opened at 2006-07-24 12:03
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Ritesh Raj Sarraf (riteshsarraf)
Assigned to: Greg Ward (gward)
Summary: optparse should support arbitrary number of arguments
Initial Comment:
Currently, the number of arguments an option
can/should have, needs be defined.
This is done using "nagrs".
parser.add_option("", "--my-option", nargs=3)
The problem is that at times it isn't predictable how
many arguments you'll be receiving.
I request the implementation of this feature in
optparse, where the following could be possible.
parser.add_option("", "--my-option", nargs=*)
Thanks,
Ritesh
--
Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2007-03-16 09:18
Message:
Logged In: YES
user_id=382018
Originator: YES
Thanks for clarifying Neal.
I've filed a bug with optik, #1681933
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-16 07:47
Message:
Logged In: YES
user_id=33168
Originator: NO
I encourage you to file a feature request with optik if it's important to
you.
While it may not be the nicest way, it's the only way we can get anything
done. I pointed you to optik so you can file the feature request if it's
important to you. What has happened in the past is that this report would
be left open forever. That is worse.
If you think this is wrong, you can fix the problem by helping us resolve
all the issues in python. Otherwise, there's no hope of us managing it.
--
Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2007-03-16 07:37
Message:
Logged In: YES
user_id=382018
Originator: YES
I don't think this is the correct way of resolving a bug. You mark it as
"Close" with a resolution "Invalid" when the bug was filed against "Python
Library", of which optparse is one. Python ships optparse as part of its
libraries.
If internally, it is a separate project, you could file one there and link
to it.
But why just plain close it ?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-16 06:44
Message:
Logged In: YES
user_id=33168
Originator: NO
Optik is maintained separately. Please file a feature request there:
http://sourceforge.net/projects/optik
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 13:31
Message:
Logged In: YES
user_id=849994
I share effbot's view on that, but leaving to Greg to
decide. In any case, this is a feature request.
--
Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2006-07-24 13:21
Message:
Logged In: YES
user_id=382018
Can you please go through the following link and give your
comments ?
http://groups.google.com/group/comp.lang.python/browse_thre
ad/thread/277522927334b8d8
I feel its a valid feature request.
Ritesh
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 12:57
Message:
Logged In: YES
user_id=849994
I don't know of any program that uses command line switches
with a variable number of args, partly because you then
cannot distinguish between option arguments and normal
arguments.
I you still need this, you can implement a custom callback,
I think.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1683288 ] xreload.py won't update class docstrings
Bugs item #1683288, was opened at 2007-03-18 18:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683288&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: xreload.py won't update class docstrings
Initial Comment:
"""
def _update_class(oldclass, newclass):
...
for name in oldnames & newnames - {"__dict__", "__doc__"}:
setattr(oldclass, name, _update(olddict[name], newdict[name]))
return oldclass
"""
I assume __doc__ is skipped because a string can't be updated in place. But
since oldclass is returned, __doc__ should still be replaced with the updated
documentation.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683288&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1666807 ] Incorrect file path reported by inspect.getabsfile()
Bugs item #1666807, was opened at 2007-02-23 07:08 Message generated for change (Comment added) made by fer_perez You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fernando P�rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect file path reported by inspect.getabsfile() Initial Comment: The following code demonstrates the problem succinctly: ### import inspect,sys print 'Version info:',sys.version_info print f1 = inspect.getabsfile(inspect) f2 = inspect.getabsfile(inspect.iscode) print 'File for `inspect` :',f1 print 'File for `inspect.iscode`:',f2 print 'Do these match?',f1==f2 if f1==f2: print 'OK' else: print 'BUG - this is a bug in this version of Python' ### EOF Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces: tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py Version info: (2, 3, 6, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.3/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py Do these match? True OK tlon[bin]> python2.4 ~/code/python/inspect_bug.py Version info: (2, 4, 4, 'candidate', 1) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python tlon[bin]> python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python ### The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path. This changed between 2.3 and 2.4, but the inspect module was never updated. This code: ### import inspect,sys print 'Python version info:',sys.version_info print 'File info for `inspect.iscode function`:' print ' ',inspect.iscode.func_code.co_filename print ### EOF shows the problem: tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py Python version info: (2, 3, 6, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.3/inspect.py tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: inspect.py ### (2.4 has the same issue). Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days. -- >Comment By: Fernando P�rez (fer_perez) Date: 2007-03-18 23:49 Message: Logged In: YES user_id=395388 Originator: YES Yes, though at least in this report we seem to have narrowed down the problem a little better. I'm perfectly willing to believe that Ubuntu is somehow mis-building their shipped Python, but it would be great if the Python build itself could be hardened against this being possible in the first place. Unfortunately I don't know how to better track the problem, but I'll be glad to provide info from my local system upon request. -- Comment By: Žiga Seilnacht (zseil) Date: 2007-03-16 14:06 Message: Logged In: YES user_id=1326842 Originator: NO It looks like this is a bug in Ubuntu build process. The logging package had the same problem: http://www.python.org/sf/1669498 http://www.python.org/sf/1633605 http://www.python.org/sf/1616422 -- Comment By: Fernando P�rez (fer_perez) Date: 2007-03-09 02:00 Message: Logged In: YES user_id=395388 Originator: YES As I mentioned, on hand-built Pythons I don't get the bug at all. So it may be a problem with how Ubuntu builds its Python, since I can reproduce the problem with both 2.4 and 2.5, but only with the default ones provided by Ubuntu Edgy. I don't know enough about their packaging system to know how to retrieve build info. There may be something odd in their build, but it would be nice if this simply couldn't happen at all. If anyone knows how to retrieve the relevant info from an ubuntu build, I'll be happy to try and provide it. -- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 00:04 Message: Logged In: YES user_id=1344176 Originator: NO I haven't
[ python-Bugs-1683316 ] select.select() injecting spurious text in stdout
Bugs item #1683316, was opened at 2007-03-19 10:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Williams (peter_ono) Assigned to: Nobody/Anonymous (nobody) Summary: select.select() injecting spurious text in stdout Initial Comment: I'm using a function (see attachment) similar to that described on Page 386 (Section 9.12) of the Python Cookbook (Second Edition) to capture the stdout and stderr streams of programs run with popen2.Popen3. This involves using select.select() to detect the availability of data on the two streams. Sometimes, what looks like a debugging message: "EXCEPTION IN SAFE SELECT 9\n" gets injected into the stdout stream. As far as I can tell this has only started occuring after updating to version 2.4.4. No exception occurs and the string just silently appears in stdout. Apart from the bogus text in stdout everything seems to be working correctly and I'm able to work around the problem by looking for the string and removing whenever it occurs. It looks to me like a debugging message that somebody forgot to remove. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683316&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1528074 ] difflib.SequenceMatcher.find_longest_match() wrong result
Bugs item #1528074, was opened at 2006-07-24 19:59 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Machin (sjmachin) Assigned to: Tim Peters (tim_one) Summary: difflib.SequenceMatcher.find_longest_match() wrong result Initial Comment: A short example script is attached. Two strings, each 500 bytes long. Longest match is the first 32 bytes of each string. Result produced is a 10-byte match later in the string. If one byte is chopped off the end of each string (len now 499 each), the correct result is produced. Other observations, none of which may be relevant: 1. Problem may be in the heuristic for "popular" elements in the __chain_b method. In this particular example, the character '0' (which has frequency of 6 in the "b" string) is not "popular" with a len of 500 but is "popular" with a len of 499. 2. '0' is the last byte of the correct longest match. 3. The correct longest match is at the start of the each of the strings. 4. Disabling the "popular" heuristic (like below) appears to make the problem go away: if 0: # if n >= 200 and len(indices) * 100 > n: populardict[elt] = 1 del indices[:] else: indices.append(i) 5. The callable self.isbpopular is created but appears to be unused. 6. The determination of "popular" doesn't accord with the comments, which say 1%. However with len==500, takes 6 to be popular. -- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-18 21:51 Message: Logged In: YES user_id=764593 Originator: NO I think the bug is documentation only. According to the comments (but not the docstring) find_longest_match returns the longest _interesting_ match. A single element appearing too often is likely to cause spurious matches, and is therefore not interesting. I do agree that this should be noted more prominently, so people don't try things like comparing text strings letter-by-letter (where 1% is far too low a threshhold for a 26-character alphabest). And yes, the comments on popular are correct -- it ignores elements which constitute *more* than 1%. I recommend closing this set of tracker items. If you could submit changes to the documentation (docstrings and/or help files; maybe even the comments), I would recommend applying them. -- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-14 16:11 Message: Logged In: YES user_id=1416496 Originator: NO By the way, I found that the implementation should better be changed completely. The current one has a O(n^2) computational complexity, while the one, based on suffix trees using Ukkonen's algorithm would use only O(n) -- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-11 11:29 Message: Logged In: YES user_id=1416496 Originator: NO I have sent a testcase for this bug into the SourceForge. The ID is #1678339. Also I have submitted a fix for this bug (ID #1678345), but the fix reduces the performance significantly. -- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-10 12:24 Message: Logged In: YES user_id=1416496 Originator: NO The quick test for this bug is: for i in xrange(190, 200): text1 = "a" + "b"*i text2 = "b"*i + "c" m = difflib.SequenceMatcher(None, text1, text2) (aptr,bptr,l) = m.find_longest_match(0, len(text1), 0, len(text2)) print "i:", i, " l:", l, " aptr:", aptr, " bptr:", bptr assert l == i The assertion will fail when i==199 (the length of the texts will be 200). And yes, the bug is clearly "populardict"-related. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681984 ] unittest documentation is incomplete
Bugs item #1681984, was opened at 2007-03-16 11:17 Message generated for change (Comment added) made by haypo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: unittest documentation is incomplete Initial Comment: When I tried to write a test suite using many test cases, I read the documentation (docs.python.org) but it does work because I was unable to run my test suite. Using Google I realised that documentation is incomplete! In Python binding of gstreamer, I found a "TextTestRunner"! So, would it be possible to update the doc? -- >Comment By: STINNER Victor (haypo) Date: 2007-03-19 03:00 Message: Logged In: YES user_id=365388 Originator: YES "Could you please state what exactly is missing from the documentation, in your opinion?" Well, when I ready Python documentation I expect to have the full list of "builtin" modules, functions and classes. But if you check unittest module, documentation only list TestCase, TestSuite, TestResult and TestLoader. Whereas dir(unittest) gives TestCase, TestLoader, *TestProgram*, TestResult, TestSuite, *TextTestRunner*. So information about TestProgram and TextTestRunner is missing. I also expect a small example showing how to use a test runner and a test suite. I'm using: -- 8< --- from unittest import TestSuite, TestLoader, TextTestRunner from sys import exit def loadTests(loader): """Generator listing all test cases""" ... def main(): loader = TestLoader() suite = TestSuite() for test in loadTests(loader.loadTestsFromTestCase): suite.addTests(test) runner = TextTestRunner(descriptions=2, verbosity=2) result = runner.run(suite) if result.failures or result.errors: exit(1) -- 8< --- -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 14:02 Message: Logged In: YES user_id=849994 Originator: NO Could you please state what exactly is missing from the documentation, in your opinion? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 20:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Nobody/Anonymous (nobody) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
