Gettysburg Address

From noreply@sourceforge.net Mon Jul 1 06:55:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 30 Jun 2002 22:55:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-534864 ] profiling with xml parsing asserts Message-ID: Bugs item #534864, was opened at 2002-03-25 22:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Aron K. Insinga (ainsinga) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: profiling with xml parsing asserts Initial Comment: I'm getting a 'bad call' assertion error when using the profiler when parsing XML. (It works ok without the profiler, and if I don't call SAXparser.parse it doesn't happen.) Python 2.2 (#1, Dec 23 2001, 09:30:32) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import t4crash start document end document >>> import profile >>> t4crash.test() start document end document >>> profile.run('t4crash.test()') start document Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/profile.py", line 71, in run prof = prof.run(statement) File "/usr/lib/python2.2/profile.py", line 404, in run return self.runctx(cmd, dict, dict) File "/usr/lib/python2.2/profile.py", line 410, in runctx exec cmd in globals, locals File "", line 1, in ? File "t4crash.py", line 46, in test main(files) File "t4crash.py", line 39, in main SAXparser.parse(fileName) File "/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py", line 53, in parse File "/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/xmlreader.py", line 123, in parse File "/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py", line 106, in feed File "/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py", line 179, in start_element File "/usr/lib/python2.2/profile.py", line 214, in trace_dispatch_i if self.dispatch[event](self, frame,t): File "/usr/lib/python2.2/profile.py", line 260, in trace_dispatch_call assert rframe.f_back is frame.f_back, ("Bad call", rfn, AssertionError: ('Bad call', ('/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py', 95, 'feed'), , , , ) >>> [ainsinga@ainsinga index_xml]$ cat t4crash.py #!/usr/bin/env python2 # t4crash.py by Aron K. Insinga (aron.insinga@av.com) 25-Mar-2002 import xml.sax import sys import string import re class ContentHandler(xml.sax.ContentHandler): """ Handle callbacks from the SAX XML parser. """ def __init__(selfy): pass def setDocumentLocator(self, locator): pass def startDocument(self): print 'start document' def endDocument(self): print 'end document' def startElement(self, name, attrs): pass def endElement(self, name): pass def main(files): SAXparser = xml.sax.make_parser() chand = ContentHandler() SAXparser.setContentHandler(chand) try: for fileName in files: SAXparser.parse(fileName) except xml.sax.SAXParseException: sys.stderr.write("%s; processing aborted\n" % (xml.sax.SAXParseException)) sys.exit(1) def test(): files = ['doc0.xml'] main(files) test() [ainsinga@ainsinga index_xml]$ cat doc0.xml Gettysburg Address

Four score and seven years ago...

LincolnAbraham 11191863 [ainsinga@ainsinga index_xml]$ which python /usr/bin/python [ainsinga@ainsinga index_xml]$ set | grep PATH LD_LIBRARY_PATH=/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib: PATH=$'/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:.:/home/ainsinga/bin:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/ staroffice6.0:/home/ainsinga/mozilla' [ainsinga@ainsinga index_xml]$ set | grep -i py [ainsinga@ainsinga index_xml]$uname -a Linux ainsinga 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown [ainsinga@ainsinga index_xml]$ ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-07-02 09:05 Message: Logged In: YES user_id=21627 Attached is a patch that fixes the problem. ---------------------------------------------------------------------- Comment By: Andrew P. Lentvorski, Jr. (andrewl) Date: 2002-07-02 02:13 Message: Logged In: YES user_id=28733 The xmltest.py program follows since I appear to be too stupid to figure out how to attach a file to a bug report on SourceForge. -a #!/usr/bin/env python import xml.sax testxml = \ """ """ class ContentHandler(xml.sax.ContentHandler): """ Handle callbacks from the SAX XML parser. """ def __init__(self): pass def startElement(self, name, attrs): print "start element" def endElement(self, name): print "end element" def main(): chand = ContentHandler() xml.sax.parseString(testxml, chand) if __name__ == "__main__": main() ---------------------------------------------------------------------- Comment By: Andrew P. Lentvorski, Jr. (andrewl) Date: 2002-07-02 02:01 Message: Logged In: YES user_id=28733 Here is a session log for a much more self-contained regression file (xmltest.py): andrewl@taz:andrewl$ python Python 2.2.1 (#1, May 27 2002, 16:42:22) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import profile >>> import xmltest >>> profile.run('xmltest.main()') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/profile.py", line 71, in run prof = prof.run(statement) File "/usr/local/lib/python2.2/profile.py", line 404, in run return self.runctx(cmd, dict, dict) File "/usr/local/lib/python2.2/profile.py", line 410, in runctx exec cmd in globals, locals File "", line 1, in ? File "xmltest.py", line 24, in main xml.sax.parseString(testxml, chand) File "/usr/local/lib/python2.2/xml/sax/__init__.py", line 49, in parseString parser.parse(inpsrc) File "/usr/local/lib/python2.2/xml/sax/expatreader.py", line 90, in parse xmlreader.IncrementalParser.parse(self, source) File "/usr/local/lib/python2.2/xml/sax/xmlreader.py", line 123, in parse self.feed(buffer) File "/usr/local/lib/python2.2/xml/sax/expatreader.py", line 143, in feed self._parser.Parse(data, isFinal) File "/usr/local/lib/python2.2/xml/sax/expatreader.py", line 216, in start_element def start_element(self, name, attrs): File "/usr/local/lib/python2.2/profile.py", line 214, in trace_dispatch_i if self.dispatch[event](self, frame,t): File "/usr/local/lib/python2.2/profile.py", line 260, in trace_dispatch_call assert rframe.f_back is frame.f_back, ("Bad call", rfn, AssertionError: ('Bad call', ('/usr/local/lib/python2.2/xml/sax/expatreader.py', 132, 'feed'), , , , ) ---------------------------------------------------------------------- Comment By: Andrew P. Lentvorski, Jr. (andrewl) Date: 2002-07-02 00:57 Message: Logged In: YES user_id=28733 There is another filing on this problem at: http://mail.python.org/pipermail/xml-sig/2002-April/007632.html Also, I reproduced this on another FreeBSD box today as well. andrewl@taz:andrewl$ python Python 2.2.1 (#1, May 27 2002, 16:42:22) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 -a ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-01 17:55 Message: Logged In: YES user_id=31435 I reproduced this with current CVS Python on Windows; see attached traceback.txt, which shows a screen dump of the offending interactive session. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-01 07:55 Message: Logged In: YES user_id=21627 I can't reproduce it with the Python 2.2 that ships with SuSE 8.0, either. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-27 13:30 Message: Logged In: YES user_id=21627 I can't reproduce the crash, with 2.3a0. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-25 23:27 Message: Logged In: YES user_id=31435 Assigned to Fred. ---------------------------------------------------------------------- Comment By: Aron K. Insinga (ainsinga) Date: 2002-03-25 22:19 Message: Logged In: YES user_id=496408 attached is the sample program (which ought to have indenting preserved!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470 From noreply@sourceforge.net Tue Jul 2 12:23:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 04:23:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-418626 ] maximum recursion limit exceeded (2.1) Message-ID: Bugs item #418626, was opened at 2001-04-24 12:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=418626&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fredrik Lundh (effbot) Summary: maximum recursion limit exceeded (2.1) Initial Comment: % /usr/bin/env python2.1 Python 2.1 (#2, Apr 24 2001, 11:33:06) [GCC 2.95.3 20010315 (release)] on hp-uxB Type "copyright", "credits" or "license" for more information. >>> % uname -a HP-UX wshelley B.11.00 A 9000/785 2014123772 two-user license % rebug.py Traceback (most recent call last): File "rebug.py", line 205, in ? re.search("== Data Table ==\n(.*?)\n(.*?)\s*$", output, re.S) File "/usr/local/lib/python2.1/sre.py", line 57, in search return _compile(pattern, flags).search(string) RuntimeError: maximum recursion limit exceeded rebug.py script works correctly using python1.5.2 I submitted this bug as a followup to [ #215696 ] sre RuntimeError when .*? matches >16K string ##### The following is the rebug.py file #!/usr/bin/env python2.1 import re output = """Using == Data Table == s m:d mb 3.300000 0.000104772187944365 -1.23330767339032e-15 3.200000 0.000103862130408037 -1.23481086168441e-15 3.100000 0.000102831826202984 -1.23643366708223e-15 3.000000 0.000101671354638586 -1.23819069775402e-15 2.900000 0.000100370082245968 -1.24009908383179e-15 2.800000 9.89166376398503e-05 -1.24217904419247e-15 2.700000 9.72988932844521e-05 -1.24445461136295e-15 2.600000 9.55039568198016e-05 -1.24695456774457e-15 2.500000 9.3518175238995e-05 -1.24971366756711e-15 2.400000 9.13271559565959e-05 -1.25277425005882e-15 2.300000 8.89158096852735e-05 -1.25618839559713e-15 2.200000 8.62684210547775e-05 -1.26002084671538e-15 2.100000 8.33687540802062e-05 -1.26435302405962e-15 2.000000 8.02002009414518e-05 -1.26928863786894e-15 1.900000 7.67459841300842e-05 -1.27496167015724e-15 1.800000 7.29894239935539e-05 -1.28154795600633e-15 1.700000 6.89142864097651e-05 -1.28928236065365e-15 1.600000 6.45052296412595e-05 -1.29848488989922e-15 1.500000 5.97483776126083e-05 -1.30960148694006e-15 1.400000 5.46320649249439e-05 -1.32326977154928e-15 1.300000 4.91478435825781e-05 -1.3404286750276e-15 1.200000 4.32919623998454e-05 -1.36250830892367e-15 1.100000 3.70678871330223e-05 -1.39177202537724e-15 1.000000 3.04915786576429e-05 -1.43195494399345e-15 0.900000 2.36052666077545e-05 -1.48947100843164e-15 0.800000 1.65202853321069e-05 -1.57551564136398e-15 0.700000 9.56073716566518e-06 -1.70791288744525e-15 0.600000 3.67125710597e-06 -1.89923336361812e-15 0.500000 6.00021904261974e-07 -2.08381565027337e-15 0.400000 4.27864345038415e-08 -2.14973379503184e-15 0.300000 2.5741570279509e-09 -2.15852923041729e-15 0.200000 1.60325700603365e-10 -2.15762110254924e-15 0.100000 1.10181009347061e-11 -2.15430351925385e-15 0.000000 9.18460199298261e-13 -2.14607756126421e-15 -0.100000 8.2907448480307e-14 -2.13154544128925e-15 -0.200000 9.49291906644266e-15 -2.09562596113738e-15 -0.300000 2.57398712712903e-15 -1.89144055818718e-15 -0.400000 1.23896929747012e-15 -1.18482371296596e-15 -0.500000 4.77088843470797e-16 -4.74259070979461e-16 3.300000 0.000725333230235404 -1.60279744215745e-14 3.200000 0.000698989627849489 -1.57983897758426e-14 3.100000 0.000672395787137216 -1.55721529060957e-14 3.000000 0.000645566845212758 -1.53549883971193e-14 2.900000 0.000618516906916818 -1.51624220311135e-14 2.800000 0.000591259277466284 -1.50347782956977e-14 2.700000 0.000563806714724985 -1.5069525306854e-14 2.600000 0.000536171704020601 -1.54848062262748e-14 2.500000 0.000508366761845922 -1.67334737461837e-14 2.400000 0.000480404778779427 -1.96904798125589e-14 2.300000 0.00045229941701671 -2.59347024715496e-14 2.200000 0.000424065584744255 -3.81354821168744e-14 2.100000 0.000395720019338978 -6.05316531752639e-14 2.000000 0.000367282025836478 -9.9457021513997e-14 1.900000 0.000338774439198852 -1.63825993533288e-13 1.800000 0.000310224913488982 -2.65456611717139e-13 1.700000 0.000281667696431468 -4.19089961445906e-13 1.600000 0.000253146138686846 -6.4197984099406e-13 1.500000 0.000224716340367884 -9.52983499747302e-13 1.400000 0.00019645260393449 -1.37117106753005e-12 1.300000 0.000168455842857815 -1.9140171376089e-12 1.200000 0.000140866992561325 -2.5949957749272e-12 1.100000 0.000113889209694637 -3.419066099784e-12 1.000000 8.78261401150504e-05 -4.36958009251635e-12 0.900000 6.31506490822963e-05 -5.36461118003355e-12 0.800000 4.06312963119592e-05 -6.12577475587495e-12 0.700000 2.15481889941145e-05 -5.92418822150058e-12 0.600000 7.87604367966821e-06 -3.80859906972703e-12 0.500000 1.3904896761789e-06 -9.79870732426348e-13 0.400000 1.06064890626322e-07 -9.39992702457847e-14 0.300000 6.34950130197645e-09 -1.65503941397823e-14 0.200000 3.88292805625561e-10 -1.16204226732226e-14 0.100000 2.57865399432747e-11 -1.11870703136006e-14 0.000000 2.05458930149398e-12 -1.09482596289954e-14 -0.100000 1.85578779234532e-13 -1.06729449780495e-14 -0.200000 2.5577583052963e-14 -1.02232392679007e-14 -0.300000 1.05769385343133e-14 -9.2322860676878e-15 -0.400000 8.00273522170935e-15 -7.88228414475344e-15 -0.500000 6.51965630664677e-15 -6.50815076902941e-15 3.300000 0.000778073989265561 -1.65574096734398e-07 3.200000 0.00074963150963251 -1.92244746339178e-07 3.100000 0.000721015586364691 -2.21197891556889e-07 3.000000 0.000692226507232058 -2.52254070463242e-07 2.900000 0.000663264988754168 -2.85152554002688e-07 2.800000 0.000634132321079485 -3.19546222567145e-07 2.700000 0.000604830546549725 -3.54998299569146e-07 2.600000 0.000575362679604795 -3.90981285317844e-07 2.500000 0.000545732977654778 -4.26878409205096e-07 2.400000 0.000515947275272665 -4.61987879332959e-07 2.300000 0.000486013397947319 -4.95530155074015e-07 2.200000 0.000455941677304999 -5.26658398699649e-07 2.100000 0.000425745598153737 -5.54472176489517e-07 2.000000 0.000395442620520435 -5.78034377120716e-07 1.900000 0.000365055239615154 -5.96391194651538e-07 1.800000 0.000334612377612625 -6.0859488246625e-07 1.700000 0.000304151250425071 -6.13728816719563e-07 1.600000 0.000273719932661724 -6.1093419812057e-07 1.500000 0.000243380977243086 -5.99437433988553e-07 1.400000 0.000213216675616044 -5.78576796961394e-07 1.300000 0.000183336956663227 -5.47826196051382e-07 1.200000 0.000153891700661593 -5.06812695554088e-07 1.100000 0.000125090796710056 -4.55323667088038e-07 1.000000 9.7238530664174e-05 -3.9330616509577e-07 0.900000 7.07959411929754e-05 -3.20910962327376e-07 0.800000 4.64992533700793e-05 -2.38877973057319e-07 0.700000 2.55795422135307e-05 -1.50458199069334e-07 0.600000 1.00314893206752e-05 -6.74343626580743e-08 0.500000 2.00947524041218e-06 -1.48839482947924e-08 0.400000 1.67232105200131e-07 -1.2816627677716e-09 0.300000 1.00809637284154e-08 -7.82708572696571e-11 0.200000 6.12196843592758e-10 -4.83619605089934e-12 0.100000 4.0027953235145e-11 -3.39466185939354e-13 0.000000 3.1163322565507e-12 -4.38427713973686e-14 -0.100000 2.82036148373174e-13 -2.01235539818538e-14 -0.200000 4.04726306794353e-14 -1.75747562532315e-14 -0.300000 1.83397331593843e-14 -1.63366924660679e-14 -0.400000 1.50709750319906e-14 -1.48901998089388e-14 -0.500000 1.34240392889815e-14 -1.34063683071726e-14 3.300000 0.000104772187944365 -1.23330767339032e-15 3.200000 0.000103862130408037 -1.23481086168441e-15 3.100000 0.000102831826202984 -1.23643366708223e-15 3.000000 0.000101671354638586 -1.23819069775402e-15 2.900000 0.000100370082245968 -1.24009908383179e-15 2.800000 9.89166376398503e-05 -1.24217904419247e-15 2.700000 9.72988932844521e-05 -1.24445461136295e-15 2.600000 9.55039568198016e-05 -1.24695456774457e-15 2.500000 9.3518175238995e-05 -1.24971366756711e-15 2.400000 9.13271559565959e-05 -1.25277425005882e-15 2.300000 8.89158096852735e-05 -1.25618839559713e-15 2.200000 8.62684210547775e-05 -1.26002084671538e-15 2.100000 8.33687540802062e-05 -1.26435302405962e-15 2.000000 8.02002009414518e-05 -1.26928863786894e-15 1.900000 7.67459841300842e-05 -1.27496167015724e-15 1.800000 7.29894239935539e-05 -1.28154795600633e-15 1.700000 6.89142864097651e-05 -1.28928236065365e-15 1.600000 6.45052296412595e-05 -1.29848488989922e-15 1.500000 5.97483776126083e-05 -1.30960148694006e-15 1.400000 5.46320649249439e-05 -1.32326977154928e-15 1.300000 4.91478435825781e-05 -1.3404286750276e-15 1.200000 4.32919623998454e-05 -1.36250830892367e-15 1.100000 3.70678871330223e-05 -1.39177202537724e-15 1.000000 3.04915786576429e-05 -1.43195494399345e-15 0.900000 2.36052666077545e-05 -1.48947100843164e-15 0.800000 1.65202853321069e-05 -1.57551564136398e-15 0.700000 9.56073716566518e-06 -1.70791288744525e-15 0.600000 3.67125710597e-06 -1.89923336361812e-15 0.500000 6.00021904261974e-07 -2.08381565027337e-15 0.400000 4.27864345038415e-08 -2.14973379503184e-15 0.300000 2.5741570279509e-09 -2.15852923041729e-15 0.200000 1.60325700603365e-10 -2.15762110254924e-15 0.100000 1.10181009347061e-11 -2.15430351925385e-15 0.000000 9.18460199298261e-13 -2.14607756126421e-15 -0.100000 8.2907448480307e-14 -2.13154544128925e-15 -0.200000 9.49291906644266e-15 -2.09562596113738e-15 -0.300000 2.57398712712903e-15 -1.89144055818718e-15 -0.400000 1.23896929747012e-15 -1.18482371296596e-15 -0.500000 4.77088843470797e-16 -4.74259070979461e-16 3.300000 0.000725333230235404 -1.60279744215745e-14 3.200000 0.000698989627849489 -1.57983897758426e-14 3.100000 0.000672395787137216 -1.55721529060957e-14 3.000000 0.000645566845212758 -1.53549883971193e-14 2.900000 0.000618516906916818 -1.51624220311135e-14 2.800000 0.000591259277466284 -1.50347782956977e-14 2.700000 0.000563806714724985 -1.5069525306854e-14 2.600000 0.000536171704020601 -1.54848062262748e-14 2.500000 0.000508366761845922 -1.67334737461837e-14 2.400000 0.000480404778779427 -1.96904798125589e-14 2.300000 0.00045229941701671 -2.59347024715496e-14 2.200000 0.000424065584744255 -3.81354821168744e-14 2.100000 0.000395720019338978 -6.05316531752639e-14 2.000000 0.000367282025836478 -9.9457021513997e-14 1.900000 0.000338774439198852 -1.63825993533288e-13 1.800000 0.000310224913488982 -2.65456611717139e-13 1.700000 0.000281667696431468 -4.19089961445906e-13 1.600000 0.000253146138686846 -6.4197984099406e-13 1.500000 0.000224716340367884 -9.52983499747302e-13 1.400000 0.00019645260393449 -1.37117106753005e-12 1.300000 0.000168455842857815 -1.9140171376089e-12 1.200000 0.000140866992561325 -2.5949957749272e-12 1.100000 0.000113889209694637 -3.419066099784e-12 1.000000 8.78261401150504e-05 -4.36958009251635e-12 0.900000 6.31506490822963e-05 -5.36461118003355e-12 0.800000 4.06312963119592e-05 -6.12577475587495e-12 0.700000 2.15481889941145e-05 -5.92418822150058e-12 0.600000 7.87604367966821e-06 -3.80859906972703e-12 0.500000 1.3904896761789e-06 -9.79870732426348e-13 0.400000 1.06064890626322e-07 -9.39992702457847e-14 0.300000 6.34950130197645e-09 -1.65503941397823e-14 0.200000 3.88292805625561e-10 -1.16204226732226e-14 0.100000 2.57865399432747e-11 -1.11870703136006e-14 0.000000 2.05458930149398e-12 -1.09482596289954e-14 -0.100000 1.85578779234532e-13 -1.06729449780495e-14 -0.200000 2.5577583052963e-14 -1.02232392679007e-14 -0.300000 1.05769385343133e-14 -9.2322860676878e-15 -0.400000 8.00273522170935e-15 -7.88228414475344e-15 -0.500000 6.51965630664677e-15 -6.50815076902941e-15 """ re.search("== Data Table ==\n(.*?)\n(.*?)\s*$", output, re.S) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-02 04:23 Message: Logged In: NO I have the same problem, running Python 2.1.3. It works well under Windows XP, but fails under Linux. Both Python 2.1.3. This is the pattern I am trying to match: ([\s,\S]*?) I use re.split in order to group code outside tables and code inside tables. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-24 20:28 Message: Logged In: YES user_id=31435 Assigned to /F. Works for me on Win98 under 2.1. Binding m to the re result and then printing print m.span(), len(output), m.span(1), m.span(2) yields (8, 12112) 12112 (25, 43) (44, 12111) Anonymous, this is a poor use for regexps: the code would be clearer, simpler and faster (plus it wouldn't blow up ) if you used basic string operations instead. The (.*?)\s*$ at the end is especially wasteful: you're teilling the regexp engine to do 12,000+ useless match attempts there, when all you *want* is the entire tail end of the string stripped of trailing whitespace. So just grab the tail end of the string directly and do string.rstrip() on it; saves 12,000+ useless matching attempts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=418626&group_id=5470 From noreply@sourceforge.net Tue Jul 2 16:02:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 08:02:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-576419 ] Infinite recursion in Pickle Message-ID: Bugs item #576419, was opened at 2002-07-02 19:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576419&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: Infinite recursion in Pickle Initial Comment: Pickle falls into infininite recursion, cPickle crashed (segfault on Linux, bus error on FreeBSD). See the attached file. There is initial pickle (just a very simple though somewhat large tree of bookmarks; unfortunately lesser tree does not trigger the bug); bkmk_objects.py module that includes class definitions for the pickled object, and simple test program that demonstrates the bug. The program loads initial pickle, runs a function upon it and saves the pickle back. The function runs through the entire tree and creates backlinks - every object got a link to its parent folder. So it seems the bug is related to pickling objects with loops. When I changed builtin list as a parent class of Folder to UserList (and recreated initial pickle) the bug disappeared, so I think the bug is related to pickling new classes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576419&group_id=5470 From noreply@sourceforge.net Tue Jul 2 16:48:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 08:48:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-576016 ] Docs missing for PyErr_SetFromWindows... Message-ID: Bugs item #576016, was opened at 2002-07-01 17:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576016&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: Docs missing for PyErr_SetFromWindows... Initial Comment: Docs are missing for PyErr_SetFromWindowsErr() and PyErr_SetFromWindowsErrWithFilename(). While we're at it, shouldn't there also be variants of these functions taking an additional 'PyObject *exc' parameter, allowing to specify other exception types (probably subclasses of PyExc_WindowsError)? ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-07-02 17:48 Message: Logged In: YES user_id=11105 Checked in (slightly changed) as exceptions.tex rev 1.6 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 03:56 Message: Logged In: YES user_id=3066 Please check in on the trunk. Thanks! ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-07-01 21:23 Message: Logged In: YES user_id=11105 Simple-minded patch, which only describes what these functions do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576016&group_id=5470 From noreply@sourceforge.net Tue Jul 2 16:52:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 08:52:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions Message-ID: Bugs item #413582, was opened at 2001-04-03 20:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: g++ must be called for c++ extensions Initial Comment: When building c++ extension using distutils setup, the compiler that was used to build python distribution is always called. On Linux, it is normally gcc. When gcc is called to link shared library, it does not link certain c++ runtime stuff. As a result, when extension is imported, missing symbols are reported, e.g.: >>> import ex_ext1 Traceback (most recent call last): File "", line 1, in ? ImportError: ./ex_ext1.so: undefined symbol: __vt_13runtime_error >>> I tried to use "extra_link_args = ['-x c++']" in setup.py (it tells gcc to link as c++), but that gets added to the end of compiler's command line, which results in: gcc -shared build/temp.linux-i686-2.1/ex_ext1.o -L../boost/libs/python -lboost_python -o build/lib.linux-i686-2.1/ex_ext1.so -x c++ gcc: Warning: `-x c++' after last input file has no effect Proposed solution: either use CXX= variable from Python Makefile when c++ files are involved, or prepend extra_link_args to compiler's arguments instead of appending them. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-18 08:55 Message: Logged In: YES user_id=6380 reassigned to amk who should know ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-04-18 02:47 Message: Logged In: YES user_id=29957 can this be closed as a duplicate of 454030? That one has a real submitter, and some more info... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 11:51 Message: Logged In: YES user_id=6380 Assigning this to Andrew, who is the current distutils maintainer. ---------------------------------------------------------------------- Comment By: Andrei Tovtchigretchko (andreitd) Date: 2001-04-04 20:23 Message: Logged In: YES user_id=189208 Follow-up: If I link with a static library (-lboost_python is libboost_python.a in bug post example), the problem shows. If I link with shared c++ library (libboost_python.so), everything is ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 From noreply@sourceforge.net Tue Jul 2 18:08:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 10:08:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-527064 ] bogus URLs cause exception in httplib Message-ID: Bugs item #527064, was opened at 2002-03-07 17:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527064&group_id=5470 Category: Python Library Group: Python 2.1.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brian Cox (brian_cox) Assigned to: Jeremy Hylton (jhylton) Summary: bogus URLs cause exception in httplib Initial Comment: This is a partial HTTP header from IIS: HTTP/1.1 302 Redirect Server: Microsoft-IIS/5.0 Date: Wed, 06 Mar 2002 19:41:34 GMT P3P: CP='ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI' Location: http://www.microsoft.comhttp://support.microsoft.com/de fault.aspx?LN=RU Notice the 'Location:'; this causes a ValueError exception in httplib in class HTTPConnection, method _set_hostport(): port = int(host[i+1:]) I fixed this by doing: try: port = int(host[i+1:]) except ValueError: raise InvalidHost(host) and adding: class InvalidHost(HTTPException): def __init__(self, host): self.host = host def __str__(self): return "invalid host- '%s'" % self.host ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-07-02 17:08 Message: Logged In: YES user_id=31392 Already fixed by Skip in rev 1.48 & 1.49. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527064&group_id=5470 From noreply@sourceforge.net Tue Jul 2 19:55:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 11:55:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows) Message-ID: Bugs item #216289, was opened at 2000-10-06 19:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: Later Priority: 3 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: Programs using Tkinter sometimes can't shut down (Windows) Initial Comment: The following msg from the Tutor list is about 1.6, but I noticed the same thing several times today using 2.0b2+CVS. In my case, I was running IDLE via python ../tool/idle/idle.pyw from a DOS box in my PCbuild directory. Win98SE. *Most* of the time, shutting down IDLE via Ctrl+Q left the DOS box hanging. As with the poster, the only way to regain control was to use the Task Manager to kill off Winoldap. -----Original Message----- From: Joseph Stubenrauch Sent: Friday, October 06, 2000 9:23 PM To: tutor@python.org Subject: Re: [Tutor] Python 1.6 BUG Strange, I have been experiencing the same bug myself. Here's the low down for me: Python 1.6 with win95 I am running a little Tkinter program The command line I use is simply: "python foo.py" About 25-35% of the time, when I close the Tkinter window, DOS seems to "freeze" and never returns to the c:\ command prompt. I have to ctrl-alt-delete repeatedly and shut down "winoldapp" to get rid of the window and then shell back into DOS and keep working. It's a bit of a pain, since I have the habit of testing EVERYTHING in tiny little stages, so I change one little thing, test it ... freeze ... ARGH! Change one more tiny thing, test it ... freeze ... ARGH! However, sometimes it seems to behave and doesn't bother me for an entire several hour session of python work. That's my report on the problem. Cheers, Joe ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-07-02 11:55 Message: Logged In: YES user_id=72656 I appreciate that many others see this is a problem in embedding Tcl, but without any clear way to reproduce this in Tcl/Tk itself, it's very hard for me to fix it. I don't think that there is anything done in 8.4 to fix this that I recall, but if someone finds that the problem "goes away" with 8.4, please report that. For those of course that experience this with python, the simple and "correct" work-around is to launch with pythonw.exe instead of python.exe. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-26 10:40 Message: Logged In: NO According to http://tcl.activestate.com ActiveTcl 8.4.0 is now available for download. It is new as of June 24. I don't know whether this will solve our problems or not, but it's worth looking into. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-19 06:36 Message: Logged In: NO I just downloaded Ruby 1.6.6 for Windows, which also uses Tcl/Tk 8.3 and I experience exactly the same problem there. So this is definitely a Tcl problem (but we know that already). ---------------------------------------------------------------------- Comment By: John Popplewell (johnnypops) Date: 2002-06-07 12:01 Message: Logged In: YES user_id=143340 Hmmm. I run a Python Tcl/Tk application several times every day - the very application that prompted my bug-hunt. I do use "pythonw.exe" to launch it, but it used to hang almost as badly as "python.exe". Whilst developing this app I used "python.exe" and experienced no hang-ups. The Tcl guys point out that this bug is only one of several possible causes of the hang-up, maybe you are just out of luck. The patch has fixed the problem on three Win98 machines, all of which exhibited the problem before updating the DLLs. One thought - are you sure there weren't multiple copies of the tcl83.dll and tk83.dll files? My (only) copies were in "D:\python20\DLLs" good luck, John. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-06-03 11:55 Message: Logged In: YES user_id=72656 providing Tim with a fixed DLL exactly according to John Popplewell's patch did not fix the problem for him. That makes it seem fishy that John really didn't see the problem any more. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-06-03 09:59 Message: Logged In: YES user_id=31435 I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from Tcl/Tk 8.3.2) with newer matched sets from A) PythonWare's py21 distribution (Tcl/Tk 8.3.3). and again from B) ActiveState's Tcl/Tk 8.3.4. All the symptoms originally reported here persisted on Win98SE despite that. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-22 06:57 Message: Logged In: NO I am new to Python and encountered this bug on my very first Tkinter application. It persists in Python 2.2.1 under Windows Me. Needless to say, it makes a bad first impression. Basically, this thread says that Tkinter has been broken for a year and a half on a popular platform at a time when Python is trying to expand its user base. Hopefully, this bug will be corrected soon. If Tcl/Tk 8.4 is not released shortly you might try repackaging Tkinter for Win32 with an earlier version of Tcl/Tk, such as 8.0, that doesn't encounter this problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-22 19:36 Message: Logged In: YES user_id=6380 The proper action is to wait until Tcl 8.3.5 is released, and then shaming someone else in providing you with a set of Windowsbinaries for Tcl. You may also ask Hobbs if there's a Windows project file to build Tcl/Tk for Windows. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-03-11 18:31 Message: Logged In: YES user_id=72656 I did end up back-porting this to the 8.3.4+ Tcl CVS on 2002-02-25, which means it will be in an eventual 8.3.5. It is already in the release 8.4 alpha series. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-09 17:50 Message: Logged In: YES user_id=31435 Back to Guido: Do you think you know what the proper action is? (You said that's why you reopened it, and there's been no new info here since then.) ---------------------------------------------------------------------- Comment By: John Popplewell (johnnypops) Date: 2002-02-25 16:55 Message: Logged In: YES user_id=143340 I knew I wasn't getting to the heart of it .... Almost a one-liner! It has been seriously spoiling my (otherwise crash free) Python experience on Win9x - hope it gets fixed soon. cheers, John. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-25 15:39 Message: Logged In: YES user_id=6380 Reopened until we know what the proper action is. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-02-25 15:32 Message: Logged In: YES user_id=72656 This is mostly correct, and is fixed in the 8.4 Tcl sources already (I guess we can backport this). This was mentioned in SF Tcl bug (account for chopped URL): https://sourceforge.net/tracker/? func=detail&aid=217982&group_id=10894&atid=110894 and the code comment is: /* * Only finalize the notifier if a notifier was installed in the * current thread; there is a route in which this is not * guaranteed to be true (when tclWin32Dll.c:DllMain() is called * with the flag DLL_PROCESS_DETACH by the OS, which could be * doing so from a thread that's never previously been involved * with Tcl, e.g. the task manager) so this check is important. * * Fixes Bug #217982 reported by Hugh Vu and Gene Leache. */ if (tsdPtr == NULL) { return; } ---------------------------------------------------------------------- Comment By: John Popplewell (johnnypops) Date: 2002-02-25 14:41 Message: Logged In: YES user_id=143340 This one has been torturing me for a while. Managed to track it down to a problem inside Tcl. For the Tcl8.3.4 source distribution the problem is in the file win/tclWinNotify.c void Tcl_FinalizeNotifier(ClientData clientData) { ThreadSpecificData *tsdPtr = (ThreadSpecificData *) clientData; /* sometimes called with tsdPtr == NULL */ if ( tsdPtr != NULL ) { DeleteCriticalSection(&tsdPtr->crit); CloseHandle(tsdPtr->event); /* * Clean up the timer and messaging * window for this thread. */ if (tsdPtr->hwnd) { KillTimer(tsdPtr->hwnd, INTERVAL_TIMER); DestroyWindow(tsdPtr->hwnd); } } /* * If this is the last thread to use the notifier, * unregister the notifier window class. */ Tcl_MutexLock(¬ifierMutex); if ( notifierCount && !--notifierCount ) { UnregisterClassA( "TclNotifier", TclWinGetTclInstance()); } Tcl_MutexUnlock(¬ifierMutex); } This bodge doesn't address the underlying problem but has stopped me from tearing all my hair out, cheers, John Popplewell. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-24 15:27 Message: Logged In: YES user_id=31435 FYI, you don't need an IDE to do this -- in Win9x, hit Ctrl+Alt+Del and kill the process directly. A saner solution is to develop under Win2K, which doesn't appear to suffer this problem (the only reports I've seen, and experienced myself, came from Win9x boxes). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-24 01:52 Message: Logged In: NO For those who are still trapped in this bug's hell, I will gladly share the one thing that saved my sanity: WingIDE's 'Kill' command will shut down the program with apparent 100% certainty and no fear of lockups. WingIDE has its own issues, so its not a perfect solution, but if you are like me and Joe (above) who test in small iterations, then using 'Kill' to quit out of your app while testing is a workaround that may preserve your sanity. Perhaps the python gods and the Wing guys can get together and tell us how to replicate 'kill' into our code. For now, I'll use WingIDE to edit, and pythonw.exe for my final client's delivery. ---------------------------------------------------------------------- Comment By: Howard Lightstone (hlightstone) Date: 2001-09-05 10:43 Message: Logged In: YES user_id=66570 I sometimes get bunches of these.... A tool I use (Taskinfo2000) reports that (after killing winoldap): python.exe is blocked on a mutex named OLESCELOCKMUTEX. The reported state is "Console Terminating". There appears to be only one (os) thread running. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-02 13:06 Message: Logged In: YES user_id=31435 No sign of progress on this presumed Tk/Tcl Windows bug in over 3 months, so closing it for lack of hope. ---------------------------------------------------------------------- Comment By: Doug Henderson (djhender) Date: 2001-02-05 21:13 Message: This was a symptom I saw while tracking down the essence of the problem reported in #131207. Using Win98SE, I would get an error dialog (GPF?) in the Kernel, and sometimes the dos prompt would not come back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-12-12 18:00 Message: Just reproduced w/ current CVS, but didn't hang until the 8th try. http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest released version; don't know whether that URL still makes sense, though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-12 12:58 Message: Tim, can you still reproduce this with the current CVS version? There's been one critical patch to _tkinter since the 2.0 release. An alternative would be to try with a newer version of Tcl (isn't 8.4 out already?). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-10-15 09:47 Message: Same as I've reported earlier; it hangs in the call to Tcl_Finalize (which is called by the DLL finalization code). It's less likely to hang if I call Tcl_Finalize from the _tkinter DLL (from user code). Note that the problem isn't really Python-related -- I have stand-alone samples (based on wish) that hangs in the same way. More later. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-13 07:40 Message: Back to Tim since I have no clue what to do here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-12 10:25 Message: The recent fix to _tkinter (Tcl_GetStringResult(interp) instead of interp->result) didn't fix this either. As Tim has remarked in private but not yet recorded here, a workaround is to use pythonw instead of python, so I'm lowering thepriority again. Also note that the hanging process that Tim writes about apparently prevents Win98 from shutting down properly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-10-07 00:37 Message: More info (none good, but some worse so boosted priority): + Happens under release and debug builds. + Have not been able to provoke when starting in the debugger. + Ctrl+Alt+Del and killing Winoldap is not enough to clean everything up. There's still a Python (or Python_d) process hanging around that Ctrl+Alt+Del doesn't show. + This process makes it impossible to delete the associated Python .dll, and in particular makes it impossible to rebuild Python successfully without a reboot. + These processes cannot be killed! Wintop and Process Viewer both fail to get the job done. PrcView (a freeware process viewer) itself locks up if I try to kill them using it. Process Viewer freezes for several seconds before giving up. + Attempting to attach to the process with the MSVC debugger (in order to find out what the heck it's doing) finds the process OK, but then yields the cryptic and undocumented error msg "Cannot execute program". + The processes are not accumulating cycles. + Smells like deadlock. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470 From noreply@sourceforge.net Tue Jul 2 20:03:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 12:03:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-574241 ] Automated daily documentation builds Message-ID: Bugs item #574241, was opened at 2002-06-26 15:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Automated daily documentation builds Initial Comment: Set-up a cron job or python script to make daily rebuilds of the Python documentation at: www.python.org/dev/doc/devel Developers using Windows and not using Cygwin do not have a method for doing their own builds. I think daily updates would be helpful for all developers and would increase the likelihood that people check their patches versus current documentation. Also, it increases the chance that someone will notice and report a documentation error earlier in the release cycle. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 15:03 Message: Logged In: YES user_id=3066 I don't think failing frequently is a problem if the failure shows up in someone's email. It should probably go to python-docs@python.org, and I can turn that into a fix. Perhaps it should go to the Doc-SIG instead, to allow more people to help. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-30 14:46 Message: Logged In: YES user_id=21627 I don't think this is possible. Automatic rebuilding of the documentation will likely fail frequently, because of errors in the tex input. OTOH, if somebody volunteers to produce the documentation automatically somewhere in the world (and fixes errors found during the rebuild), then it would be easy to mirror those on python.org. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 From noreply@sourceforge.net Tue Jul 2 20:13:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 12:13:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-575229 ] multiple inheritance w/ slots dumps core Message-ID: Bugs item #575229, was opened at 2002-06-28 19:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575229&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Cesar Douady (douady) Assigned to: Nobody/Anonymous (nobody) Summary: multiple inheritance w/ slots dumps core Initial Comment: The following script dumps a core (revision 2.2.1) : class A(object): __slots__=() class B(object): pass class C(A,B) : __slots__=() C().x=2 basic sizes for those classes are: A => 8 (correct : no dict, no weakref) B => 16 (correct : dict and weakref slots added) C => 8 (incorrect : dict and weakref not inherited from B) in the last lines of type_new, variables add_dict and add_weak are exploited to add those slots, but only when slots==NULL. The best base selected for C is A, which is correct in my opinion since slots come from it, but dict and weak refs must be treated specially and can come from another base. I have seen nothing in the cvs repository which may fix this bug. I did not submit a patch since this is a touchy part of the interpreter, but I may do it upon request. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-02 15:13 Message: Logged In: YES user_id=33168 I could not replicate this problem from current CVS nor from 2.2.1+ (cvs). Can you test with the CVS versions to see if you still have a problem? for 2.2.1+ the tag is release22-maint ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575229&group_id=5470 From noreply@sourceforge.net Tue Jul 2 20:39:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 12:39:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows) Message-ID: Bugs item #216289, was opened at 2000-10-06 22:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: Later Priority: 3 Submitted By: Tim Peters (tim_one) >Assigned to: Fredrik Lundh (effbot) Summary: Programs using Tkinter sometimes can't shut down (Windows) Initial Comment: The following msg from the Tutor list is about 1.6, but I noticed the same thing several times today using 2.0b2+CVS. In my case, I was running IDLE via python ../tool/idle/idle.pyw from a DOS box in my PCbuild directory. Win98SE. *Most* of the time, shutting down IDLE via Ctrl+Q left the DOS box hanging. As with the poster, the only way to regain control was to use the Task Manager to kill off Winoldap. -----Original Message----- From: Joseph Stubenrauch Sent: Friday, October 06, 2000 9:23 PM To: tutor@python.org Subject: Re: [Tutor] Python 1.6 BUG Strange, I have been experiencing the same bug myself. Here's the low down for me: Python 1.6 with win95 I am running a little Tkinter program The command line I use is simply: "python foo.py" About 25-35% of the time, when I close the Tkinter window, DOS seems to "freeze" and never returns to the c:\ command prompt. I have to ctrl-alt-delete repeatedly and shut down "winoldapp" to get rid of the window and then shell back into DOS and keep working. It's a bit of a pain, since I have the habit of testing EVERYTHING in tiny little stages, so I change one little thing, test it ... freeze ... ARGH! Change one more tiny thing, test it ... freeze ... ARGH! However, sometimes it seems to behave and doesn't bother me for an entire several hour session of python work. That's my report on the problem. Cheers, Joe ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-07-02 15:39 Message: Logged In: YES user_id=31435 Jeff, a long time ago Fredrik Lundh said he was able to reproduce this with a short wish script (no Python, no Tkinter, just Tcl/Tk + wish). I'm reassigning this to /F in the hopes he'll remember how. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-07-02 14:55 Message: Logged In: YES user_id=72656 I appreciate that many others see this is a problem in embedding Tcl, but without any clear way to reproduce this in Tcl/Tk itself, it's very hard for me to fix it. I don't think that there is anything done in 8.4 to fix this that I recall, but if someone finds that the problem "goes away" with 8.4, please report that. For those of course that experience this with python, the simple and "correct" work-around is to launch with pythonw.exe instead of python.exe. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-26 13:40 Message: Logged In: NO According to http://tcl.activestate.com ActiveTcl 8.4.0 is now available for download. It is new as of June 24. I don't know whether this will solve our problems or not, but it's worth looking into. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-19 09:36 Message: Logged In: NO I just downloaded Ruby 1.6.6 for Windows, which also uses Tcl/Tk 8.3 and I experience exactly the same problem there. So this is definitely a Tcl problem (but we know that already). ---------------------------------------------------------------------- Comment By: John Popplewell (johnnypops) Date: 2002-06-07 15:01 Message: Logged In: YES user_id=143340 Hmmm. I run a Python Tcl/Tk application several times every day - the very application that prompted my bug-hunt. I do use "pythonw.exe" to launch it, but it used to hang almost as badly as "python.exe". Whilst developing this app I used "python.exe" and experienced no hang-ups. The Tcl guys point out that this bug is only one of several possible causes of the hang-up, maybe you are just out of luck. The patch has fixed the problem on three Win98 machines, all of which exhibited the problem before updating the DLLs. One thought - are you sure there weren't multiple copies of the tcl83.dll and tk83.dll files? My (only) copies were in "D:\python20\DLLs" good luck, John. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-06-03 14:55 Message: Logged In: YES user_id=72656 providing Tim with a fixed DLL exactly according to John Popplewell's patch did not fix the problem for him. That makes it seem fishy that John really didn't see the problem any more. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-06-03 12:59 Message: Logged In: YES user_id=31435 I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from Tcl/Tk 8.3.2) with newer matched sets from A) PythonWare's py21 distribution (Tcl/Tk 8.3.3). and again from B) ActiveState's Tcl/Tk 8.3.4. All the symptoms originally reported here persisted on Win98SE despite that. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-22 09:57 Message: Logged In: NO I am new to Python and encountered this bug on my very first Tkinter application. It persists in Python 2.2.1 under Windows Me. Needless to say, it makes a bad first impression. Basically, this thread says that Tkinter has been broken for a year and a half on a popular platform at a time when Python is trying to expand its user base. Hopefully, this bug will be corrected soon. If Tcl/Tk 8.4 is not released shortly you might try repackaging Tkinter for Win32 with an earlier version of Tcl/Tk, such as 8.0, that doesn't encounter this problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-22 22:36 Message: Logged In: YES user_id=6380 The proper action is to wait until Tcl 8.3.5 is released, and then shaming someone else in providing you with a set of Windowsbinaries for Tcl. You may also ask Hobbs if there's a Windows project file to build Tcl/Tk for Windows. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-03-11 21:31 Message: Logged In: YES user_id=72656 I did end up back-porting this to the 8.3.4+ Tcl CVS on 2002-02-25, which means it will be in an eventual 8.3.5. It is already in the release 8.4 alpha series. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-09 20:50 Message: Logged In: YES user_id=31435 Back to Guido: Do you think you know what the proper action is? (You said that's why you reopened it, and there's been no new info here since then.) ---------------------------------------------------------------------- Comment By: John Popplewell (johnnypops) Date: 2002-02-25 19:55 Message: Logged In: YES user_id=143340 I knew I wasn't getting to the heart of it .... Almost a one-liner! It has been seriously spoiling my (otherwise crash free) Python experience on Win9x - hope it gets fixed soon. cheers, John. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-25 18:39 Message: Logged In: YES user_id=6380 Reopened until we know what the proper action is. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-02-25 18:32 Message: Logged In: YES user_id=72656 This is mostly correct, and is fixed in the 8.4 Tcl sources already (I guess we can backport this). This was mentioned in SF Tcl bug (account for chopped URL): https://sourceforge.net/tracker/? func=detail&aid=217982&group_id=10894&atid=110894 and the code comment is: /* * Only finalize the notifier if a notifier was installed in the * current thread; there is a route in which this is not * guaranteed to be true (when tclWin32Dll.c:DllMain() is called * with the flag DLL_PROCESS_DETACH by the OS, which could be * doing so from a thread that's never previously been involved * with Tcl, e.g. the task manager) so this check is important. * * Fixes Bug #217982 reported by Hugh Vu and Gene Leache. */ if (tsdPtr == NULL) { return; } ---------------------------------------------------------------------- Comment By: John Popplewell (johnnypops) Date: 2002-02-25 17:41 Message: Logged In: YES user_id=143340 This one has been torturing me for a while. Managed to track it down to a problem inside Tcl. For the Tcl8.3.4 source distribution the problem is in the file win/tclWinNotify.c void Tcl_FinalizeNotifier(ClientData clientData) { ThreadSpecificData *tsdPtr = (ThreadSpecificData *) clientData; /* sometimes called with tsdPtr == NULL */ if ( tsdPtr != NULL ) { DeleteCriticalSection(&tsdPtr->crit); CloseHandle(tsdPtr->event); /* * Clean up the timer and messaging * window for this thread. */ if (tsdPtr->hwnd) { KillTimer(tsdPtr->hwnd, INTERVAL_TIMER); DestroyWindow(tsdPtr->hwnd); } } /* * If this is the last thread to use the notifier, * unregister the notifier window class. */ Tcl_MutexLock(¬ifierMutex); if ( notifierCount && !--notifierCount ) { UnregisterClassA( "TclNotifier", TclWinGetTclInstance()); } Tcl_MutexUnlock(¬ifierMutex); } This bodge doesn't address the underlying problem but has stopped me from tearing all my hair out, cheers, John Popplewell. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-24 18:27 Message: Logged In: YES user_id=31435 FYI, you don't need an IDE to do this -- in Win9x, hit Ctrl+Alt+Del and kill the process directly. A saner solution is to develop under Win2K, which doesn't appear to suffer this problem (the only reports I've seen, and experienced myself, came from Win9x boxes). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-24 04:52 Message: Logged In: NO For those who are still trapped in this bug's hell, I will gladly share the one thing that saved my sanity: WingIDE's 'Kill' command will shut down the program with apparent 100% certainty and no fear of lockups. WingIDE has its own issues, so its not a perfect solution, but if you are like me and Joe (above) who test in small iterations, then using 'Kill' to quit out of your app while testing is a workaround that may preserve your sanity. Perhaps the python gods and the Wing guys can get together and tell us how to replicate 'kill' into our code. For now, I'll use WingIDE to edit, and pythonw.exe for my final client's delivery. ---------------------------------------------------------------------- Comment By: Howard Lightstone (hlightstone) Date: 2001-09-05 13:43 Message: Logged In: YES user_id=66570 I sometimes get bunches of these.... A tool I use (Taskinfo2000) reports that (after killing winoldap): python.exe is blocked on a mutex named OLESCELOCKMUTEX. The reported state is "Console Terminating". There appears to be only one (os) thread running. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-02 16:06 Message: Logged In: YES user_id=31435 No sign of progress on this presumed Tk/Tcl Windows bug in over 3 months, so closing it for lack of hope. ---------------------------------------------------------------------- Comment By: Doug Henderson (djhender) Date: 2001-02-06 00:13 Message: This was a symptom I saw while tracking down the essence of the problem reported in #131207. Using Win98SE, I would get an error dialog (GPF?) in the Kernel, and sometimes the dos prompt would not come back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-12-12 21:00 Message: Just reproduced w/ current CVS, but didn't hang until the 8th try. http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest released version; don't know whether that URL still makes sense, though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-12 15:58 Message: Tim, can you still reproduce this with the current CVS version? There's been one critical patch to _tkinter since the 2.0 release. An alternative would be to try with a newer version of Tcl (isn't 8.4 out already?). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-10-15 12:47 Message: Same as I've reported earlier; it hangs in the call to Tcl_Finalize (which is called by the DLL finalization code). It's less likely to hang if I call Tcl_Finalize from the _tkinter DLL (from user code). Note that the problem isn't really Python-related -- I have stand-alone samples (based on wish) that hangs in the same way. More later. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-13 10:40 Message: Back to Tim since I have no clue what to do here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-12 13:25 Message: The recent fix to _tkinter (Tcl_GetStringResult(interp) instead of interp->result) didn't fix this either. As Tim has remarked in private but not yet recorded here, a workaround is to use pythonw instead of python, so I'm lowering thepriority again. Also note that the hanging process that Tim writes about apparently prevents Win98 from shutting down properly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-10-07 03:37 Message: More info (none good, but some worse so boosted priority): + Happens under release and debug builds. + Have not been able to provoke when starting in the debugger. + Ctrl+Alt+Del and killing Winoldap is not enough to clean everything up. There's still a Python (or Python_d) process hanging around that Ctrl+Alt+Del doesn't show. + This process makes it impossible to delete the associated Python .dll, and in particular makes it impossible to rebuild Python successfully without a reboot. + These processes cannot be killed! Wintop and Process Viewer both fail to get the job done. PrcView (a freeware process viewer) itself locks up if I try to kill them using it. Process Viewer freezes for several seconds before giving up. + Attempting to attach to the process with the MSVC debugger (in order to find out what the heck it's doing) finds the process OK, but then yields the cryptic and undocumented error msg "Cannot execute program". + The processes are not accumulating cycles. + Smells like deadlock. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470 From noreply@sourceforge.net Tue Jul 2 21:25:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 13:25:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-453208 ] 64-bit zip problems Message-ID: Bugs item #453208, was opened at 2001-08-20 01:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453208&group_id=5470 Category: None Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: 64-bit zip problems Initial Comment: This is from c.l.py. There's not enough info (e.g., which OS, which compiler, which Python), but in case anyone is wondering what to do with their IA64 box ... From: John Wiegley Sent: Thursday, August 16, 2001 6:14 PM To: python-list@python.org Subject: Problem with zipfile between 32-bit and 64-bit Using the test script below, run it once on an Intel 32-bit platform. This produces test.zip, which extracts hello.py. Then take the test script and test.zip to an ia64 platform, and run it again. The file it extracts has 0 bytes. I've run into other problems between ia32 and ia64, such as bad checksums, and was wondering if anyone knew anything about this? Thanks, John Wiegley ----[ file: ziptest.py ]------------------------------- --------------- import os import zipfile import string if not os.path.exists('test.zip'): zip = zipfile.ZipFile('test.zip', 'w') zip.write('ziptest.py', 'hello.py') zip.close() zip = zipfile.ZipFile('test.zip', 'r') if hasattr(zip, 'namelist'): files = zip.namelist() else: files = zip.listdir() for file in files: file = apply(os.path.join, string.split (file, '\')) data = open(file, 'wb') print "unarchiving", file data.write(zip.read(file)) data.close() ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-07-02 16:25 Message: Logged In: YES user_id=31435 Could someone try this again? binascii.crc32() returned different results on some 64-bit boxes than on 32-bit boxes, and that's been fixed. See ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-04 16:39 Message: Logged In: YES user_id=31435 Should they really be 64 bits on a 64-bit box? Looks like zipfile.py is using a standard (as opposed to native) pack format, in order to ensure platform-independent layout. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-04 15:51 Message: Logged In: YES user_id=11375 The zlib module seems to use struct.pack('l') for packing some values, which should be 64-bits on a 64-bit platform. Maybe that's the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453208&group_id=5470 From noreply@sourceforge.net Tue Jul 2 21:38:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 13:38:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-574742 ] Missing docs for module textwrap Message-ID: Bugs item #574742, was opened at 2002-06-27 15:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574742&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Missing docs for module textwrap Initial Comment: The textwrap module is not documented in the Python Library Reference. Please write & check-in the documentation as Doc/lib/libtextwrap.tex. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 16:38 Message: Logged In: YES user_id=3066 Fixed the problem with long argument lists in the typeset documentation in Doc/texinputs/python.sty 1.96. Fixed the other XXX comment and made the markup more consistent in Doc/lib/libtextwrap.tex 1.2. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2002-06-28 22:43 Message: Logged In: YES user_id=14422 Assigning to Fred because of my LaTeX questions. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2002-06-28 22:42 Message: Logged In: YES user_id=14422 Done. I'm not completely happy with the LaTeX source, as explained by my two XXX comments in lib/libtextwrap.tex: % XXX how to typeset long argument lists? this just spills off % the edge of the page, with or without \ delimiters [...] % XXX how to typeset the empty string? this looks awful, and "" is worse. Fred, can you either tell me how to fix these or fix them yourself? I'll leave this bug open until these small problems are resolved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574742&group_id=5470 From noreply@sourceforge.net Tue Jul 2 21:45:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 13:45:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-576593 ] pyport.h INFINITY and HUGE_VAL treatment Message-ID: Bugs item #576593, was opened at 2002-07-02 22:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576593&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Tim Peters (tim_one) Summary: pyport.h INFINITY and HUGE_VAL treatment Initial Comment: pyport.h prefers to use INFINITY over HUGE_VAL, if it is available. However, for a future version of Mac OS X math.h may include both constants, but with INFINITY being a value (1e50) that will be represented as IEEE Infinity if stuffed into a float, while HUGE_VAL has the same role for a double (1e500). The path supplied is a simple hack to undefine INFINITY for the Apple gcc compiler (which, to my knowledge, has always had a correct value for HUGE_VAL), but discussion on python-dev hinted that it may be better to get rid of all references to INFINITY here altogether, and in stead use a configure-based define of Py_HUGE_VAL in pyconfig.h on platforms where HUGE_VAL is broken. I agree with this, as long as I don't have to write the configure mods:-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576593&group_id=5470 From noreply@sourceforge.net Tue Jul 2 21:48:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 13:48:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-559117 ] HTTPSConnection memory leakage Message-ID: Bugs item #559117, was opened at 2002-05-22 11:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=559117&group_id=5470 Category: Python Library Group: Python 2.1.2 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Paolo Andreetto (pandreetto) Assigned to: Jeremy Hylton (jhylton) Summary: HTTPSConnection memory leakage Initial Comment: I've tried this test script: import time,httplib,gc gc.set_debug(gc.DEBUG_STATS) while 1: conn=httplib.HTTPSConnection('') conn.connect() conn.request('GET', '/index.html') res=conn.getresponse() conn.close() time.sleep(1) print gc.collect() and I've seen that a memory leakage occurs. The process requires 4Kbytes every 10 seconds. The output of garbage collector shows that at the end of each cycle a new object is contained into last generation. I've tried also to remove from the script both the conn.request and the conn.getresponse but nothing has changed; perhaps the problem is in the connect() method. All tests run on linux (debian distribution, sid version for i386) with kernel 2.4.18 and python 2.1.3. The web server is apache with mod-ssl on redhat 7.2. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-07-02 20:48 Message: Logged In: YES user_id=31392 Fixed on 2.1 maintenace branch. It's there if we ever do a 2.1.4 release. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-27 03:55 Message: Logged In: YES user_id=31392 Some of the SSL fixes should back reported to 2.1, if we ever to a 2.1.4 release. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 15:25 Message: Logged In: YES user_id=31392 Several leaks were fixed just before Python 2.2b1. It looks like those changes were not backported to the 2.1 maintenance branch. I don't have time to backport the changes, but I'd be happy to review a patch. Since the problem wouldn't get fix until a (hypothetical) 2.1.4, you might get more mileage out of an upgrade to 2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=559117&group_id=5470 From noreply@sourceforge.net Tue Jul 2 21:50:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 13:50:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-225744 ] httplib does not check if port is valid (easy to fix?) Message-ID: Bugs item #225744, was opened at 2000-12-14 04:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=225744&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Luca de Alfaro (dealfaro) Assigned to: Jeremy Hylton (jhylton) Summary: httplib does not check if port is valid (easy to fix?) Initial Comment: In httplib.py, line 336, the following code appears: def _set_hostport(self, host, port): if port is None: i = string.find(host, ':') if i >= 0: port = int(host[i+1:]) host = host[:i] else: port = self.default_port self.host = host self.port = port Ths code breaks if the host string ends with ":", so that int("") is called. In the old (1.5.2) version of this module, the corresponding int () conversion used to be enclosed in a try/except pair: try: port = string.atoi(port) except string.atoi_error: raise socket.error, "nonnumeric port" and this fixed the problem. Note BTW that now the error reported by int is "ValueError: invalid literal for int():" rather than the above string.atoi_error. I found this problem while downloading web pages, but unfortunately I cannot pinpoint which page caused the problem. Luca de Alfaro ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-07-02 20:50 Message: Logged In: YES user_id=31392 Skip's change was checked in a while ago. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-09 14:30 Message: Logged In: YES user_id=44345 Here's a suggested patch that matches the exception structure used by httplib. It adds a subclass of HTTPException called InvalidURL and raises that when int(port) gets incorrect input. ---------------------------------------------------------------------- Comment By: MartinThomas (martinthomas) Date: 2001-01-10 21:19 Message: I have been trying to pin down a problem in Redhat's Update agent which is written in Python (..mostly) which happens when a proxy is specified. In RH7.0, they are still using Python 1.5.2 and the message 'nonnumeric port' is received when a proxy is specified in the following form: http://proxy.yourdomain.com:80 but the following: proxy.yourdomain.com:80 works.. looking at the code, it seems that it expects that the only colon would be near the end of the url and makes no allowance for 'http:' nor 'https:'... Regards / Martin ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-18 22:38 Message: Thanks for explaining this more. I am surprised that a 301 redirect would give an invalid port -- but surely webmasters aren't perfect. :-) The argument that urllib.Urlopener.open() checks for socket.error but not for other errors is a good one. However I don't see the httplib.py code raising socket.error elsewhere. I'll ask Jeremy. The rest of the module seems to be using a totally different set of exceptions. On the other hand, it *can* raise socket.error, implicitly (when various socket calls are being made). ---------------------------------------------------------------------- Comment By: Luca de Alfaro (dealfaro) Date: 2000-12-18 22:25 Message: There are three (minor?) problems with raising ValueError. 1) Compatibility. I had some code for 1.5.2 that was trying to load web pages checking for various errors, and it was expecting this error to cause a socket error, not a value error. 2) Accuracy. ValueError can be caused by anything. The 'non-numeric port' error is much more informative. I don't want to catch ValueError, because it can be caused in too many situations. I also cannot check myself that the port is fine, because the port and the URL are often given by a redirect (errors 301 and 302, if I remember correctly). This in fact was the situation that caused the problem. Hence, my only real solution was to patch my version of httplib. 3) Style. I am somewhat new to Python, but I was under the impression that, stilistically, a ValueError was used to convey a situation that was the fault of the programmer, while other more specific errors were used for unexpected situations (communication, etc). Since the socket is the result of a URL redirection (errors 301 or 302), the programmer is not in a position to prevent this error by "better checking". Hence, I would consider a network-relted exception to be more appropriate here. But who am I to argue with the creator of Python? ;-) Luca ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-14 14:37 Message: The only effect is that it raises ValueError instead of socket.error. Where is this a problem? (Note that string.atoi_error is an alias for ValueError.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=225744&group_id=5470 From noreply@sourceforge.net Tue Jul 2 22:06:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 14:06:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-574773 ] removedirs() is not a recursive function Message-ID: Bugs item #574773, was opened at 2002-06-27 16:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574773&group_id=5470 Category: Documentation >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Dani (asqui) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: removedirs() is not a recursive function Initial Comment: The _Python Library Reference_, section 6.1.4: os: Files and Directories_ lists the following definition of os.removedirs(): removedirs(path) Recursive directory removal function. Works like rmdir() except that, if the leaf directory is successfully removed, directories corresponding to rightmost path segments will be pruned way until either the whole path is consumed or an error is raised (which is ignored, because it generally means that a parent directory is not empty). Throws an error exception if the leaf directory could not be successfully removed. New in version 1.5.2. >From what I can see there is nothing recursive about os.removedirs(), just simple iteration. This is misleading because it suggests something like removedirs('foo/bar/') will remove 'foo/bar/' and all its subdirectories, providing they are empty. When in fact what it does is remove directory foo/bar/ if it is empty, then remove foo/ if it is empty. (I'm fairly new to python so I could be mistaken, but I checked with peers on IRC who instructed me to submit a bug report.) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 17:06 Message: Logged In: YES user_id=3066 The documentation is trying to state that removedirs() is removing directories in a recursive manner, not that the implementation is recursive (which is completely irrelevant to the documentation). I've attempted to clarify the docs (Doc/lib/libos.tex 1.91), but removedirs() is just a really weird function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574773&group_id=5470 From noreply@sourceforge.net Tue Jul 2 22:12:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 14:12:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-563338 ] Getting traceback in embedded python. Message-ID: Bugs item #563338, was opened at 2002-06-01 12:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=563338&group_id=5470 Category: Documentation >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Getting traceback in embedded python. Initial Comment: It would be nice if there was an API method for getting the traceback as a string for use in embedded Python applications. Since I couldn't find any such function I created the following, maybe it could be added to the embedding docs? class PyException : public std::exception { std::string msg; public: PyException(const std::string& m) : msg(m) {} const char* what() { return msg.c_str(); } }; std::string getTraceback() { std::string result; PyObject *exception, *v, *traceback; PyErr_Fetch(&exception, &v, &traceback); PyErr_NormalizeException(&exception, &v, &traceback); /* import traceback lst = traceback.format_exception(exception, v, traceback) */ PyObject* tbstr = PyString_FromString("traceback"); PyObject* tbmod = PyImport_Import(tbstr); if (!tbmod) throw PyException("Unable to import traceback module. Is your Python installed?"); PyObject* tbdict = PyModule_GetDict(tbmod); PyObject* formatFunc = PyDict_GetItemString (tbdict, "format_exception"); if (!formatFunc) throw PyException("Can't find traceback.format_exception"); if (!traceback) { traceback = Py_None; Py_INCREF(Py_None); } PyObject* args = Py_BuildValue("(OOO)", exception, v, traceback); PyObject* lst = PyObject_CallObject(formatFunc, args); for (int i=0; iComment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 17:12 Message: Logged In: YES user_id=3066 Agreed with suggestion that we reject this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 15:40 Message: Logged In: YES user_id=6380 I suggest that we reject this reques, but I'll let Fred do that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 09:09 Message: Logged In: YES user_id=21627 Another approach is to use PyTraceBack_Print, passing a file-like object of your choice (e.g. a cStringIO object). I don't think this belongs into the embedding tutorial - anybody who understands the API can derive code similar to yours just from the equivalent Python code. Instead, I recommend that you add your snippet into the Python Cookbook, at http://aspn.activestate.com/ASPN/Python/Cookbook/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 09:09 Message: Logged In: YES user_id=21627 Another approach is to use PyTraceBack_Print, passing a file-like object of your choice (e.g. a cStringIO object). I don't think this belongs into the embedding tutorial - anybody who understands the API can derive code similar to yours just from the equivalent Python code. Instead, I recommend that you add your snippet into the Python Cookbook, at http://aspn.activestate.com/ASPN/Python/Cookbook/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=563338&group_id=5470 From noreply@sourceforge.net Tue Jul 2 23:35:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 15:35:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-558278 ] unittest.TestResult documentation Message-ID: Bugs item #558278, was opened at 2002-05-20 09:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=558278&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stéphane Bidoul (sbidoul) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: unittest.TestResult documentation Initial Comment: The documentation of unittest.TestResult states: TestResult instances have the following attributes that will be of interest when inspecting the results of running a set of tests: errors A list containing pairs of TestCase instances and the sys.exc_info() results for tests which raised an exception but did not signal a test failure. failures A list containing pairs of TestCase instances and the sys.exc_info() results for tests which signalled a failure in the code under test. unittest.py (version 1.14) has, in the docstring of TestResult: Each instance holds the total number of tests run, and collections of failures and errors that occurred among those test runs. The collections contain tuples of (testcase, exceptioninfo), where exceptioninfo is the *formatted* traceback of the error that occurred. So the second parts of the errors and failures lists of pairs are actually strings and not sys.exc_info() tuples. The docstring in the code looks correct to me, so I guess the documentation needs to be fixed. Note that this behaviour changed between python 2.1 and python 2.2. As a side note, I noticed the problem because I had a custom test runner that exploited the traceback information to customize the display of results based on the actual failureException subclass. I overcame that by maintaining my own errors and failure lists in a subclass of TestResult. Now, I've read the rationale for keeping only formatted tracebacks, but this kind of use of the traceback for customized result display looked useful to me. May be there is a better way? Regards. -Stephane ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 18:35 Message: Logged In: YES user_id=3066 Fixed the documentation in Doc/lib/libunittest.tex (revisions 1.8 and 1.7.8.1), and added a brief example of how to create an extended TestResult object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=558278&group_id=5470 From noreply@sourceforge.net Wed Jul 3 00:43:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 16:43:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-563338 ] Getting traceback in embedded python. Message-ID: Bugs item #563338, was opened at 2002-06-02 02:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=563338&group_id=5470 Category: Documentation Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Getting traceback in embedded python. Initial Comment: It would be nice if there was an API method for getting the traceback as a string for use in embedded Python applications. Since I couldn't find any such function I created the following, maybe it could be added to the embedding docs? class PyException : public std::exception { std::string msg; public: PyException(const std::string& m) : msg(m) {} const char* what() { return msg.c_str(); } }; std::string getTraceback() { std::string result; PyObject *exception, *v, *traceback; PyErr_Fetch(&exception, &v, &traceback); PyErr_NormalizeException(&exception, &v, &traceback); /* import traceback lst = traceback.format_exception(exception, v, traceback) */ PyObject* tbstr = PyString_FromString("traceback"); PyObject* tbmod = PyImport_Import(tbstr); if (!tbmod) throw PyException("Unable to import traceback module. Is your Python installed?"); PyObject* tbdict = PyModule_GetDict(tbmod); PyObject* formatFunc = PyDict_GetItemString (tbdict, "format_exception"); if (!formatFunc) throw PyException("Can't find traceback.format_exception"); if (!traceback) { traceback = Py_None; Py_INCREF(Py_None); } PyObject* args = Py_BuildValue("(OOO)", exception, v, traceback); PyObject* lst = PyObject_CallObject(formatFunc, args); for (int i=0; iComment By: Mark Hammond (mhammond) Date: 2002-07-03 09:43 Message: Logged In: YES user_id=14198 For the sake of completeness, I am attaching some pure C code that does something similar. The code is longer as it uses CStringIO to extract the final traceback string. The key advantage is that it is pure C so could be included in Python itself. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-03 07:12 Message: Logged In: YES user_id=3066 Agreed with suggestion that we reject this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-06 05:40 Message: Logged In: YES user_id=6380 I suggest that we reject this reques, but I'll let Fred do that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 23:09 Message: Logged In: YES user_id=21627 Another approach is to use PyTraceBack_Print, passing a file-like object of your choice (e.g. a cStringIO object). I don't think this belongs into the embedding tutorial - anybody who understands the API can derive code similar to yours just from the equivalent Python code. Instead, I recommend that you add your snippet into the Python Cookbook, at http://aspn.activestate.com/ASPN/Python/Cookbook/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 23:09 Message: Logged In: YES user_id=21627 Another approach is to use PyTraceBack_Print, passing a file-like object of your choice (e.g. a cStringIO object). I don't think this belongs into the embedding tutorial - anybody who understands the API can derive code similar to yours just from the equivalent Python code. Instead, I recommend that you add your snippet into the Python Cookbook, at http://aspn.activestate.com/ASPN/Python/Cookbook/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=563338&group_id=5470 From noreply@sourceforge.net Wed Jul 3 03:10:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 19:10:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-576711 ] Windows binary missing SSL Message-ID: Bugs item #576711, was opened at 2002-07-03 02:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Dave Schuyler (parameter) Assigned to: Tim Peters (tim_one) Summary: Windows binary missing SSL Initial Comment: The Windows binary build from www.python.org appears to be missing SSL support (-DUSE_SSL ?). Please consider including SSL/HTTPS support "out of the box" for Windows users. Here's an example of what I tried (although I changed the server name): Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import httplib >>> conn=httplib.HTTPSConnection ("some.secure.server.com") >>> conn.request("GET", "/index.php") Traceback (most recent call last): File "", line 1, in ? conn.request("GET", "/index.php") File "C:\Python22\lib\httplib.py", line 537, in request self._send_request(method, url, body, headers) File "C:\Python22\lib\httplib.py", line 553, in _send_request self.putrequest(method, url) File "C:\Python22\lib\httplib.py", line 453, in putrequest self.send(str) File "C:\Python22\lib\httplib.py", line 395, in send self.connect() File "C:\Python22\lib\httplib.py", line 688, in connect ssl = socket.ssl(realsock, self.key_file, self.cert_file) AttributeError: 'module' object has no attribute 'ssl' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 From noreply@sourceforge.net Wed Jul 3 03:53:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 19:53:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-574570 ] Freeze on Windows missing recent changes Message-ID: Bugs item #574570, was opened at 2002-06-27 23:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574570&group_id=5470 Category: Demos and Tools Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Lawrence Hudson (lhudson) Assigned to: Mark Hammond (mhammond) Summary: Freeze on Windows missing recent changes Initial Comment: Freeze still references zlib 1.1.3 and does not yet know about _winreg. Patches #574531 and #574532 for contain fixes. Are we the only people using this tool on Windows?? ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-07-03 12:53 Message: Logged In: YES user_id=14198 Both patches checked in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-06-28 11:15 Message: Logged In: YES user_id=14198 Patch 574531 was just checked in. 574532 appears to contain no patch. I will close this report when the missing patch is uploaded. Thanks! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-06-28 06:04 Message: Logged In: YES user_id=31435 AFAIK, freeze is never tested on Windows as part of the PythonLabs release process. Meaning it's certainly not tested by anyone in PythonLabs, and I have no reason to suspect it's tested by anyone else either. Indeed. the PL Windows distro doesn't even include freeze, and it was a surprise to me that you use it . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574570&group_id=5470 From noreply@sourceforge.net Wed Jul 3 03:50:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 19:50:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-576711 ] Windows binary missing SSL Message-ID: Bugs item #576711, was opened at 2002-07-02 22:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Dave Schuyler (parameter) >Assigned to: Mark Hammond (mhammond) Summary: Windows binary missing SSL Initial Comment: The Windows binary build from www.python.org appears to be missing SSL support (-DUSE_SSL ?). Please consider including SSL/HTTPS support "out of the box" for Windows users. Here's an example of what I tried (although I changed the server name): Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import httplib >>> conn=httplib.HTTPSConnection ("some.secure.server.com") >>> conn.request("GET", "/index.php") Traceback (most recent call last): File "", line 1, in ? conn.request("GET", "/index.php") File "C:\Python22\lib\httplib.py", line 537, in request self._send_request(method, url, body, headers) File "C:\Python22\lib\httplib.py", line 553, in _send_request self.putrequest(method, url) File "C:\Python22\lib\httplib.py", line 453, in putrequest self.send(str) File "C:\Python22\lib\httplib.py", line 395, in send self.connect() File "C:\Python22\lib\httplib.py", line 688, in connect ssl = socket.ssl(realsock, self.key_file, self.cert_file) AttributeError: 'module' object has no attribute 'ssl' ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-07-02 22:50 Message: Logged In: YES user_id=31435 Mark, does this interest you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 From noreply@sourceforge.net Wed Jul 3 04:32:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 20:32:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-576593 ] pyport.h INFINITY and HUGE_VAL treatment Message-ID: Bugs item #576593, was opened at 2002-07-02 16:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576593&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Tim Peters (tim_one) Summary: pyport.h INFINITY and HUGE_VAL treatment Initial Comment: pyport.h prefers to use INFINITY over HUGE_VAL, if it is available. However, for a future version of Mac OS X math.h may include both constants, but with INFINITY being a value (1e50) that will be represented as IEEE Infinity if stuffed into a float, while HUGE_VAL has the same role for a double (1e500). The path supplied is a simple hack to undefine INFINITY for the Apple gcc compiler (which, to my knowledge, has always had a correct value for HUGE_VAL), but discussion on python-dev hinted that it may be better to get rid of all references to INFINITY here altogether, and in stead use a configure-based define of Py_HUGE_VAL in pyconfig.h on platforms where HUGE_VAL is broken. I agree with this, as long as I don't have to write the configure mods:-) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-07-02 23:32 Message: Logged In: YES user_id=31435 I instead checked in the threatened change to get rid of the INFINITY hack altogether. That was there specifically to support some unknown subset of Cray boxes, which don't conform to the C standard. People on those platforms (if there are any anymore ...) will have to fix this with some Cray-specific config hack. I'll reject any patch that tries to make this the core's problem again (as you discovered, all that does in the end is create other problems on other boxes -- but do note that Jaguar has a non-conforming definition for INFINITY). Include/pyport.h; new revision: 2.51 Misc/NEWS; new revision: 1.436 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576593&group_id=5470 From noreply@sourceforge.net Wed Jul 3 05:08:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 21:08:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-545096 ] ConfigParser code cleanup Message-ID: Bugs item #545096, was opened at 2002-04-17 06:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=545096&group_id=5470 Category: Python Library Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser code cleanup Initial Comment: The first patch fixes a bug, implements some speed improvements, some memory consumption improvements, enforces the usage of the already available global variables, and extends the allowed chars in option names to be very permissive. The second one, if used, is supposed to be applied over the first one, and implements a walk() generator method for walking trough the options of a section. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-03 00:08 Message: Logged In: YES user_id=3066 Any objections to my renaming "walk" to "items" (or even "section_items")? "walk" makes me think of os.path.walk(), which uses a callback; what the function returns is a list of name-value pairs, though, which makes me think "items". Other than this, I'm ready to commit. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-22 00:09 Message: Logged In: YES user_id=7887 Deal!! ;-) Here is the updated patch. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-21 22:16 Message: Logged In: YES user_id=3066 Thanks! I can take care of the referred bug; I already know how I want to solve that one. Thanks! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-21 22:14 Message: Logged In: YES user_id=7887 Thanks for your review Fred! I'll fix the patch as suggested, and work on a solution for the referred bug as well. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-21 21:38 Message: Logged In: YES user_id=3066 Changed to a "bug" report even though it's a patch, so that all the ConfigParser reports can show up together. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-21 13:22 Message: Logged In: YES user_id=3066 I'd like to accept a variation on this patch. Specifically, I'd like "section in self.sections()" tests to become "sections in self.__sections" consistently; your proposed patch is better than the original, but as long as we're not supporting subclassing in this way, let's go ahead and use the better-performing solution. I'll accept the use of MAX_INTERPOLATION_DEPTH and your changes to the interpolation loop, but the loop itself will probably be re-written later, in response to SF bug #511737. The walk() method will need documentation. Can you prepare a new patch for this? Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-21 12:20 Message: Logged In: YES user_id=3066 Ken appears non-responsive, re-assigning to me. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 21:42 Message: Logged In: YES user_id=3066 Ken, can you recall our thinking on the use of the constant for MAX_INTERPOLATION_DEPTH when this was first written? I think you were more involved in this than the rest of us at the time. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-03 17:45 Message: Logged In: YES user_id=7887 Hello Fred! - About has_section(), I thought about the possibility of subclassing it. But, besides agreeing with you on the messy code matter, other functions weren't (and still aren't) considering this possibility, so I doubt some one will be able to subclass it anyways. Anyway, I may change the patch to use whatever you suggest. - About MAX_INTERPOLATION_DEPTH, I understand your position of wanting "a safety net", but my intention of using it in the code was not to let the user change it, but to clarify and give consistence to the code. I think using literal constants in the code is not a good measure at all. If this was adopted, many modules would have to be changed (in a bad way) for consistence. With a quick look at the library, I was able to find smtpd.py, base64.py, binhex.py, cgi.py, cmd.py, and many others using similar purpose constants. You'll probably agree with me if you think about this more extensively. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 12:11 Message: Logged In: YES user_id=3066 I should clarify: By "retain the use of the constant" I mean the constant numeric literal, not MAX_INTERPOLATION_DEPTH. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 12:06 Message: Logged In: YES user_id=3066 Two comments: - "section in self.__sections.keys()" can be written (still more efficiently) as "section in self.__sections", *but* the use of the sections() method is done to be subclass-friendly. I'm not sure how important this is since I can't imagine anyone actually subclassing from such a mass of messy code. Perhaps these could be modified to use the has_section() method, which is relatively new. - MAX_INTERPOLATION_DEPTH was not "honored" in the code since it's really a safety net; there's no intention that client code be able to change it. (The sanity of the value is not checked before use.) I'm inclined to retain the use of the constant in the interpolation code, and add a comment above the constant the it exists for informational purposes only. Otherwise, I'm fine with the patch. ;-) Sorry for the delay in responding to this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 13:55 Message: Logged In: YES user_id=6380 I'm assigning this to Fred Drake, who has some opinions on ConfigParser. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-04-18 13:07 Message: Logged In: YES user_id=7887 I'd rather explain here the patch that changes behavior, since it's pretty small. This line in the regular expression OPTCRE: r'(?P

403 Forbidden