[ python-Bugs-1194209 ] Error in section 4.2 of Python Tutorial
Bugs item #1194209, was opened at 2005-05-02 23:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194209&group_id=5470 Category: Documentation Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 3 Submitted By: Andrina Kelly (andrina) Assigned to: Nobody/Anonymous (nobody) Summary: Error in section 4.2 of Python Tutorial Initial Comment: The example in section 4.2 of the on-line tutorial should read as follows: >>> # Measure some strings: ... a = ['cat', 'window', 'defenestrate'] >>> for x in a: ... print x, len(a) ... cat 3 window 6 defenestrate 12 currently the print line has len(x) -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-04 08:34 Message: Logged In: YES user_id=80475 Sorry, this is correct as is. I'm not sure why you would think that len(a) is appropriate. That would give the length of the list which is always equal to three. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194209&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-849046 ] gzip.GzipFile is slow
Bugs item #849046, was opened at 2003-11-25 09:45
Message generated for change (Comment added) made by marumari
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849046&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 3
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip.GzipFile is slow
Initial Comment:
gzip.GzipFile is significantly (an order of a magnitude)
slower than using the gzip binary. I've been bitten by this
several times, and have replaced "fd = gzip.open('somefile',
'r')" by "fd = os.popen('gzcat somefile', 'r')" on several
occassions.
Would a patch that implemented GzipFile in C have any
change of being accepted?
--
Comment By: April King (marumari)
Date: 2005-05-04 11:18
Message:
Logged In: YES
user_id=747439
readlines(X) is even worse, as all it does is call
readline() X times.
readline() is also biased towards files where each line is
less than 100 characters:
readsize = min(100, size)
So, if it's longer than that, it calls read, which calls
_read, and so on. I've found using popen to be roughly 20x
faster than using the gzip module. That's pretty bad.
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2003-12-28 10:25
Message:
Logged In: YES
user_id=580910
Leaving out the assignment sure sped thing up, but only because
the input didn't contain lines anymore ;-)
I did an experiment where I replaced self.extrabuf by a list, but
that did slow things down. This may be because there seemed to
be very few chunks in the buffer (most of the time just 2)
According to profile.run('testit()') the function below spends about
50% of its time in the readline method:
def testit()
fd = gzip.open('testfile.gz', 'r')
ln = fd.readline()
cnt = bcnt = 0
while ln:
ln = fd.readline()
cnt += 1
bcnt += len(ln)
print bcnt, cnt
return bcnt,cnt
testfile.gz is a simple textfile containing 40K lines of about 70
characters each.
Replacing the 'buffers' in readline by a string (instead of a list)
slightly speeds things up (about 10%).
Other experiments did not bring any improvement. Even writing a
simple C function to split the buffer returned by self.read() didn't
help a lot (splitline(strval, max) -> match, rest, match is strval
upto the first newline and at most max characters, rest is the rest
of strval).
--
Comment By: A.M. Kuchling (akuchling)
Date: 2003-12-23 11:10
Message:
Logged In: YES
user_id=11375
It should be simple to check if the string operations are responsible
-- comment out the 'self.extrabuf = self.extrabuf + data'
in _add_read_data. If that makes a big difference, then _read
should probably be building a list instead of modifying a string.
--
Comment By: Brett Cannon (bcannon)
Date: 2003-12-04 13:51
Message:
Logged In: YES
user_id=357491
Looking at GzipFile.read and ._read , I think a large chunk of time
is burned in the decompression of small chunks of data. It initially
reads and decompresses 1024 bits, and then if that read did not
hit the EOF, it multiplies it by 2 and continues until the EOF is
reached and then finishes up.
The problem is that for each read a call to _read is made that sets
up a bunch of objects. I would not be surprised if the object
creation and teardown is hurting the performance. I would also
not be surprised if the reading of small chunks of data is an initial
problem as well. This is all guesswork, though, since I did not run
the profiler on this.
*But*, there might be a good reason for reading small chunks. If
you are decompressing a large file, you might run out of memory
very quickly by reading the file into memory *and* decompressing
at the same time. Reading it in successively larger chunks means
you don't hold the file's entire contents in memory at any one
time.
So the question becomes whether causing your memory to get
overloaded and major thrashing on your swap space is worth the
performance increase. There is also the option of inlining _read
into 'read', but since it makes two calls that seems like poor
abstraction and thus would most likely not be accepted as a
solution. Might be better to just have some temporary storage in
an attribute of objects that are used in every call to _read and
then delete the attribute once the reading is done. Or maybe
allow for an optional argument to read that allowed one to specify
the initial read size (and that might be a good way to see if any of
these ideas are reasonable; just modify the code to read the
whole thing and go at it from that).
But I am in no position to make any of
[ python-Bugs-1194497 ] ImportError: No module named os
Bugs item #1194497, was opened at 2005-05-03 14:50 Message generated for change (Settings changed) made by diskman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None >Priority: 9 Submitted By: Will L G (diskman) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named os Initial Comment: Compiling on the following system: Redhat 7.2 [alpha] Kernel-2.6.11.4 Compaq C 6.5.9 GLIBC-2.3.2 Make-2.80 Binutils-2.15 Receiving the following error: /usr/share/printconf/util/queueTree.py:89: GtkWarning: gtk_label_set_use_underline: assertion `GTK_IS_LABEL (label)' failed domain = domain) Traceback (most recent call last): File "/usr/sbin/redhat-config-printer-gui", line 7, in ? import queueTree File "/usr/share/printconf/util/queueTree.py", line 1091, in ? queueTree() File "/usr/share/printconf/util/queueTree.py", line 128, in __init__ if cups_import.import_needed (): File "/usr/share/printconf/util/cups_import.py", line 200, in import_needed which = which_spooler () File "/usr/share/printconf/util/cups_import.py", line 195, in which_spooler return which UnboundLocalError: local variable 'which' referenced before assignment -- Comment By: Will L G (diskman) Date: 2005-05-03 14:53 Message: Logged In: YES user_id=312992 Whoops, did a cut and paste... the previous error was from printconfig... I was upgrading python to fix that and this is what I received from Python while building: [EMAIL PROTECTED] Python-2.4.1]# make case $MAKEFLAGS in *-s*) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py -q build;; *) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py build;; esac Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re ImportError: No module named os make: *** [sharedmods] Error 1 [EMAIL PROTECTED] Python-2.4.1]# -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194497&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1195576 ] [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings
Bugs item #1195576, was opened at 2005-05-04 18:13 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=1195576&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings Initial Comment: "[ 1190012 ] don't assume all errors are syntax errors" should also check allow SyntaxWarnings to pass. This is a one-line fix at around line 104 in ast_error_finish in ast.c. This causes the failure in test_warnings.py. Brett, If you really want a patch, I can get you one, but right now my copy of ast.c is a little too far out of sync to generate a clean patch. The fix is pretty trivial though. Let me know. -Grant -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195576&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1195576 ] [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings
Bugs item #1195576, was opened at 2005-05-04 18:13 Message generated for change (Settings changed) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195576&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) >Assigned to: Brett Cannon (bcannon) Summary: [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings Initial Comment: "[ 1190012 ] don't assume all errors are syntax errors" should also check allow SyntaxWarnings to pass. This is a one-line fix at around line 104 in ast_error_finish in ast.c. This causes the failure in test_warnings.py. Brett, If you really want a patch, I can get you one, but right now my copy of ast.c is a little too far out of sync to generate a clean patch. The fix is pretty trivial though. Let me know. -Grant -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195576&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1190012 ] ``from sys import stdin, `` doesn't raise a SyntaxError
Bugs item #1190012, was opened at 2005-04-26 01:11 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190012&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: ``from sys import stdin,`` doesn't raise a SyntaxError Initial Comment: Python 2.4 raises a SyntaxError: "trailing comma not allowed without surrounding parentheses". Detected by test_compile. -- Comment By: logistix (logistix) Date: 2005-05-04 18:14 Message: Logged In: YES user_id=699438 Patch 1194895 fixes this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190012&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
