[ python-Bugs-1210377 ] Cursors not correctly closed after exception.
Bugs item #1210377, was opened at 2005-05-28 14:48
Message generated for change (Comment added) made by ragnar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210377&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
Submitted By: Ragnar Ouchterlony (ragnar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cursors not correctly closed after exception.
Initial Comment:
If an exception occurs when going through a database,
the cursors will not be correctly reset.
If I manually set the cursor to None (by doing db.dbc =
None) it will work fine.
>>> db = bsddb.btopen('/tmp/test.db', 'c')
>>> db.first()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/bsddb/__init__.py", line
264, in first
rv = self.dbc.first()
_bsddb.DBNotFoundError: (-30990, 'DB_NOTFOUND: No
matching key/data pair found')
>>> db['foo'] = 'bar'
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/bsddb/__init__.py", line
217, in __setitem__
self._closeCursors()
File "/usr/lib/python2.4/bsddb/__init__.py", line
192, in _closeCursors
self.saved_dbc_key = c.current(0,0,0)[0]
bsddb._db.DBInvalidArgError: (22, 'Invalid argument --
Cursor position must be set before performing this
operation')
Here, I first open a new database. Since it is empty,
db.first() will fail. When I after that try to add a
key/value pair to the database it fails, since it tries
to close an invalid cursor.
>>> db = bsddb.btopen('/tmp/test.db', 'c')
>>> db.first()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/bsddb/__init__.py", line
264, in first
rv = self.dbc.first()
_bsddb.DBNotFoundError: (-30990, 'DB_NOTFOUND: No
matching key/data pair found')
>>> db.dbc = None
>>> db['foo'] = 'bar'
>>> db
{'foo': 'bar'}
Here I do "db.dbc = None" after the exception and now
it works just fine.
--
>Comment By: Ragnar Ouchterlony (ragnar)
Date: 2005-05-30 09:59
Message:
Logged In: YES
user_id=1394
The bugreport refers to bsddb. I did not make that entirely
clear.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210377&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1207466 ] installer ignores changed installation directory
Bugs item #1207466, was opened at 2005-05-24 04:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207466&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: Installation Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Blubb Fallo (blubbfallo) >Assigned to: Martin v. Löwis (loewis) Summary: installer ignores changed installation directory Initial Comment: concerning python-2.4.1.msi at win2000 sp4 After having spent quite some time at python.org to find out if I had to remove 2.4 before installing 2.4.1 (without any success, btw) I dared to start overinstalling. 1. Unfortunately, I didn't recognize that the suggested directory was different from where I wanted Python to stay in. Now, there seems to be no way back except completele un- and reinstalling: 2. I run the installer again and selected "change Python 2.4.1", then clicked "back", choosing the right directory, then went on to "next" and on, but my directory choice was ignored. 3. Finally, I run the installer at commandline, specifying TARGETDIR, chose the "change Python 2.4.1" radiobutton ... and again, Python was reinstalled as if TARGETDIR wasn't given. Paths containing spaces are not involved. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-05-30 10:32 Message: Logged In: YES user_id=21627 1. Correct, this is indeed the case. However, this sounds like an operator error, not a bug in Python. 2. Correct. It never occurred to me that somebody would try to move the installation in a "modify" installation. I will fix this by disabling the "back" button. 3. Likewise, however, this is an operator error. You shouldn't be specifying TARGETDIR in the "modify" mode. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207466&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1201461 ] suspected cPickle memory leak
Bugs item #1201461, was opened at 2005-05-13 17:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201461&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.2 Status: Open Resolution: None Priority: 5 Submitted By: Alan (franz2) Assigned to: Nobody/Anonymous (nobody) Summary: suspected cPickle memory leak Initial Comment: I believe there is a memory leak in cPickle. I have a parallel code which uses array() and indices() from Numeric to massage data buffers before being sent and received by Pypar. Pypar subsequently uses cPickle to pickle the data. After many hours of execution, my code crashes with one of the following error messages (depending upon the run): a = zeros(shape, typecode, savespace) MemoryError: can't allocate memory for array or: s = dumps(x, 1) MemoryError: out of memory I have since modified my code to use a different data format so cPickle is no longer used from PyPar and now the code runs fine. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-05-30 10:34 Message: Logged In: YES user_id=21627 Can you provide a test case that demonstrates how the memory is exhausted? Without a test case, it is unlikely that we will be able to find the suspected leak. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201461&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-1208730 ] expat binding for XML_ParserReset
Feature Requests item #1208730, was opened at 2005-05-25 22:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: expat binding for XML_ParserReset Initial Comment: XML_ParserReset is an expat parser method for resetting the parser to handle a new document. This keeps you from having to create a new parser for each document. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-05-30 10:37 Message: Logged In: YES user_id=21627 Would you like to work on a patch for this feature? Exposing more methods from Expat is a good idea. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&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-1193610 ] Expat Parser to supply document locator in incremental parse
Feature Requests item #1193610, was opened at 2005-05-02 08:12 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1193610&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: XML Group: None Status: Open Resolution: None >Priority: 6 Submitted By: GaryD (gazzadee) >Assigned to: Martin v. Löwis (loewis) Summary: Expat Parser to supply document locator in incremental parse Initial Comment: The standard Expat SAX Parser supplied with Python (xml.sax.expatreader.ExpatParser) does not set the document locator (using ContentHandler.setDocumentLocator) when you are doing an incremental parse (ie. using feed instead of parse), although it does supply the locator when you do a full parse. Is there a reason why this is so, or is it just an oversight? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1193610&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1071094 ] some latex reject the pdfinfo macro while generating html
Bugs item #1071094, was opened at 2004-11-22 17:15
Message generated for change (Comment added) made by stroeder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc-Antoine Parent (maparent)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: some latex reject the pdfinfo macro while generating html
Initial Comment:
I was building the documentation on OSX. I use the latest LaTeX
2004 from Wierda's teTeX. There is a pdfinfo command in Doc/
texinputs/manual.cls and Doc/texinputs/howto.cls which chokes my
version of latex.
edited log follows:
TEXINPUTS=/.../Python-2.4c1/Doc/commontex: python /.../Python
-2.4c1/Doc/tools/mkhowto --html --about html/stdabout.dat --
iconserver ../icons --favicon ../icons/pyfav.png --address "See
About this document... for
information on suggesting changes." --up-link ../index.html --up-
title "Python Documentation Index" --global-module-index "../
modindex.html" --dvips-safe --dir html/api api/api.tex
+++ TEXINPUTS=/.../Python-2.4c1/
Doc/api:/.../Python-2.4c1/Doc/
commontex:/.../Python-2.4c1/Doc/
paper-letter:/.../Python-2.4c1/Doc/
texinputs:
+++ latex api
*** Session transcript and error messages are in /.../Python
-2.4c1/Doc/html/api/api.how.
*** Exited with status 1.
The relevant lines from the transcript are:
+++ latex api
This is pdfeTeX, Version 3.141592-1.20a-2.2 (Web2C 7.5.3)
output format initialized to DVI
entering extended mode
(/.../Python-2.4c1/Doc/api/api.tex
LaTeX2e <2003/12/01>
Babel and hyphenation patterns for american, french,
german, ngerman, nohyphenation, loaded.
(/.../Python-2.4c1/Doc/texinputs/manual.cls
Document Class: manual 1998/03/03 Document class (Python
manual)
(/.../Python-2.4c1/Doc/texinputs/pypaper.sty
(/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/times.sty)
Using Times instead of Computer Modern.
) (/usr/local/teTeX/share/texmf.tetex/tex/latex/fancybox/
fancybox.sty
Style option: `fancybox' v1.3 <2000/09/19> (tvz)
) (/usr/local/teTeX/share/texmf.tetex/tex/latex/base/report.cls
Document Class: report 2004/02/16 v1.4f Standard LaTeX
document class
(/usr/local/teTeX/share/texmf.tetex/tex/latex/base/size10.clo))
(/.../Python-2.4c1/Doc/texinputs/fancyhdr.sty)
Using fancier footers than usual.
(/.../Python-2.4c1/Doc/texinputs/fncychap.sty)
Using fancy chapter headings.
(/.../Python-2.4c1/Doc/texinputs/python.sty
(/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/longtable.sty)
(/usr/local/teTeX/share/texmf.tetex/tex/latex/tools/verbatim.sty)
(/usr/local/teTeX/share/texmf.tetex/tex/latex/base/alltt.sty)))
(/.../Python-2.4c1/Doc/commontex/boilerplate.tex
(/.../Python-2.4c1/Doc/commontex/patchlevel.tex))
Writing index file api.idx
No file api.aux.
(/usr/local/teTeX/share/texmf.tetex/tex/latex/psnfss/ot1ptm.fd)
pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
{ \def \{, } \pdfinfo
{ /Author ([EMAIL PROTECTED] ) /Title ([EMAIL
PROTECTED] ) } }
l.12 \maketitle
No pages of output.
Transcript written on api.log.
*** Session transcript and error messages are in /.../Python
-2.4c1/Doc/html/api/api.how.
*** Exited with status 1.
make: *** [html/api/api.html] Error 1
--
Comment By: Michael Ströder (stroeder)
Date: 2005-05-30 11:23
Message:
Logged In: YES
user_id=64920
This patch I got from a tex expert seems to fix it. It
should also be applied to howto.cls.
--- manual.cls.orig 2005-05-30 10:02:28.0 +0200
+++ manual.cls 2005-05-30 11:16:58.0 +0200
@@ -6,9 +6,17 @@
\ProvidesClass{manual}
[1998/03/03 Document class (Python manual)]
+\RequirePackage{ifpdf}
[EMAIL PROTECTED]
+ \ifpdf
+[EMAIL PROTECTED]
+ \else
+[EMAIL PROTECTED]
+ \fi
+}
+
\RequirePackage{pypaper}
\RequirePackage{fancybox}
-
% Change the options here to get a different set of basic
options, but only
% if you have to. Paper and font size should be adjusted
in pypaper.sty.
%
@@ -64,7 +72,7 @@
\let\footnotesize\small
\let\footnoterule\relax
[EMAIL PROTECTED]
-[EMAIL PROTECTED]
+[EMAIL PROTECTED]
% This \def is required to deal with multi-line
authors; it
% changes \ to ', ' (comma-space), making it pass
muster for
% generating document info in the PDF file.
--
Comment By: Michael Ströder (stroeder)
Date: 2005-05-17 23:09
Message:
Logged In: YES
user_id=64920
I also have this problem when trying to build python-ldap's
docs on SuSE Linux 9.3 which ships with tetex-3.0-13 and
te_late
[ python-Bugs-516232 ] Windows os.path.isdir bad if drive only
Bugs item #516232, was opened at 2002-02-11 19:50
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516232&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: Extension Modules
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Charles I. Fuller (cifuller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Windows os.path.isdir bad if drive only
Initial Comment:
It seems that most os functions recognize the Windows
drive letter without a directory as the current
directory on the drive, but os.path.isdir still
returns 0. If os.listdir('C:') returns data,
os.path.isdir('C:') should return 1 for consistency.
C:\folder_on_C>python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or
"license" for
more information.
>>> import os
>>> os.system('dir C:')
Volume in drive C has no label.
Volume Serial Number is E4C9-AD16
Directory of C:\folder_on_C
02/11/2002 05:29p .
02/11/2002 05:29p ..
02/11/2002 05:29p subA
02/11/2002 05:29p subB
0 File(s) 0 bytes
4 Dir(s) 22,126,567,424 bytes free
0
>>> os.listdir('C:')
['subA', 'subB']
>>> os.path.abspath('C:')
'C:\folder_on_C'
>>> os.path.isdir('C:')
0
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 15:00
Message:
Logged In: YES
user_id=752496
Deprecated. Reopen only if still happens in 2.3 or newer.
.Facundo
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-03-21 16:30
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Tim Peters (tim_one)
Date: 2002-02-12 19:33
Message:
Logged In: YES
user_id=31435
Well, the underlying Microsoft routines are themselves
inconsistent, and in undocumented ways. We make a mild
effort to hide their warts, but it's historical truth that
doing so introduces other bugs. The sad fact is that MS
stat() insists "C:" does not exist, but the MS
FindFirstFile happily accepts "C:". If you think *you* can
straigten this inherited mess out, happy to accept a patch
.
--
Comment By: Charles I. Fuller (cifuller)
Date: 2002-02-12 18:54
Message:
Logged In: YES
user_id=211047
Responding to Tim's followup...
In this case the 'C:' is not the root drive, it is the
current dir on that drive. I noticed that os.path.abspath
was updated between 2.0 and 2.2 to recognize the current
dir.
It's an inconsistency that tripped me up already.
>>> os.path.isdir('C:')
0
>>> os.path.isdir(os.path.abspath('C:'))
1
The listdir has been working with drive specs (recognizing
the current dir) for a while. The abspath code must be
handling the drive-only input as a special case. The isdir
function should do the same for consistency.
There should at least be a warning in the docs...
--
Comment By: Tim Peters (tim_one)
Date: 2002-02-11 20:16
Message:
Logged In: YES
user_id=31435
Sorry, this is how Microsoft's implementation of the
underlying stat() function works. "Root drive" paths must
be given with a trailing slash or backslash, else MS stat()
claims they don't exist. You'll see the same irritating
behavior in C code. Attempts to worm around it in the past
have introduced other bugs; see bug 513572 for a current
example.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516232&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-549081 ] test_signal hangs -- signal broken on OpenBSD?
Bugs item #549081, was opened at 2002-04-26 10:54 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&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: Installation Group: Python 2.2.1 candidate >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: test_signal hangs -- signal broken on OpenBSD? Initial Comment: This appears to be similar to bug as PR#288, [ 210635 ] test_signal hangs when running as part of testall (PR#288) except that I have this problem on a fresh install of OpenBSD 3.0 while trying to build Python-2.2.1. I did a generic build running as root: ./configure ./make ./make test Yours, Noah -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:03 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 19:02 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Frallan the master Jedi (frallan) Date: 2003-12-11 09:14 Message: Logged In: YES user_id=639616 My test program now works. It both terminates and prints the 'got signal' message. Current Platform is: OpenBSD somewhere 3.3 GENERIC#44 i386 Python 2.3.2 (#1, Dec 1 2003, 11:20:01) [GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3 I should receive my OpenBSD 3.4 CDs soon. Then I'll test that too. -- Comment By: Michael Hudson (mwh) Date: 2002-10-31 07:49 Message: Logged In: YES user_id=6656 As far as I am aware (not very) Python signals have always been broken on OpenBSD. None of the Python core developers use OpenBSD, though, so it's always remained a mystery. frallan, does the C equivalent of your Python test work? Do you have any idea what Python (or OpenBSD, maybe) is doing wrong? signals are pain. -- Comment By: Frallan the master Jedi (frallan) Date: 2002-10-31 06:48 Message: Logged In: YES user_id=639616 I get the exact same behavior on OpenBSD 3.1 with Python- 2.2.2. Also this simple test program from the "Python Standard Library" book - fails. The program terminates but the "got signal" message is never printed. import signal import time def handler (signo, frame): print 'got signal', signo signal.signal(signal.SIGALRM, handler) # wake me up in two seconds signal.alarm(2) now = time.time() time.sleep(200) print 'slept for', time.time() - now, "seconds" -- Comment By: Noah Spurrier (noah) Date: 2002-04-27 12:40 Message: Logged In: YES user_id=59261 Below is the output of test_signal.py. I ran it manually. I modified it slightly to print out the pid; the return values from the signal calls; and to print a count of the loop iteration (starting at 1). You can see that after Count 4 it just sits there. After about a minute I hit Ctrl- Z. I have uploaded the modified version of test_signal.py. ... bash-2.05# python test_signal.py pid: 8606 signal.alarm(20): 0 signal.signal(5, handlerA): 0 signal.signal(2, handlerB):signal.signal(3, signal.SIG_IGN): 0 signal.signal(signal.SIGALRM, signal.default_int_handler): 0 starting pause() loop... + sleep 2 count: 1 call pause()... + kill -5 8606 pause() returned + sleep 2 count: 2 call pause()... + kill -2 8606 pause() returned + sleep 2 count: 3 call pause()... + kill -3 8606 pause() returned count: 4 call pause()... ^Z [1]+ Stopped python test_signal.py bash-2.05# ps -p 8606 PID TT STAT TIME COMMAND 8606 p0 T 0:00.09 python test_signal.py bash-2.05# uname -a OpenBSD nobot 3.0 GENERIC#94 i386 bash-2.05# python Python 2.2.1 (#4, Apr 26 2002, 23:06:40) [GCC 2.95.3 20010125 (prerelease)] on openbsd3 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python
[ python-Bugs-768649 ] popen4 doesn't close filedescriptors when in Threads
Bugs item #768649, was opened at 2003-07-09 15:36
Message generated for change (Settings changed) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768649&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.2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: martin doudoroff (mdoudoroff)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen4 doesn't close filedescriptors when in Threads
Initial Comment:
Running the following code under Linux will result in a
crash on the 508th thread started. The error is
OSError: [Errno 24] Too many open files
The nature of the bug seems to be that Python isn't
closing filedescriptors cleanly when running a thread.
---
import os
from threading import Thread
class Crash(Thread):
def run(self):
a = os.popen4('ls')
b = a[1].read()
# uncommenting these lines fixes the problem
# but this isn't really documented as far as
# we can tell...
# a[0].close()
# a[1].close()
for i in range(1000):
t = Crash()
t.start()
while t.isAlive():
pass
print i
---
The same code without threads (Crash as a plain class)
doesn't crash, so the descriptor must be getting taken
care of when the run() method is exited.
import os
class Crash:
def run(self):
a = os.popen4('ls')
b = a[1].read()
for i in range(1000):
t = Crash()
t.run()
print i
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 17:48
Message:
Logged In: YES
user_id=752496
Works fine to me:
Python 2.3.4 (#1, Oct 26 2004, 16:42:40)
[GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
with glibc-2.3.4-2
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 17:48
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Andrew Gaul (gaul)
Date: 2003-10-01 15:51
Message:
Logged In: YES
user_id=139865
Duplicated with Python 2.3 on Red Hat 7.3 using
glibc-2.2.5-43. Popen3.{poll,wait} are written under the
incorrect assumption that waitpid can monitor any process in
the same process group, when it only works for immediate
children. _active.remove is never called, so Popen3 objects
are never destroyed and the associated file descriptors are
not returned to the operating system.
A general solution for Popen[34] is not obvious to me. With
patch #816059, popen2.popen[234] plugs the _active leak,
which in turn returns the file descriptors to the operating
system when the file objects that popen2.popen[234] return
go out of scope.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-07-10 00:20
Message:
Logged In: YES
user_id=33168
I can't duplicate this on Redhat 9. What OS, what version
of glibc and what kernel are you using? Does it always
crash on the 508th iteration?
I tested with both 2.2.3 and 2.3b2 from CVS without
problems. I even used ulimit to set my open files to 10.
Can you try the patch in bug #761888 to see if that helps?
http://pythong.org/sf/761888
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768649&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-763190 ] Sudden death with SIGSEGV in RtlEnterCriticalSection
Bugs item #763190, was opened at 2003-06-30 10:34 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763190&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: Threads Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Maria Martinsdotter (dehex) Assigned to: Nobody/Anonymous (nobody) Summary: Sudden death with SIGSEGV in RtlEnterCriticalSection Initial Comment: Environment: Python 2.2.2 win32all-150 Win2000 Server Dell server 2 CPU Pentuim 4 emulating 4 CPU's. Application: Service with many (50-150) threads. Problem: The entire service exits unexepectedly with only a brief reference made by Dr.Watson indicating the Windows equivalent of SIGSEGV in RtlEnterCriticalSection. Side info: Known to have happened once, we believe it may have happened three times in total but the two extra did not leave even a Dr.Watson trace. The known occurrence can be connected to our use of a timer where the action routine restarts the timer. The two extra's occurred at a point in time that connect the problem event to the timer expiration. The application have been used for five months, runnning around the clock. The customer installation currently use five instances of the base software, only configuration differs. It is arbitrary which instance fail. We have no means to trigger the problem. -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:27 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:40 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Maria Martinsdotter (dehex) Date: 2003-06-30 19:00 Message: Logged In: YES user_id=807857 Apart from what we initially reported, no extensions are used. It is all pure Python and the only part of win32all used is the support for running it as a service. We are aware of the enhancements provided by 2.3 beta but let it suffice to say that the customer is picky. We have not been able to reproduce the problem in our test environment, however the hardware is not as sophisticated. -- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 12:13 Message: Logged In: YES user_id=33168 Are there any other C/Extension modules used which are not from the standard python distribution? Can you make a self contained test case? I encourage you to test with 2.3 beta 2. There were some thread changes which could affect this problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763190&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-756940 ] can't CNTRL-C when running os.system in a thread
Bugs item #756940, was opened at 2003-06-18 20:52 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756940&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: Threads Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Greg Jones (morngnstar) Assigned to: Nobody/Anonymous (nobody) Summary: can't CNTRL-C when running os.system in a thread Initial Comment: This is related to Bug #756924. When os.system is called in a thread, Control-C is ignored. Steps to reproduce: 1. Download the attached file fibonacci.py. 2. Run python2.2 fibonacci.py. 3. Hit CNTRL-C. fibonacci.py starts a thread that executes fibonacci.py again (but with a flag to prevent this from recursing infinitely). Then it computes and prints the Fibonacci sequence, the slow way. The process executed in the thread redirects this to a file to avoid conflict over stdout. All this is just to give the program something to do while you hit CNTRL-C. Expected, and Python 2.1 behavior: You get a KeyboardInterrupt exception, a stack trace, and the program exits. Actual Python 2.2 behavior: No response. You have to run kill on the process. Maybe this is not a bug, but rather a limitation of Linux, since I understand SIGINT is blocked during the C function 'system'. However, CNTRL-C worked in Python 2.1, and that was nicer. Removing the lines of code described in Bug #756924 also fix this bug. -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:30 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:23 Message: Logged In: YES user_id=752496 The other bug have a very long discussion about this, and talks about patches to be applied to Py2.4, and the last patch is actually accepted. Maybe this is already fixed, please give it a try. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 16:23 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Greg Jones (morngnstar) Date: 2003-06-18 23:58 Message: Logged In: YES user_id=554883 OS is Linux. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756940&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs
Bugs item #737202, was opened at 2003-05-13 14:54
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&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
Submitted By: Hartmut Goebel (htgoebel)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer does not handle scripts in sub-dirs
Initial Comment:
CGIHTTPServer does not handle scripts in sub directoreis correctly:
When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns
404 CGI script is not a plain file ('/cgi-bin/script')
This tracked down to CGIHTTPRequestHandler.run_cgi() containing
these lines:
i = rest.find('/')
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
scriptname = dir + '/' + script
This will move the dir-part of the 'rest' into 'script', but leave the
actual filename in 'rest'. The 'scriptname' thus does miss the filename.
I assume this should become simply:
script, rest = rest, ''
scriptname = dir + '/' + script
--
>Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 15:51
Message:
Logged In: YES
user_id=752496
The example shows the problem in Py2.4.1.
--
Comment By: Titus Brown (titus)
Date: 2005-01-17 02:31
Message:
Logged In: YES
user_id=23486
Verified proper behavior does not work in 2.2, 2.3, 2.4, or current CVS.
The attached patches are just a filename; you should try downloading
them to be sure they're actually a patch ;).
A simpe self-contained example is at
http://issola.caltech.edu/~t/transfer/python-bug737202-example.tgz
it works under Python 2.2 or greater & demonstrates the problem.
A patch for the current CVS HEAD is at
http://issola.caltech.edu/~t/transfer/python-bug737202-patch.diff
and 2.4 should probably be back-patched as well.
--
Comment By: Hartmut Goebel (htgoebel)
Date: 2005-01-16 12:11
Message:
Logged In: YES
user_id=376953
Encloded please find a testcase.
I've checkt it with 2.3.3.
Buf should still persist in 2.3.4 and 2.4. I've checked the
CVS diffs and there is no change which would solve it.
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 15:42
Message:
Logged In: YES
user_id=752496
Both bugs are for the same problem, keeping this alive
(because it has the patch), closing the other as Duplicate.
Regarding the patch, the actual code has something very
similar to it, so maybe the bug is already fixed...
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 15:42
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Titus Brown (titus)
Date: 2004-12-19 03:20
Message:
Logged In: YES
user_id=23486
same as bug 778804, assigned to esr.
--
Comment By: Hartmut Goebel (htgoebel)
Date: 2003-05-23 10:21
Message:
Logged In: YES
user_id=376953
I rethought this: The reason for this type of split is to make it possible to
pass parameters as part of the URL, like Zope does.
So the snippet above should be changed to something like this:
i = 0
while 1:
# get the next path-element out of the url
i = rest.find('/', i)
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
scriptname = dir + '/' + script
scriptfile = self.translatepath(scriptname)
if os.isdir(scriptname):
# if scriptname is a directory, continue "walking" the url
continue
# scriptname is not a directory, stop "walking" the url
break
Patch is included.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-730222 ] socketmodule.c: inet_pton() expects 4-byte packed_addr
Bugs item #730222, was opened at 2003-04-30 12:00 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&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.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: John Marshall (john_marshall) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c: inet_pton() expects 4-byte packed_addr Initial Comment: In the Modules/socketmodule.c file, the inet_pton function implicitly treats "long packed_addr" as a 4-byte object or expects that the required 4-bytes is at &packed_addr[0]-[3]. This is not true under SUPER-UX/SX. In order to get this working right, I changed the data type from "long" to "int". This now works properly. -Modules/socketmodule.c: #3825 /* 042303; JM; this routine really expects a 4-byte packed_addr * not a long; long on SX is 8-bytes! */ #if SX int packed_addr; #else long packed_addr; #endif ... if (packed_addr == INADDR_NONE) return 0; memcpy(dst, &packed_addr, 4); - -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:57 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: John Marshall (john_marshall) Date: 2005-01-17 12:52 Message: Logged In: YES user_id=768577 I no longer have access to SUPER-UX/SX systems, but the problem must still exist since nothing has changed in the source (I just checked that "long packed_addr" is still used -- SUPER-UX/SX systems support 8-byte longs). The more general patch supplied by nnorwitz should do the trick, though. Thanks, John -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:04 Message: Logged In: YES user_id=752496 This patch is no applied, the bug persists? -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 15:04 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 00:32 Message: Logged In: YES user_id=33168 Attached is a patch which should fix the problem. There was one other place that needed to be changed. This change is more generic. Let me know if it works for you. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730222&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix
Bugs item #728515, was opened at 2003-04-27 14:44 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&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: Extension Modules Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:59 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 09:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-727241 ] Core Dumps : Python2.2.2
Bugs item #727241, was opened at 2003-04-24 19:16
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=727241&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 2.2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Eli Rosenberg (elirosenberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core Dumps : Python2.2.2
Initial Comment:
Hello,
I am able to cause python to core dump on IRIX
6.5.18 and above with the code listed below. I have
compiled with 3 versions of gcc as well as MIPSpro.
Running this code with a valid host and a port
that will cause a connection refused socket error
produces a core dump with the the stack trace below.
>>> import socket
>>> x=socket.socket()
>>> x.connect(('www.google.com', 1234))
> 0 realfree(0x10162e98, 0x0, 0x20, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
1 cleanfree(0x0, 0x0, 0x20, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
2 __malloc(0x28, 0x0, 0x20, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
3 _malloc(0x28, 0x0, 0x20, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x10092368]
6 newtracebackobject(next = (nil), frame =
0x1016b670, lasti = 21, lineno = 1)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":115,
0x100c6684]
7 PyTraceBack_Here(frame = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/traceback.c":133,
0x100c67f4]
8 eval_frame(f = 0x1016b670)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2238,
0x1004e894]
9 PyEval_EvalCodeEx(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0, args = (nil), argcount
= 0, kws = (nil), kwcount = 0, defs = (nil), defcount =
0, closure = (nil))
["/usr/people/eli/Python-2.2.2/Python/ceval.c":2595,
0x1004ffe0
10 PyEval_EvalCode(co = 0x1016e990, globals =
0x1016a5d0, locals = 0x1016a5d0)
["/usr/people/eli/Python-2.2.2/Python/ceval.c":481,
0x10047ea0]
11 run_node(n = 0x101a5b28, filename = 0x1014e978 =
"", globals = 0x1016a5d0, locals = 0x1016a5d0,
flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":1079,
0x1006f380]
12 PyRun_InteractiveOneFlags(fp = 0xfb53680,
filename = 0x1014e978 = "", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":590,
0x1006d57c]
13 PyRun_InteractiveLoopFlags(fp = 0xfb53680,
filename = 0x1014e978 = "", flags = 0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":526,
0x1006d198]
14 PyRun_AnyFileExFlags(fp = 0xfb53680, filename =
0x1014e978 = "", closeit = 0, flags =
0x7fff2e2c)
["/usr/people/eli/Python-2.2.2/Python/pythonrun.c":489,
0x1006cf48]
15 Py_Main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/main.c":364,
0x1000fa44]
16 main(argc = 1, argv = 0x7fff2f24)
["/usr/people/eli/Python-2.2.2/Modules/python.c":10,
0x1000ecdc]
17 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177,
0x1000ec78]
I compiled Python 64-bit and the code above appears
not to cause a segfault but the code below will
bus error after a few iterations.
import socket
import time
def doit():
s = socket.socket()
start = time.time()
try:
s.connect(('www.cnn.com', 80))
except socket.error,e:
print repr(e),str(e)
finish = time.time()
time.sleep(.5)
print str(finish-start),"\n"
s.close()
for x in xrange(10):
doit()
Here is the stack trace:
> 0 realfree(0x10162e98, 0x0, 0x20, 0x65637469,
0x17dd4, 0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":527,
0xfb245fc]
1 cleanfree(0x0, 0x0, 0x20, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":945,
0xfb24e44]
2 __malloc(0x28, 0x0, 0x20, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":230,
0xfb24078]
3 _malloc(0x28, 0x0, 0x20, 0x65637469, 0x17dd4,
0x1, 0x1, 0x8)
["/xlv47/6.5.18f/work/irix/lib/libc/libc_n32_M4/gen/malloc.c":186,
0xfb23ee4]
4 _PyObject_GC_Malloc(tp = 0x1013fbe0, nitems = 0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":868,
0x10092244]
5 _PyObject_GC_New(tp = 0x1013fbe0)
["/usr/people/eli/Python-2.2.2/Modules/gcmodule.c":895,
0x100923
[ python-Bugs-718532 ] inspect, class instances and __getattr__
Bugs item #718532, was opened at 2003-04-09 17:01 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&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 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Raymond Hettinger (rhettinger) Summary: inspect, class instances and __getattr__ Initial Comment: inspect.isclass(class_instance) fails if the corresponding class uses a "wildcard" implementation of __getattr__. Example: Python 2.2.2 (#1, Nov 13 2002, 22:53:57) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> class X: ... def __getattr__(self, name): ... if name == 'foo': ... return 1 ... if name == 'bar': ... return 2 ... else: ... return "default" ... >>> x = X() >>> inspect.isclass(x) 1 The problematic expression in inspect.isclass is hasattr(object, '__bases__') which returns a true value. -- >Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:15 Message: Logged In: YES user_id=752496 Don't know yet if it's a bug or not, but in Py2.4.1 inspect.isclass() is still returning True in these cases... -- Comment By: Stefan Schwarzer (sschwarzer) Date: 2005-01-28 13:44 Message: Logged In: YES user_id=383516 Hi Facundo The problem still exists in both Python 2.3.4 and 2.4. A possible test case is: import inspect import unittest class TestIsclass(unittest.TestCase): def test_instance_with_getattr(self): class Cls: def __getattr__(self, name): return "not important" obj = Cls() # obj is not a class self.failIf(inspect.isclass(obj)) -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:50 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-15 07:40 Message: Logged In: YES user_id=80475 Ping, if this change is made, will isclass() still be able to find extension classes? The addition of the hasattr(object, '__bases__') was made by you in ver 1.11 about two years ago. -- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 07:01 Message: Logged In: YES user_id=89016 type(object) in (types.TypeType, types.ClassType) won't work with custom metaclasses. isinstance(object, (type, types.ClassType)) would be better. -- Comment By: Stefan Schwarzer (sschwarzer) Date: 2003-04-15 05:01 Message: Logged In: YES user_id=383516 Hello Raymond, thanks for your reply. In fact, I'm also not sure if it counts as a bug. I also suggested a patch (handle __getattr__ requests for __bases__ with an AttributeError) for for the SF project which causes/d the problem. I think, if there's a better way to decide on "class-ness" than now, the code in inspect should be changed. Fortunately, it doesn't have to be backward-compatible, because the module is always distributed with a certain interpreter version. -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-14 21:36 Message: Logged In: YES user_id=80475 Hmm. I'm not sure that counts as a bug. In an OO language, it's a feature that objects can be made to look like and be substituable for other types. In this case, you've taught your object to be able to fake some classlike behavior (having a __bases__ attribute). OTOH, inspect could have a stronger test for classhood: type(object) in (types.TypeType, types.ClassType) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-716634 ] " build_ext" " libraries" subcommand not s
Bugs item #716634, was opened at 2003-04-07 06:13 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716634&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: Distutils Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: "build_ext" "libraries" subcommand not s Initial Comment: The "libraries" command for "build_ext" is definitely one that should accept multiple libraries. However, this is impossible for both the command line as well as the configuration file. Patch attached. -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:17 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716634&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-701836 ] Thread running (os.system or popen#)
Bugs item #701836, was opened at 2003-03-11 18:46
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&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.2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Johan Fredrik Öhman (johanfo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread running (os.system or popen#)
Initial Comment:
Bottom line: Some programs may lock up when
spawned from a thread.
>>> import thread, os
>>> thread.start_new_thread(os.system,
("/usr/sbin/ntpdate ifi.uio.no",))
This starts a program "ntpdate" from a Python thread.
Usually this is no problem. Ntpdate, is a simple program
to adjust the clock of the system. However, when
ntpdate is started from a thread it locks up and newer
exits!! With my limited debugging knowledge, it sems
as it hangs in a "poll()" kernel call, however, this could
be misleading. (I used stacktrace -p )
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 16:29
Message:
Logged In: YES
user_id=752496
Deprecated. Reopen only if still happens in 2.3 or newer.
.Facundo
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 17:34
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 17:34
Message:
Logged In: YES
user_id=752496
Works ok for me:
Python 2.3.4 (#1, Oct 26 2004, 16:42:40)
[GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import thread, os
>>> thread.start_new_thread(os.system,("/usr/sbin/ntpdate
ifi.uio.no",))
-1210684496
>>>
--
Comment By: Johan Fredrik Öhman (johanfo)
Date: 2003-03-12 13:12
Message:
Logged In: YES
user_id=556425
I have verified this bug on both Redhat 8.0 and SuSE 8.1,
linux yes.
Signal is one possible path, filedescriptors another. I read
somwhere that there was some issues with pthreads forking
and filedescriptors. However, this is not my area (too low
level)
--
Comment By: Michael Hudson (mwh)
Date: 2003-03-12 09:40
Message:
Logged In: YES
user_id=6656
IIRC, threads other than the main thread get a signal mask
that blocks everything. That could be the problem, but I
don't know what to do about it...
What platform are you on? Linux?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-700650 ] Canvas origin is off-canvas in create_< item> (). Worka
Bugs item #700650, was opened at 2003-03-10 02:17 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700650&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: Tkinter Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Canvas origin is off-canvas in create_- (). Worka Initial Comment: The origin for x,y pairs sent to the Canvas items is off-screen by the sum of borderwidth bd and highlightthickness hT. The accompanying program shows this and includes three functions which can be used in workarounds. I just hope the upload facility works this time. A canvas with exaggerated values for bd and hT is shown to illustrate the problem. On it, a full-screen open rectangle ((0-to width-1) by 0-to-(height-1)) is shown in red, and it is partly off-screen. A blue rectangle of the same coordinates is sent through UsrToCnv(), which uses .cget() to fetch up-to-date values for bd and hT (which can of course be updated on the fly) and translates the user's canvas item back where it belongs. Clicking on the canvas illustrates the use of CnvToUsr, sending a tuple (event.x, event.y) through the reverse of the above translation so that it matches the user's expectations. If these functions or their equivalents are not already available, you have my permission to offer these as workarounds while someone investigates the problem. I recommend that similar trials be performed on Tcl/Tk or PERL/Tk to see if the problem lies in Tkinter or even deeper in the mass of code. I'm a Python beginner so can't help with a project to fix it, but I'd like to be kept informed of any progress or decisions, if that's not too much trouble. Roy Keir -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:31 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 There's no file attached... -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700650&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-699816 ] Canvas Widget origin is off-screen
Bugs item #699816, was opened at 2003-03-08 03:21 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699816&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: Tkinter Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Canvas Widget origin is off-screen Initial Comment: I'm a Python newbie, so be patient. I noticed that create-- didn't place the item where I expected. My [EMAIL PROTECTED] guru Matt Cowles suggested that highlightthickness (hT hereinafter) might be the culprit. I wasn't using hT, but I was using borderwidth (bd to all), and I eventually found the problem. I believe that it is an error in Tkinter, but I'll be happy to be corrected. I wrote a program to display the canvases with the four combinations of hT and bd, and later I doubled up to see if 'relief' with bd==0 had any effect. I'll try to upload the code (oops. It invoves two modules. I may have to send two messages, one with each module). Here is what I think happens, and what I think should happen : DOES: SHOULD: Tkinter finds screen coordinates cx, cy of Canvas same (crucial step omitted) tx, ty = cx, cy Tkinter translatescx, cy = cx - bd, cy -bd tx, ty = tx- bd, ty - bd Tkinter draws the border (width is 2*bd wider than the Canvas)draws the border Tkinter translatescx, cy = cx - hT, cy - hT tx, ty = tx - hT, ty - hT Tkinter draws the highlight box (width is 2*hT wider than the border)draws the hightlight box Tkinter delivers cx, cy as the origin of the Canvas delivers cx, cy as the origin The attached program, if it arrives, demonstrates this effect. Any one doing serious graphics will need to adjust the x,y values of every Canvas item they draw. Putting a wrapper around each to .get() the values of hT and bd (and others I haven't discovered yet ?) is feasible but awful. Putting a function at the top of each event callback function to correct the event object x and y is even more awkward. To preserve backwards compatibility, I suggest that Tkinter Canvas items all be given an extra set of x and y values, with distinctive names. The user can put any old values in the current x,y positional spots and use xcorrected = NN, ycorrected=NN to override the stuff in the positional spots. To handle the variable number of x,y pairs in create_polygon(), create_line(), and perhaps other, Tkinter might require that the new values be given in a tuple of pairs or two tuples (x0,x1,x2) & (y0,y1,y2) The attached file is TkCoords03.py The next error will include algGrid03.py. Hope you can get them together. Roy Keir newbieroy [EMAIL PROTECTED] -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:32 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:46 Message: Logged In: YES user_id=752496 There's no file attached... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699816&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-687747 ] _iscommand() in webbrowser module
Bugs item #687747, was opened at 2003-02-17 01:17
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: _iscommand() in webbrowser module
Initial Comment:
[From a post to python-help]
Under KDE under Mandrake Linux the BROWSER environment
variable is set to
kfmclient openProfile webbrowsing
The problem is that _iscommand() in the webbrowser
module doesn't realize that only the first thing there
is the name of the executable. It looks for an
executable with that whole thing as its name and
doesn't find one. Since the module doesn't use any
browser it has found if BROWSER is set, it raises an
error rather than opening the page.
The possible fixes that are obvious to me all have
potential disadvantages:
One solution would be to assume that the name of the
executable ran only up to the first space. But
executables can have spaces in their names, especially
on a Macintosh, I think.
Another possibility would be not to call _iscommand()
on anything in BROWSER. That would have the additional
advantage of not requiring that the executable
specified there be in a directory that's in the user's
PATH. The problem with doing things this way is that it
would be impossible to tell which of the browsers
specified in BROWSER should be used until the user
called open().
I'm prepared to work on a fix if given some guidance
about the best way to go.
--
>Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 16:37
Message:
Logged In: YES
user_id=752496
richard seems to reproduced it on Py2.3, changing the group
to it.
--
Comment By: Richard Jones (richard)
Date: 2005-01-16 19:01
Message:
Logged In: YES
user_id=6405
This is still an issue.
python -c 'import
webbrowser;webbrowser.open("http://www.google.com/";)'
on a system using KDE will exhibit the break.
I posted a patch to fix the behaviour in my last message. I just
noticed that I invoked diff the wrong way around (though the
explanation still stands) - a correct invocation:
--- /tmp/webbrowser.py 2005-01-17 08:59:50.697657208
+1100
+++ /usr/lib/python2.3/webbrowser.py2005-01-17
08:59:58.269989095 +1100
@@ -354,7 +354,7 @@
if "BROWSER" in os.environ:
# It's the user's responsibility to register handlers for any
unknown
# browser referenced by this value, before calling open().
-_tryorder = os.environ["BROWSER"].split(os.pathsep)
+_tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep)
for cmd in _tryorder:
if not cmd.lower() in _browsers:
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 09:26
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Richard Jones (richard)
Date: 2003-08-19 21:29
Message:
Logged In: YES
user_id=6405
This is still an issue... has there been any movement on it outside of this
bug report?
I'm seeing the behaviour on Mandrake 9.1, KDE 3.1.3 that the module is
finding the BROWSER env var as described above, and thus not finding a
usable browser.
As a fallback, the _tryorder shouldn't be *replaced* by BROWSER, but
just prepended with its value. Sure, that means that the KDE BROWSER
value will be ignored, but it'll still find konqueror. This approach works for
me, and I'm sure it'll work for others who have "valid" BROWSER
values
:)
Simple patch against python2.3 (sorry, sf will mangle this, but it's short):
--- webbrowser.py 2003-08-20 10:28:07.0 +1000
+++ /usr/lib/python2.3/webbrowser.py2003-08-04
10:18:17.0 +1000
@@ -354,7 +354,7 @@
if "BROWSER" in os.environ:
# It's the user's responsibility to register handlers for any unknown
# browser referenced by this value, before calling open().
-_tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep)
+_tryorder = os.environ["BROWSER"].split(os.pathsep)
for cmd in _tryorder:
if not cmd.lower() in _browsers:
--
Comment By: Guido van Rossum
[ python-Bugs-687297 ] Profilier hooked into SystemExit
Bugs item #687297, was opened at 2003-02-15 22:41 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687297&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: Demos and Tools Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Dylan Shell (dshell) Assigned to: Nobody/Anonymous (nobody) Summary: Profilier hooked into SystemExit Initial Comment: I've been attempting to profile code that uses the PyOpenGL bindings. Essentially I've got a program with that calls glutMainLoop - which is said to never return. The problem is that since this really envokes some C code that calls "exit" the profiler does not catch a "SystemExit" exception, because this is never thrown. If there was a way to get the profiler to dump state on demand, I could do this in an "onExit" event handler, and then restart python with the pstats module to have a look-see. Alternatively the profiler could use some OS provided exit handler - or something simliar. Also, running the main loop in a thread does not seem to work (the video memory used by GLUT) is corrupted. So, this isn't a fair test on which to profile. I suspect that the ability to dump profile stats to disk could also be useful for other folks. -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 16:47 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 01:08 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687297&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-676346 ] String formatting operation Unicode problem.
Bugs item #676346, was opened at 2003-01-28 17:59
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676346&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: Unicode
Group: Python 2.2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: David M. Grimes (dmgrime)
Assigned to: M.-A. Lemburg (lemburg)
Summary: String formatting operation Unicode problem.
Initial Comment:
When performing a string formatting operation using %s
and a unicode argument, the argument evaluation is
performed more than once. In certain environments (see
example) this leads to excessive calls.
It seems Python-2.2.2:Objects/stringobject.c:3394 is
where PyObject_GetItem is used (for dictionary-like
formatting args). Later, at :3509, there is a"goto
unicode" when a string argument is actually unicode.
At this point, everything resets and we do it all over
again in PyUnicode_Format.
There is an underlying assumption that the cost of the
call to PyObject_GetItem is very low (since we're going
to do them all again for unicode). We've got a
Python-based templating system which uses a very simple
Mix-In class to facilitate flexible page generation.
At the core is a simple __getitem__ implementation
which maps calls to getattr():
class mixin:
def __getitem__(self, name):
print '%r::__getitem__(%s)' % (self, name)
hook = getattr(self, name)
if callable(hook):
return hook()
else:
return hook
Obviously, the print is diagnostic. So, this basic
mechanism allows one to write hierarchical templates
filling in content found in "%()s" escapes with
functions returning strings. It has worked extremely
well for us.
BUT, we recently did some XML-based work which
uncovered this strange unicode behaviour. Given the
following classes:
class w1u(mixin):
v1 = u'v1'
class w2u(mixin):
def v2(self):
return '%(v1)s' % w1u()
class w3u(mixin):
def v3(self):
return '%(v2)s' % w2u()
class w1(mixin):
v1 = 'v1'
class w2(mixin):
def v2(self):
return '%(v1)s' % w1()
class w3(mixin):
def v3(self):
return '%(v2)s' % w2()
And test case:
print 'All string:'
print '%(v3)s' % w3()
print
print 'Unicode injected at w1u:'
print '%(v3)s' % w3u()
print
As we can see, the only difference between the w{1,2,3}
and w{1,2,3}u classes is that w1u defines v1 as unicode
where w1 uses a "normal" string.
What we see is the string-based one shows 3 calls, as
expected:
All string:
<__main__.w3 instance at 0x8150524>::__getitem__(v3)
<__main__.w2 instance at 0x814effc>::__getitem__(v2)
<__main__.w1 instance at 0x814f024>::__getitem__(v1)
v1
But the unicode causes a tree-like recursion:
Unicode injected at w1u:
<__main__.w3u instance at 0x8150524>::__getitem__(v3)
<__main__.w2u instance at 0x814effc>::__getitem__(v2)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w2u instance at 0x814effc>::__getitem__(v2)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w3u instance at 0x8150524>::__getitem__(v3)
<__main__.w2u instance at 0x814effc>::__getitem__(v2)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w2u instance at 0x814effc>::__getitem__(v2)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
v1
I'm sure this isn't a "common" use of the string
formatting mechanism, but it seems that evaluating the
arguments multiple times could be a bad thing. It
certainly is for us 8^)
We're running this on a RedHat 7.3/8.0 setup, not that
it appears to matter (from looking in stringojbect.c).
Also appears to still be a problem in 2.3a1.
Any comments? Help? Questions?
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 16:55
Message:
Logged In: YES
user_id=752496
Deprecated. Reopen only if still happens in 2.3 or newer.
.Facundo
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-11 00:54
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-28 19:23
Message:
Logged In: YES
user_id=38
[ python-Bugs-666700 ] os.popen+() can take string list and bypass shell.
Bugs item #666700, was opened at 2003-01-12 13:45 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&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: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dani (asqui) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen+() can take string list and bypass shell. Initial Comment: After being somewhat dumbfounded by the fact that there is no easy way to securely give user input as parameters to an external utility (because of the fact that os.popen*() runs things in the shell), I was happy to find that (os | popen2).popen[234]() will accept either a string as the command and execute it within a shell, or a string list which is executed directly. This does not apply to os.popen(), however popen2.popen[234]() all use this piece of code to execute the command in the child process: /usr/lib/python2.2/popen2.py def _run_child(self, cmd): if isinstance(cmd, types.StringTypes): cmd = ['/bin/sh', '-c', cmd] for i in range(3, MAXFD): try: os.close(i) except: pass try: os.execvp(cmd[0], cmd) finally: os._exit(1) Meaning that unless cmd is a string it will be run directly, outside of any shell. This appears to be the case for os.popen[234]() as well as popen2.popen*() -- >Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 17:03 Message: Logged In: YES user_id=752496 Ok, fixed. -- Comment By: Jeremy Fincher (jemfinch) Date: 2005-01-11 13:56 Message: Logged In: YES user_id=99508 I think I misunderstood your question. Yes, this *is* already fixed in the documentation for the subprocess module in 2.4. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 12:19 Message: Logged In: YES user_id=752496 Jeremy, could you please provide a patch for the docs? Thanks! -- Comment By: Jeremy Fincher (jemfinch) Date: 2005-01-11 12:08 Message: Logged In: YES user_id=99508 Yes, I believe it should. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:34 Message: Logged In: YES user_id=752496 Should this be fixed in 2.4? Now we have the "subprocess" module. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:34 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-23 19:34 Message: Logged In: YES user_id=99508 Can I second that the documentation should definitely be updated to reflect this possibility, even if it's only available on *nix-like systems? This is something that many other languages in the same realm as Python (Perl, PHP, etc.) support and document, and I can't see any good reason why we *shouldn't* document a more secure way to give data to external programs. -- Comment By: Bernhard Herzog (bernhard) Date: 2003-08-05 13:04 Message: Logged In: YES user_id=2369 Given that the command as list of strings feature only works on Unix-like systems, ISTM it should perhaps only be documented for the PopenN classes. Maybe the documentation for the functions should state that on unix they accept lists of strings, though. -- Comment By: Dani (asqui) Date: 2003-01-12 13:49 Message: Logged In: YES user_id=569758 (The punch line which I omitted was that this fact is not documented anywhere.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-654783 ] doctest and exception messages
Bugs item #654783, was opened at 2002-12-16 16:23 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&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: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Aahz (aahz) Assigned to: Aahz (aahz) Summary: doctest and exception messages Initial Comment: doctest should include information something like this: doctest docstrings should not rely on the text of internal Python exceptions. Notice the way factorial() uses its own error messages with the standard Python exceptions. The internal messages can change even in bugfix releases (as in 2.2.1 to 2.2.2). -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 17:05 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:30 Message: Logged In: YES user_id=752496 What should change Aahz in the docs? Not clear to me... -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:30 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-23 19:01 Message: Logged In: YES user_id=3066 Tim sent this back to Aahz, so I'm assigning it to him as a reminder. ;-) -- Comment By: Tim Peters (tim_one) Date: 2003-04-25 16:08 Message: Logged In: YES user_id=31435 Back to Aahz. I don't mind if you change this -- edit the docs and check it in. -- Comment By: Tim Peters (tim_one) Date: 2002-12-16 20:39 Message: Logged In: YES user_id=31435 It could, but it shouldn't: error msgs in docs that don't match reality are also an insult to users. doctest should grow some sort of option here, though, as its uses outgrew its original purposes. -- Comment By: Neil Schemenauer (nascheme) Date: 2002-12-16 19:01 Message: Logged In: YES user_id=35752 Couldn't doctest be modified so that it only compares the exception name only? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-640553 ] Misuse of /usr/local/in setup.py
Bugs item #640553, was opened at 2002-11-19 05:04 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640553&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: Build Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nick Maclaren (nmm1) Assigned to: Nobody/Anonymous (nobody) Summary: Misuse of /usr/local/in setup.py Initial Comment: I cannot guarantee that this has not been reported before, as the search facility doesn't appear sufficiently powerful to determine that, and I do not have time to read a hundred bug reports. setup.py forces the use of /usr/local, which is wrong on more counts than I can describe. Not merely need it not exist, it could easily contain the wrong versions of libraries and headers. The following change should be reversed: *** setup.py.orgMon Nov 18 19:57:09 2002 --- setup.pyMon Nov 18 19:57:23 2002 *** *** 197,207 return platform def detect_modules(self): - # Ensure that /usr/local is always used - if '/usr/local/lib' not in self.compiler.library_dirs: - self.compiler.library_dirs.insert(0, '/usr/local/lib') - if '/usr/local/include' not in self.compiler.include_dirs: - self.compiler.include_dirs.insert(0, '/usr/local/include' ) try: have_unicode = unicode --- 197,202 -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 17:12 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-08 02:23 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Nick Maclaren (nmm1) Date: 2002-11-19 14:44 Message: Logged In: YES user_id=652073 Well, that's an odd interpretation, but it isn't a great matter. However, I do feel that the "gotcha" should be documented. For example, the following perfectly reasonable use will fail horribly on many systems: A user version of a shareable library is in /usr/local/lib, which is a mountable filing system, and a system version in /usr/lib, which isn't - the former may be a symlink, or may be the testing version. Python is built using the standard mechanism, and is then used for system scripts. If those are then ever run when /usr/local is not mounted, they will fail horribly. Incidentally, we got caught by that one by making /usr mountable on one version of IRIX. It was actually SGI themselves who had missed the "gotcha", but we had the problem :-( Do what you will with this - I have resolved the issue here. -- Comment By: Skip Montanaro (montanaro) Date: 2002-11-19 14:38 Message: Logged In: YES user_id=44345 Some compilers complain if -I/usr/local/include is on the command line because it changes the compiler's notion of include file search order. The case -L/usr/local/lib may be similar. If this was an ideal world, I think we would ask the compiler if it searches /usr/local by default. If so, don't add the -I/-L flags. Maybe there's an autoconf macro floating around that can do this? -- Comment By: Martin v. Löwis (loewis) Date: 2002-11-19 14:05 Message: Logged In: YES user_id=21627 If /usr/local/lib causes a build failure, then the requirements are not absolutely standard, by (our) definition: We require /usr/local/lib to provide any libraries that are not normally on the system. Absence of /usr/local/lib is not a problem, nor are missing libraries a problem. If accessing /usr/local/lib alone causes catastrophic failures, it can't be a standard system. -- Comment By: Nick Maclaren (nmm1) Date: 2002-11-19 09:29 Message: Logged In: YES user_id=652073 No, that's not the issue. The build was absolutely out of the box, and the requirements were absolutely standard. But, for reasons that are irrelevant, -L/usr/local/lib caused failure. The point was that I had not specified it, it was not specified anywhere in the configuration or any of the Makefiles, and it wasn't even in Modules/Setup! So I co
[ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var
Bugs item #632323, was opened at 2002-11-01 19:39
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&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: Tkinter
>Group: Python 2.3
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: L. Peter Deutsch (lpd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tkinter: BitmapImage vanishes if not stored in non-local var
Initial Comment:
The following program incorrectly produces a blank canvas:
#!/usr/bin/env python
from Tkinter import *
class Me(Canvas):
def init1(self):
return BitmapImage(foreground = '#ff',
background = '#00ff00',
data = """#define t_width 8
#define t_height 8
static unsigned char t_bits[] = {
0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c};
""",
maskdata = """#define t_width 8
#define t_height 8
static unsigned char t_bits[] = {
0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18};
""")
def init2(self, image):
self.create_image(32, 32, anchor = NW, image =
image)
self = Me()
self.pack(expand = 1, fill = BOTH)
self.init2(self.init1())
#img = self.init1()
#self.init2(img)
self.mainloop()
However, the following program correctly draws a small
red-and-green icon:
#!/usr/bin/env python
from Tkinter import *
class Me(Canvas):
def init1(self):
return BitmapImage(foreground = '#ff',
background = '#00ff00',
data = """#define t_width 8
#define t_height 8
static unsigned char t_bits[] = {
0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c};
""",
maskdata = """#define t_width 8
#define t_height 8
static unsigned char t_bits[] = {
0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18};
""")
def init2(self, image):
self.create_image(32, 32, anchor = NW, image =
image)
self = Me()
self.pack(expand = 1, fill = BOTH)
#self.init2(self.init1())
img = self.init1()
self.init2(img)
self.mainloop()
The two programs are identical except that one of them
assigns the BitmapImage to a variable rather than
passing it directly as an argument.
Python 2.2.1, OS = Linux version 2.4.18-3
([EMAIL PROTECTED]) (gcc version 2.96
2731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18
07:37:53 EDT 2002
--
>Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 17:19
Message:
Logged In: YES
user_id=752496
OP says the problem persists, changing it to Py2.3.
I think that or we change the resolution from "Invalid" or
close the bug...
--
Comment By: L. Peter Deutsch (lpd)
Date: 2005-01-28 00:01
Message:
Logged In: YES
user_id=8861
SourceForge apparently failed to e-mail me a notification of
your follow-up, so I didn't find out about it until today
(exactly 1 month from your original posting), by accident.
The problem is definitely still there in 2.3.3, which is
what I currently have installed. I'll download and test
2.3.4 and 2.4 tomorrow. (I hope you'll give me an extra day!)
lpd
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-12-27 23:02
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Martin v. Löwis (loewis)
Date: 2002-12-11 08:59
Message:
Logged In: YES
user_id=21627
It's inconsistent with the rest of Tkinter. Everything in
Tkinter is an object, and so are images. If you want
strings, use plain _tkinter.
--
Comment By: Fredrik Lundh (effbot)
Date: 2002-12-11 06:33
Message:
Logged In: YES
user_id=38376
"..consider all common use cases -- if you don't do it
this way, you either end up with leaks, code that works
only by accident, or code that is a lot more convoluted
than the simple assignment that is necessary to work
around this problem in real life."
--
Comment By: Internet Discovery (idiscovery)
Date: 2002-12-11 06:01
Message:
Logged In: YES
user_id=33229
What's wrong with simply wrapping what Tk does with an image_create
method that returns a string and an image_delete method that accepts a string?
It's consistent with Tk u
[ python-Bugs-1201461 ] suspected cPickle memory leak
Bugs item #1201461, was opened at 2005-05-13 12:49 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201461&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.2 Status: Open Resolution: None Priority: 5 Submitted By: Alan (franz2) Assigned to: Nobody/Anonymous (nobody) Summary: suspected cPickle memory leak Initial Comment: I believe there is a memory leak in cPickle. I have a parallel code which uses array() and indices() from Numeric to massage data buffers before being sent and received by Pypar. Pypar subsequently uses cPickle to pickle the data. After many hours of execution, my code crashes with one of the following error messages (depending upon the run): a = zeros(shape, typecode, savespace) MemoryError: can't allocate memory for array or: s = dumps(x, 1) MemoryError: out of memory I have since modified my code to use a different data format so cPickle is no longer used from PyPar and now the code runs fine. -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 17:34 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Martin v. Löwis (loewis) Date: 2005-05-30 05:34 Message: Logged In: YES user_id=21627 Can you provide a test case that demonstrates how the memory is exhausted? Without a test case, it is unlikely that we will be able to find the suspected leak. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201461&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1211639 ] parser tells invalid syntax with correct code
Bugs item #1211639, was opened at 2005-05-31 00:36 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=1211639&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: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ntrunk (ntrunk) Assigned to: Nobody/Anonymous (nobody) Summary: parser tells invalid syntax with correct code Initial Comment: I work with python 2.4 on Win2000 Sp4. I wrote a simple game with 2 modules, importing one into the other. In the imported module I wrote in the first line the coding: iso-8859-15. Starting the script from the first module the parser shows 'invalid syntax'. By inserting *1* space in a comment line the script works fine! I reduced my scripts to the minimal lines, wich will reproduce the bug. (Actually the parser tells me, that the syntax error is in line 75 :-) Changing the coding to iso-8859-1 will making the bug dissapear. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1211639&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix
Bugs item #728515, was opened at 2003-04-27 10:44 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&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: Extension Modules Group: Python 2.2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-30 16:32 Message: Logged In: YES user_id=341410 The problem still persists in Python 2.3 and 2.4. A quick read of mmapmodule.c shows that ftruncate() is not being called within the non-windows portion of mmap_resize_method(). -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 11:59 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 09:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix
Bugs item #728515, was opened at 2003-04-27 14:44 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&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: Extension Modules >Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. -- >Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 20:51 Message: Logged In: YES user_id=752496 Reopened as posted that still is a bug. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-30 20:32 Message: Logged In: YES user_id=341410 The problem still persists in Python 2.3 and 2.4. A quick read of mmapmodule.c shows that ftruncate() is not being called within the non-windows portion of mmap_resize_method(). -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 15:59 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 14:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 09:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-856103 ] reload() fails with modules from zips
Bugs item #856103, was opened at 2003-12-08 02:48 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) >Assigned to: Nobody/Anonymous (nobody) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options>>> reload(Options) Traceback (most recent call last): File " ", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. -- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-30 19:09 Message: Logged In: YES user_id=44345 Tossing back into the pool. -- Comment By: Phillip J. Eby (pje) Date: 2004-09-23 08:41 Message: Logged In: YES user_id=56214 D'oh! PyImport_AddModule() only creates a new module if it doesn't already exist in sys.modules, so there's nothing to fix on that point. Now what's needed is someone familiar with zipimport.c internals to review Stephen's patch at: http://www.chase3000.com/stephenh/patch-zipimport.txt and clean out its stderr prints. -- Comment By: Phillip J. Eby (pje) Date: 2004-09-23 01:21 Message: Logged In: YES user_id=56214 I've fixed bug #1029475, so reload() will now actually invoke the PEP 302 loader mechanism. However, there's another bug in zipimport: the loader implementation in zipimport.c always creates a new module, even when reloading. It needs to check sys.modules first, and reuse the existing module if present. I'm attempting to fix that issue now, and once I'm done, someone more familiar with zipimport's cache mechanism can do the rest. -- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 16:00 Message: Logged In: YES user_id=642545 Turns out there are two issues here: PEP 302 using the loader, and then the zip import caching the contents of zip files. At the suggestion of Phillip Eby, the PEP 302 stuff not using a loader has been put in a new bug that he is going to take care of: https://sourceforge.net/tracker/index.php?func=detail&aid=1029475&group_id=5470&atid=105470 So, now there is just the separate issue of the zip import not checking the file modification time. The attached patch makes sure when reload(aZipModule) is called that the file modification time is checked and that the contents are reloaded. More details are in my last comment. There is a test case that passes as well. The patch is at a more permanent location this time: http://www.chase3000.com/stephenh/patch-zipimport.txt -- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 17:26 Message: Logged In: YES user_id=642545 Okay, so you talked me in to it. Besides the previous PyImport_ReloadModule patch, I modified zipimport.c to add another cache (zip_directory_cache of toc_entry's and zip_mtime_cache of modification times). On creation of a new ZipImporter or call to get_module_code, check_archive_mtime is called, which gets the new mtime and compares to the cached one. If they are different, it calls the old read_directory. read_directory was modified to, instead of creating a brand new path: [toc_entry] dictionary, clear and re-populate the same 'files' dictionary. This is so that if multiple ZipImporters are sharing an archive, and hence already sharing the same 'files' entry in zip_directory_cache, if one of them detects a new zip file and has the toc_entry's reloaded, the other ZipImporters will see the change to (as they all share the same dictionary). This was pretty much the same functionality before (sharing dictionaries), just that now read_directory clears/updates an exisitng one instead creating its own brand new one. Also, I had to add a sleep(1) call in testReload to ensure the modification time stamp would change. Again, either I don't have permiss
[ python-Feature Requests-1208730 ] expat binding for XML_ParserReset
Feature Requests item #1208730, was opened at 2005-05-25 13:37 Message generated for change (Comment added) made by zhar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: expat binding for XML_ParserReset Initial Comment: XML_ParserReset is an expat parser method for resetting the parser to handle a new document. This keeps you from having to create a new parser for each document. -- >Comment By: John Eikenberry (zhar) Date: 2005-05-30 23:10 Message: Logged In: YES user_id=322022 Ok. I gave it a whirl. The patch is attached. If you have a moment, could you please look over it and let me know if I made any mistakes. Its a forward diff as recommended by the guidelines. I tried to follow them as much as possible. Thanks. -- Comment By: Martin v. Löwis (loewis) Date: 2005-05-30 01:37 Message: Logged In: YES user_id=21627 Would you like to work on a patch for this feature? Exposing more methods from Expat is a good idea. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&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-1208730 ] expat binding for XML_ParserReset
Feature Requests item #1208730, was opened at 2005-05-25 13:37 Message generated for change (Comment added) made by zhar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: expat binding for XML_ParserReset Initial Comment: XML_ParserReset is an expat parser method for resetting the parser to handle a new document. This keeps you from having to create a new parser for each document. -- >Comment By: John Eikenberry (zhar) Date: 2005-05-30 23:12 Message: Logged In: YES user_id=322022 Forgot to mention I made the patch against current CVS. -- Comment By: John Eikenberry (zhar) Date: 2005-05-30 23:10 Message: Logged In: YES user_id=322022 Ok. I gave it a whirl. The patch is attached. If you have a moment, could you please look over it and let me know if I made any mistakes. Its a forward diff as recommended by the guidelines. I tried to follow them as much as possible. Thanks. -- Comment By: Martin v. Löwis (loewis) Date: 2005-05-30 01:37 Message: Logged In: YES user_id=21627 Would you like to work on a patch for this feature? Exposing more methods from Expat is a good idea. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1210832 ] An error in Python Tutorial
Bugs item #1210832, was opened at 2005-05-29 08:28 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gene (godhand) Assigned to: Nobody/Anonymous (nobody) Summary: An error in Python Tutorial Initial Comment: In section 4.4, the program should be written as follow to get the correct result: -- for n in range(2, 10): for x in range(2, n): if n % x == 0: print n, 'equals', x, '*', n/x break if x == n-1: print n, 'is a prime number' -- besides, the line "2 is a prime number" should not appear in the result output. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-30 23:22 Message: Logged In: YES user_id=341410 The indentation on your proposed code addition was lost during your post, re-post so that it is understandable. Further, from mathworld.com: "A prime number (or prime integer, often simply called a ''prime'' for short) is a positive integer p > 1 that has no positive integer divisors other than 1 and p itself. (More concisely, a prime number p is a positive integer having exactly one positive divisor other than 1.)" That is to say, 2 is prime, so should appear in the result output, and it seems to me that the code provided in tutorial section 4.4 is correct. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
