[ python-Bugs-1626801 ] posixmodule.c leaks crypto context on Windows
Bugs item #1626801, was opened at 2007-01-03 12:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1626801&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yitz Gale (ygale) Assigned to: Nobody/Anonymous (nobody) Summary: posixmodule.c leaks crypto context on Windows Initial Comment: The Win API docs for CryptAcquireContext require that the context be released after use by calling CryptReleaseContext, but posixmodule.c fails to do so in win32_urandom(). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1626801&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1622010 ] Tcl/Tk auto-expanding window
Bugs item #1622010, was opened at 2006-12-25 16:10
Message generated for change (Settings changed) made by fmareyen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622010&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabian_M (fmareyen)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Tcl/Tk auto-expanding window
Initial Comment:
I've experienced an auto-expanding Tcl/Tk-window:
(Windows NT)
import Tkinter
tk = Tkinter.Tk()
tk.state("zoomed") #Windows only
tk.resizable(False, False)
tk.mainloop()
As you take the window by curser and move it slowly to the left, it expands
automatically to the right. This effect doesn't exist vertically.
When you use tk.state("zoomed") you needn't to set tk.resizable, but this call
remained in my programm and caused that problem.
Systeminformation:
--
Windows NT
sys.api_version = 1012 #0x3f4
sys.dllhandle = 503316480 #0x1e
sys.getwindowsversion() -> (4, 0, 1381, 2, "Service Pack 1")
sys.hexversion = 33817328 #0x20402f0
sys.platform = "win32"
sys.version = "2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (I
sys.version_info = (2, 4, 2, 'final', 0)
sys.winver = "2.4"
_tkinter.TCL_VERSION = 8.4
_tkinter.TK_VERSION = 8.4
Thanks.
Fabian Mareyen
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622010&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1626801 ] posixmodule.c leaks crypto context on Windows
Bugs item #1626801, was opened at 2007-01-03 12:47 Message generated for change (Comment added) made by ygale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1626801&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yitz Gale (ygale) Assigned to: Nobody/Anonymous (nobody) Summary: posixmodule.c leaks crypto context on Windows Initial Comment: The Win API docs for CryptAcquireContext require that the context be released after use by calling CryptReleaseContext, but posixmodule.c fails to do so in win32_urandom(). -- >Comment By: Yitz Gale (ygale) Date: 2007-01-03 14:12 Message: Logged In: YES user_id=1033539 Originator: YES You might consider backporting this to 2.5 and 2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1626801&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568240 ] Tix is not included in 2.5 for Windows
Bugs item #1568240, was opened at 2006-09-30 11:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Christos Georgiou (tzot) Assigned to: Martin v. Löwis (loewis) Summary: Tix is not included in 2.5 for Windows Initial Comment: (I hope "Build" is more precise than "Extension Modules" and "Tkinter" for this specific bug.) At least the following files are missing from 2.5 for Windows: DLLs\tix8184.dll tcl\tix8184.lib tcl\tix8.1\* -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-03 15:59 Message: Logged In: YES user_id=21627 Originator: NO Ah, ok. No, assigning this report to Neal or bumping its priority should not be done. -- Comment By: Christos Georgiou (tzot) Date: 2007-01-02 11:22 Message: Logged In: YES user_id=539787 Originator: YES Neal's message is this: http://mail.python.org/pipermail/python-dev/2006-December/070406.html and it refers to the 2.5.1 release, not prior to it. As you see, I refrained from both increasing the priority and assigning it to Neal, and actually just added a comment to the case with a related question, since I know you are the one responsible for the windows build and you already had assigned the bug to you. My adding this comment to the bug was nothing more or less than the action that felt appropriate, and still does feel appropriate to me (ie I didn't overstep any limits). The "we" was just all parties interested, and in this case, the ones I know are at least you (responsible for the windows build) and I (a user of Tix on windows). Happy new year, Martin! -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-29 23:26 Message: Logged In: YES user_id=21627 Originator: NO I haven't read Neal's message yet, but I wonder what he could do about it. I plan to fix this with 2.5.1, there is absolutely no way to fix this earlier. I'm not sure who "we" is who would like to bump the bug, and what precisely this bumping would do; tzot, please refrain from changing the priority to higher than 7. These priorities are reserved to the release manager. -- Comment By: Christos Georgiou (tzot) Date: 2006-12-27 18:46 Message: Logged In: YES user_id=539787 Originator: YES Should we bump the bug up and/or assign it to Neal Norwitz as he requested on Python-Dev? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627036 ] website issue reporter down
Bugs item #1627036, was opened at 2007-01-03 10:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627036&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: website issue reporter down Initial Comment: To request an update for python.org, the procedure seems to be to create a ticket via: http://wiki.python.org/moin/PythonWebsiteCreatingNewTickets which says that self registration is disabled, but sends you to: http://pydotorg.python.org/pydotorg/newticket which says that admin privs are required to create a new ticket. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627036&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627039 ] mention side-lists from python-dev description
Bugs item #1627039, was opened at 2007-01-03 10:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627039&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: mention side-lists from python-dev description Initial Comment: http://www.python.org/community/lists/ describes mailing lists for python, including python-dev. Change: """ Note: python-dev is for work on developing Python (fixing bugs and adding new features to Python itself); if you're having problems writing a Python program, please post to comp.lang.python. """ to """ Note: python-dev is for work on developing Python (fixing bugs and adding new features to Python itself); if you're having problems writing a Python program, please post to comp.lang.python. If you want to discuss larger changes, please use python-ideas instead. http://mail.python.org/mailman/listinfo/python-ideas """ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627039&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1626801 ] posixmodule.c leaks crypto context on Windows
Bugs item #1626801, was opened at 2007-01-03 11:47 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1626801&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.6 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Yitz Gale (ygale) >Assigned to: Martin v. Löwis (loewis) Summary: posixmodule.c leaks crypto context on Windows Initial Comment: The Win API docs for CryptAcquireContext require that the context be released after use by calling CryptReleaseContext, but posixmodule.c fails to do so in win32_urandom(). -- Comment By: Yitz Gale (ygale) Date: 2007-01-03 13:12 Message: Logged In: YES user_id=1033539 Originator: YES You might consider backporting this to 2.5 and 2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1626801&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627096 ] xml.dom.minidom parse bug
Bugs item #1627096, was opened at 2007-01-03 17:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627096&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pierre Imbaud (pmi)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom parse bug
Initial Comment:
xml.dom.minidom was unable to parse an xml file that came from an example
provided by an official organism.(http://www.iptc.org/IPTC4XMP)
The parsed file was somewhat hairy, but I have been able to reproduce the bug
with a simplified
version, attached. (ends with .xmp: its supposed
to be an xmp file, the xmp standard being built on
xml. Well, thats the short story).
The offending part is the one that goes: xmpPLUS=''
it triggers an exception: ValueError: too many values to unpack,
in _parse_ns_name. Some debugging showed an obvious mistake
in the scanning of the name argument, that goes beyond the closing
" ' ".
I digged a little further thru a pdb session, but the bug seems to be located
in c code.
Thats the very first time I report a bug, chances are I provide too much or too
little information...
To whoever it may concern, here is the invoking code:
from xml.dom import minidom
...
class xmp(dict):
def __init__(self, inStream):
xmldoc = minidom.parse(inStream)
x = xmp('/home/pierre/devt/port/IPTCCore-Full/x.xmp')
traceback:
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xmpLib.py in
__init__(self, inStream)
26 def __init__(self, inStream):
27 print minidom
---> 28 xmldoc = minidom.parse(inStream)
29 xmpmeta = xmldoc.childNodes[1]
30 rdf = xmpmeta.childNodes[1]
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/nxml/dom/minidom.py in
parse(file, parser, bufsize)
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in parse(file, namespaces)
922 fp = open(file, 'rb')
923 try:
--> 924 result = builder.parseFile(fp)
925 finally:
926 fp.close()
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in parseFile(self, file)
205 if not buffer:
206 break
--> 207 parser.Parse(buffer, 0)
208 if first_buffer and self.document.documentElement:
209 self._setup_subset(buffer)
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in start_element_handler(self, name, attributes)
743 def start_element_handler(self, name, attributes):
744 if ' ' in name:
--> 745 uri, localname, prefix, qname = _parse_ns_name(self, name)
746 else:
747 uri = EMPTY_NAMESPACE
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in _parse_ns_name(builder, name)
125 localname = intern(localname, localname)
126 else:
--> 127 uri, localname = parts
128 prefix = EMPTY_PREFIX
129 qname = localname = intern(localname, localname)
ValueError: too many values to unpack
The offending c statement:
/usr/src/packages/BUILD/Python-2.4/Modules/pyexpat.c(582)StartElement()
The returned 'name':
(Pdb) name
Out[5]: u'XMP Photographic Licensing Universal System (xmpPLUS,
http://ns.adobe.com/xap/1.0/PLUS/) CreditLineReq xmpPLUS'
Its obvious the scanning went beyond the attribute.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627096&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1619130 ] 64-bit Universal Binary build broken
Bugs item #1619130, was opened at 2006-12-20 00:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Treadway (treadway) Assigned to: Jack Jansen (jackjansen) Summary: 64-bit Universal Binary build broken Initial Comment: Hi, I'm running into problem building a 4-way universal binary of python. The following has cropped up on both python2.5 and python2.4.2 The configure goes OK, but the make bombs. [2244]$ ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \ -Wstrict-prototypes -fno-common -fPIC \ -isysroot /Developer/SDKs/MacOSX10.4u.sdk \ -arch ppc -arch i386 -arch ppc64 -arch x86_64" \ LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\ -headerpad_max_install_names -arch ppc -arch i386 \ -arch ppc64 -arch x86_64" . . . [2245]$ make gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from ./Include/Python.h:57In file included from ./Include/Python.h:57, from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." , from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out make: *** [Modules/python.o] Error 1 Comenting out the "#error" statement in pyport.h get me a little further befor getting: gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Python/mactoolboxglue.o Python/mactoolboxglue.c In file included from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32, from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125, . . . from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20, from ./Include/pymactoolbox.h:10, from Python/mactoolboxglue.c:27: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338: error: 'SIGDIGLEN' undeclared here (not in a function) lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out make: *** [Python/mactoolboxglue.o] Error 1 Seem Carbon doesn't support 64-bits! Is there a solution? trt -- Thomas R. Treadway Computer Scientist Lawrence Livermore Nat'l Lab 7000 East Avenue, L-159 Livermore, CA 94550-0611 -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-03 17:08 Message: Logged In: YES user_id=21627 Originator: NO You are right: four-way universal builds are not supported currently. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3
Bugs item #1519816, was opened at 2006-07-10 04:29
Message generated for change (Comment added) made by lecaros
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 proxy does not work in 2.4.3
Initial Comment:
My python app had to retrieve some web pages and while
our network environment requires proxy it uses urllib2
opener (source is in attachment). It worked very well
on older Python interpreters:
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based
on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310
32 bit (Intel)] on win32
It works on linux with 2.3 and 2.4.1:
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
But it does not work with newest 2.4.3 on Linux:
Python 2.4.3 (#1, Jul 10 2006, 09:57:52)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Desired result:
isof-mark:~# python2.3 proxy_bug.py
trying http://www.python.org ...
OK. We have reply from http://www.python.org.
Size: 13757 [b]
http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd">
http://www.w3.org/
1999/xhtml">
design by pollenation
Copyright Š 1990-2006, Python Software
Foundation
Legal Statements
isof-mark:~# /usr/local/bin/python proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
File "proxy_bug.py", line 37, in ?
get_page()
File "proxy_bug.py", line 27, in get_page
f = urllib2.urlopen(request)
File "/usr/local/lib/python2.4/urllib2.py", line
130, in urlopen
return _opener.open(url, data)
File "/usr/local/lib/python2.4/urllib2.py", line
364, in open
response = meth(req, response)
File "/usr/local/lib/python2.4/urllib2.py", line
471, in http_response
response = self.parent.error(
File "/usr/local/lib/python2.4/urllib2.py", line
402, in error
return self._call_chain(*args)
File "/usr/local/lib/python2.4/urllib2.py", line
337, in _call_chain
result = func(*args)
File "/usr/local/lib/python2.4/urllib2.py", line
480, in http_error_default
raise HTTPError(req.get_full_url(), code, msg,
hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy
Authentication Required
I have raported it on ActiveState bug list (http://
bugs.activestate.com/show_bug.cgi?id=47018) while I
first spot this bug on their destribution but it seems
that bug is in others distributions too.
Regards,
Michal Niklas
--
Comment By: José Lecaros Cisterna (lecaros)
Date: 2007-01-03 13:33
Message:
Logged In: YES
user_id=1410109
Originator: NO
i have the same issue on windows xp, python 2.4.3
but using DOMAIN\username format
--
Comment By: JerryKhan (jerrykhan)
Date: 2006-11-28 12:17
Message:
Logged In: YES
user_id=867168
Originator: NO
Hello,
In my sens in a general manner there is something wrong in the urllib2
http code:
But this may depends on the environment (I am not an expert in urllib)
Here are my tests : using python 2.4.2 on Windows XP
These simple codes failed with a 407 http error :
Example E1:
import urllib2 as URL
a=URL.urlopen("http://lan_apache_url";)
print a.read()
OR example E2:
import urllib2 as URL
r=URL.Request("http://lan_apache_url";)
a=URL.urlopen(r)
print a.read()
But succeed with urllib example E3
import urllib
a=urllib.urlopen("http://lan_apache_url";)
print a.read()
Notice that different code lines are minimal E1 and E3 are close:
Notice also that I'm try to access a lan apache server which is not behind
a Proxy.
And I don't want to access to any Proxy (like exclusion string in
IExplorer)
But I found also that If I try to access to a protected link with HTTPS
... on the LAN, there is not problem. The issue is really on the HTTP
interpreter or during the configuration of the URL opener.
In the same time, some of my programs are able to access to Internet
servers using the current Proxy server without any problem. For that, I
use:
import urllib2 as URL
URL.install_opener(URL.build_opener( s.https_handler,
s.proxy_auth_handler, s.cookie_handler))
Well, I developed a workaround in my programs ... to use urllib instead of
urllib2 in the case where I try to access the LAN (in fact when I don't
want to configure the Proxy server, or when the URL match my own proxy
exclusion list.)
I espect this will help python urllib2 experts to find the issue.
Jérôme Vacher alias jerrykhan the foolish dracomorpheus of the emerald
dragon dynasty.
--
Comment By: Michal Niklas (mniklas)
Date: 2006-07-
[ python-Bugs-1627244 ] xml.dom.minidom parse bug
Bugs item #1627244, was opened at 2007-01-03 19:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627244&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pierre Imbaud (pmi)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom parse bug
Initial Comment:
xml.dom.minidom was unable to parse an xml file that came from an example
provided by an official organism.(http://www.iptc.org/IPTC4XMP)
The parsed file was somewhat hairy, but I have been able to reproduce the bug
with a simplified
version, attached. (ends with .xmp: its supposed
to be an xmp file, the xmp standard being built on
xml. Well, thats the short story).
The offending part is the one that goes: xmpPLUS=''
it triggers an exception: ValueError: too many values to unpack,
in _parse_ns_name. Some debugging showed an obvious mistake
in the scanning of the name argument, that goes beyond the closing
" ' ".
I digged a little further thru a pdb session, but the bug seems to be located
in c code.
Thats the very first time I report a bug, chances are I provide too much or too
little information...
To whoever it may concern, here is the invoking code:
from xml.dom import minidom
...
class xmp(dict):
def __init__(self, inStream):
xmldoc = minidom.parse(inStream)
x = xmp('/home/pierre/devt/port/IPTCCore-Full/x.xmp')
traceback:
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xmpLib.py in
__init__(self, inStream)
26 def __init__(self, inStream):
27 print minidom
---> 28 xmldoc = minidom.parse(inStream)
29 xmpmeta = xmldoc.childNodes[1]
30 rdf = xmpmeta.childNodes[1]
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/nxml/dom/minidom.py in
parse(file, parser, bufsize)
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in parse(file, namespaces)
922 fp = open(file, 'rb')
923 try:
--> 924 result = builder.parseFile(fp)
925 finally:
926 fp.close()
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in parseFile(self, file)
205 if not buffer:
206 break
--> 207 parser.Parse(buffer, 0)
208 if first_buffer and self.document.documentElement:
209 self._setup_subset(buffer)
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in start_element_handler(self, name, attributes)
743 def start_element_handler(self, name, attributes):
744 if ' ' in name:
--> 745 uri, localname, prefix, qname = _parse_ns_name(self, name)
746 else:
747 uri = EMPTY_NAMESPACE
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in _parse_ns_name(builder, name)
125 localname = intern(localname, localname)
126 else:
--> 127 uri, localname = parts
128 prefix = EMPTY_PREFIX
129 qname = localname = intern(localname, localname)
ValueError: too many values to unpack
The offending c statement:
/usr/src/packages/BUILD/Python-2.4/Modules/pyexpat.c(582)StartElement()
The returned 'name':
(Pdb) name
Out[5]: u'XMP Photographic Licensing Universal System (xmpPLUS,
http://ns.adobe.com/xap/1.0/PLUS/) CreditLineReq xmpPLUS'
Its obvious the scanning went beyond the attribute.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627244&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1627266 ] optparse "store" action should not gobble up next option
Feature Requests item #1627266, was opened at 2007-01-03 13:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1627266&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse "store" action should not gobble up next option
Initial Comment:
Hi,
Check the following code:
--opttest.py--
from optparse import OptionParser
def process_options():
global options, args, parser
parser = OptionParser()
parser.add_option("--test", action="store_true")
parser.add_option("-m", metavar="COMMENT", dest="comment", default=None)
(options, args) = parser.parse_args()
return
process_options()
print "comment (%r)" % options.comment
-
$ ./opttest.py -m --test
comment ('--test')
I was expecting this to give an error as "--test" is an option. But it looks
like even C library's getopt() behaves similarly. It will be nice if optparse
can report error in this case.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1627266&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3
Bugs item #1519816, was opened at 2006-07-10 09:29
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 proxy does not work in 2.4.3
Initial Comment:
My python app had to retrieve some web pages and while
our network environment requires proxy it uses urllib2
opener (source is in attachment). It worked very well
on older Python interpreters:
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based
on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310
32 bit (Intel)] on win32
It works on linux with 2.3 and 2.4.1:
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
But it does not work with newest 2.4.3 on Linux:
Python 2.4.3 (#1, Jul 10 2006, 09:57:52)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Desired result:
isof-mark:~# python2.3 proxy_bug.py
trying http://www.python.org ...
OK. We have reply from http://www.python.org.
Size: 13757 [b]
http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd">
http://www.w3.org/
1999/xhtml">
design by pollenation
Copyright Š 1990-2006, Python Software
Foundation
Legal Statements
isof-mark:~# /usr/local/bin/python proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
File "proxy_bug.py", line 37, in ?
get_page()
File "proxy_bug.py", line 27, in get_page
f = urllib2.urlopen(request)
File "/usr/local/lib/python2.4/urllib2.py", line
130, in urlopen
return _opener.open(url, data)
File "/usr/local/lib/python2.4/urllib2.py", line
364, in open
response = meth(req, response)
File "/usr/local/lib/python2.4/urllib2.py", line
471, in http_response
response = self.parent.error(
File "/usr/local/lib/python2.4/urllib2.py", line
402, in error
return self._call_chain(*args)
File "/usr/local/lib/python2.4/urllib2.py", line
337, in _call_chain
result = func(*args)
File "/usr/local/lib/python2.4/urllib2.py", line
480, in http_error_default
raise HTTPError(req.get_full_url(), code, msg,
hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy
Authentication Required
I have raported it on ActiveState bug list (http://
bugs.activestate.com/show_bug.cgi?id=47018) while I
first spot this bug on their destribution but it seems
that bug is in others distributions too.
Regards,
Michal Niklas
--
Comment By: John J Lee (jjlee)
Date: 2007-01-03 19:37
Message:
Logged In: YES
user_id=261020
Originator: NO
lecaros and jerrykhan: Do you guys by any chance have a registry key
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\ProxyOverride?
I'm guessing this setting is causing urllib to avoid using your default
proxy for hosts on your local network, thereby saving you the 407 (the 407
means your proxy is complaining that you've not succeeded in
authenticating).
If so, the difference between urllib and urllib2's behaviours does not
imply a bug, but just that urllib2 is missing support for getting proxy
overrides from the Windows registry. This could easily be added.
--
Comment By: José Lecaros Cisterna (lecaros)
Date: 2007-01-03 16:33
Message:
Logged In: YES
user_id=1410109
Originator: NO
i have the same issue on windows xp, python 2.4.3
but using DOMAIN\username format
--
Comment By: JerryKhan (jerrykhan)
Date: 2006-11-28 15:17
Message:
Logged In: YES
user_id=867168
Originator: NO
Hello,
In my sens in a general manner there is something wrong in the urllib2
http code:
But this may depends on the environment (I am not an expert in urllib)
Here are my tests : using python 2.4.2 on Windows XP
These simple codes failed with a 407 http error :
Example E1:
import urllib2 as URL
a=URL.urlopen("http://lan_apache_url";)
print a.read()
OR example E2:
import urllib2 as URL
r=URL.Request("http://lan_apache_url";)
a=URL.urlopen(r)
print a.read()
But succeed with urllib example E3
import urllib
a=urllib.urlopen("http://lan_apache_url";)
print a.read()
Notice that different code lines are minimal E1 and E3 are close:
Notice also that I'm try to access a lan apache server which is not behind
a Proxy.
And I don't want to access to any Proxy (like exclusion string in
IExplorer)
But I found also that If I try to access to a protected link with HTTPS
... on the LAN, there is not problem. The issue is really on the HTTP
interpreter or during the configuration of the URL opener.
In the sam
[ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3
Bugs item #1519816, was opened at 2006-07-10 04:29
Message generated for change (Comment added) made by lecaros
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 proxy does not work in 2.4.3
Initial Comment:
My python app had to retrieve some web pages and while
our network environment requires proxy it uses urllib2
opener (source is in attachment). It worked very well
on older Python interpreters:
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based
on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310
32 bit (Intel)] on win32
It works on linux with 2.3 and 2.4.1:
Python 2.4.1 (#2, May 5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
But it does not work with newest 2.4.3 on Linux:
Python 2.4.3 (#1, Jul 10 2006, 09:57:52)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Desired result:
isof-mark:~# python2.3 proxy_bug.py
trying http://www.python.org ...
OK. We have reply from http://www.python.org.
Size: 13757 [b]
http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd">
http://www.w3.org/
1999/xhtml">
design by pollenation
Copyright Š 1990-2006, Python Software
Foundation
Legal Statements
isof-mark:~# /usr/local/bin/python proxy_bug.py
trying http://www.python.org ...
Traceback (most recent call last):
File "proxy_bug.py", line 37, in ?
get_page()
File "proxy_bug.py", line 27, in get_page
f = urllib2.urlopen(request)
File "/usr/local/lib/python2.4/urllib2.py", line
130, in urlopen
return _opener.open(url, data)
File "/usr/local/lib/python2.4/urllib2.py", line
364, in open
response = meth(req, response)
File "/usr/local/lib/python2.4/urllib2.py", line
471, in http_response
response = self.parent.error(
File "/usr/local/lib/python2.4/urllib2.py", line
402, in error
return self._call_chain(*args)
File "/usr/local/lib/python2.4/urllib2.py", line
337, in _call_chain
result = func(*args)
File "/usr/local/lib/python2.4/urllib2.py", line
480, in http_error_default
raise HTTPError(req.get_full_url(), code, msg,
hdrs, fp)
urllib2.HTTPError: HTTP Error 407: Proxy
Authentication Required
I have raported it on ActiveState bug list (http://
bugs.activestate.com/show_bug.cgi?id=47018) while I
first spot this bug on their destribution but it seems
that bug is in others distributions too.
Regards,
Michal Niklas
--
Comment By: José Lecaros Cisterna (lecaros)
Date: 2007-01-03 17:02
Message:
Logged In: YES
user_id=1410109
Originator: NO
I have that key set to , but I don't know what this mean :) Use
for local OR don't use for local.
--
Comment By: John J Lee (jjlee)
Date: 2007-01-03 16:37
Message:
Logged In: YES
user_id=261020
Originator: NO
lecaros and jerrykhan: Do you guys by any chance have a registry key
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\ProxyOverride?
I'm guessing this setting is causing urllib to avoid using your default
proxy for hosts on your local network, thereby saving you the 407 (the 407
means your proxy is complaining that you've not succeeded in
authenticating).
If so, the difference between urllib and urllib2's behaviours does not
imply a bug, but just that urllib2 is missing support for getting proxy
overrides from the Windows registry. This could easily be added.
--
Comment By: José Lecaros Cisterna (lecaros)
Date: 2007-01-03 13:33
Message:
Logged In: YES
user_id=1410109
Originator: NO
i have the same issue on windows xp, python 2.4.3
but using DOMAIN\username format
--
Comment By: JerryKhan (jerrykhan)
Date: 2006-11-28 12:17
Message:
Logged In: YES
user_id=867168
Originator: NO
Hello,
In my sens in a general manner there is something wrong in the urllib2
http code:
But this may depends on the environment (I am not an expert in urllib)
Here are my tests : using python 2.4.2 on Windows XP
These simple codes failed with a 407 http error :
Example E1:
import urllib2 as URL
a=URL.urlopen("http://lan_apache_url";)
print a.read()
OR example E2:
import urllib2 as URL
r=URL.Request("http://lan_apache_url";)
a=URL.urlopen(r)
print a.read()
But succeed with urllib example E3
import urllib
a=urllib.urlopen("http://lan_apache_url";)
print a.read()
Notice that different code lines are minimal E1 and E3 are close:
Notice also that I'm try to access a lan apache server which is not behind
[ python-Bugs-1627316 ] an extra comma in condition command crashes pdb
Bugs item #1627316, was opened at 2007-01-03 12:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: an extra comma in condition command crashes pdb Initial Comment: if instead of condition one enters (note the extra comma): condition , pdb throws an exception and aborts execution of a program Relevant parts of stacktrace: File "/usr/lib/python2.4/bdb.py", line 48, in trace_dispatch return self.dispatch_line(frame) File "/usr/lib/python2.4/bdb.py", line 66, in dispatch_line self.user_line(frame) File "/usr/lib/python2.4/pdb.py", line 135, in user_line self.interaction(frame, None) File "/usr/lib/python2.4/pdb.py", line 158, in interaction self.cmdloop() File "/usr/lib/python2.4/cmd.py", line 142, in cmdloop stop = self.onecmd(line) File "/usr/lib/python2.4/cmd.py", line 219, in onecmd return func(arg) File "/usr/lib/python2.4/pdb.py", line 390, in do_condition bpnum = int(args[0].strip()) ValueError: invalid literal for int(): 2, Uncaught exception. Entering post mortem debugging Running 'cont' or 'step' will restart the program > /site/tools/pse/lib/python2.4/pdb.py(390)do_condition() -> bpnum = int(args[0].strip()) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627316&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627373 ] Typo in module index for Carbon.CarbonEvt
Bugs item #1627373, was opened at 2007-01-03 14:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627373&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in module index for Carbon.CarbonEvt Initial Comment: The module index lists the name at 'CaronEvt' (notice the missing 'b'). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627373&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1601399 ] urllib2 does not close sockets properly
Bugs item #1601399, was opened at 2006-11-22 21:04
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601399&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brendan Jurd (direvus)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 does not close sockets properly
Initial Comment:
Python 2.5 (release25-maint, Oct 29 2006, 12:44:11)
[GCC 4.1.2 20061026 (prerelease) (Debian 4.1.1-18)] on linux2
I first noticed this when a program of mine (which makes a brief HTTPS
connection every 20 seconds) started having some weird crashes. It turned out
that the process had a massive number of file descriptors open. I did some
debugging, and it became clear that the program was opening two file
descriptors for every HTTPS connection it made with urllib2, and it wasn't
closing them, even though I was reading all data from the response objects and
then explictly calling close() on them.
I found I could easily reproduce the behaviour using the interactive console.
Try this while keeping an eye on the file descriptors held open by the python
process:
To begin with, the process will have the usual FDs 0, 1 and 2 open for
std(in|out|err), plus one other.
>>> import urllib2
>>> f = urllib2.urlopen("http://www.google.com";)
Now at this point the process has opened two more sockets.
>>> f.read()
[... HTML ensues ...]
>>> f.close()
The two extra sockets are still open.
>>> del f
The two extra sockets are STILL open.
>>> f = urllib2.urlopen("http://www.python.org";)
>>> f.read()
[...]
>>> f.close()
And now we have a total of four abandoned sockets open.
It's not until you terminate the process entirely, or the OS (eventually)
closes the socket on idle timeout, that they are closed.
Note that if you do the same thing with httplib, the sockets are properly
closed:
>>> import httplib
>>> c = httlib.HTTPConnection("www.google.com", 80)
>>> c.connect()
A socket has been opened.
>>> c.putrequest("GET", "/")
>>> c.endheaders()
>>> r = c.getresponse()
>>> r.read()
[...]
>>> r.close()
And the socket has been closed.
--
Comment By: John J Lee (jjlee)
Date: 2007-01-03 23:54
Message:
Logged In: YES
user_id=261020
Originator: NO
Confirmed. The cause is the (ab)use of socket._fileobject by
urllib2.AbstractHTTPHandler to provide .readline() and .readlines()
methods. _fileobject simply does not close the socket on
_fileobject.close() (since in the original intended use of _fileobject,
_socketobject "owns" the socket, and _fileobject only has a reference to
it). The bug was introduced with the upgrade to HTTP/1.1 in revision
36871.
The patch here fixes it:
http://python.org/sf/1627441
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601399&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627543 ] Status bar on OSX garbled
Bugs item #1627543, was opened at 2007-01-03 23:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627543&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: sigzero (sigzero) Assigned to: Nobody/Anonymous (nobody) Summary: Status bar on OSX garbled Initial Comment: The way that OSX windows work there is always a resizing handle in the lower right hand corner of windows. The way that IDLE currently does the statusbar is: |Ln: 13|Col: 4 This cause the Col number to be placed over the resizer. Something along the lines of: |Ln: 13|Col: 4| would probably ensure that the resizer is not overlayed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627543&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627543 ] Status bar on OSX garbled
Bugs item #1627543, was opened at 2007-01-03 23:49 Message generated for change (Comment added) made by sigzero You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627543&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: sigzero (sigzero) Assigned to: Nobody/Anonymous (nobody) Summary: Status bar on OSX garbled Initial Comment: The way that OSX windows work there is always a resizing handle in the lower right hand corner of windows. The way that IDLE currently does the statusbar is: |Ln: 13|Col: 4 This cause the Col number to be placed over the resizer. Something along the lines of: |Ln: 13|Col: 4| would probably ensure that the resizer is not overlayed. -- >Comment By: sigzero (sigzero) Date: 2007-01-03 23:49 Message: Logged In: YES user_id=1339209 Originator: YES This is for IDLE 1.1.4 and I am using Python 2.4.4 on OSX Tiger. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627543&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627575 ] RotatingFileHandler cannot recover from failed doRollover()
Bugs item #1627575, was opened at 2007-01-03 22:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627575&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Forest Wilkinson (forest) Assigned to: Nobody/Anonymous (nobody) Summary: RotatingFileHandler cannot recover from failed doRollover() Initial Comment: When RotatingFileHandler.doRollover() raises an exception, it puts the handler object in a permanently failing state, with no way to recover using RotatingFileHandler methods. From that point on, the handler object raises an exception every time a message is logged, which renders logging in an application practically useless. Furthermore, a handleError() method has no good way of correcting the problem, because the API does not expose any way to re-open the file after doRollover() has closed it. Unfortunately, this is a common occurrence on Windows, because doRollover() will fail if someone is running tail -f on the log file. Suggestions: - Make doRollover() always leave the handler object in a usable state, even if the rollover fails. - Add a reOpen() method to FileHandler, which an error handler could use to recover from problems like this. (It would also be useful for applications that want to re-open log files in response to a SIGHUP.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627575&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627373 ] Typo in module index for Carbon.CarbonEvt
Bugs item #1627373, was opened at 2007-01-03 14:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627373&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) >Assigned to: Neal Norwitz (nnorwitz) Summary: Typo in module index for Carbon.CarbonEvt Initial Comment: The module index lists the name at 'CaronEvt' (notice the missing 'b'). -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-03 22:26 Message: Logged In: YES user_id=33168 Originator: NO Committed revision 53235. Committed revision 53236. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627373&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627575 ] RotatingFileHandler cannot recover from failed doRollover()
Bugs item #1627575, was opened at 2007-01-03 22:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627575&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Forest Wilkinson (forest) >Assigned to: Vinay Sajip (vsajip) Summary: RotatingFileHandler cannot recover from failed doRollover() Initial Comment: When RotatingFileHandler.doRollover() raises an exception, it puts the handler object in a permanently failing state, with no way to recover using RotatingFileHandler methods. From that point on, the handler object raises an exception every time a message is logged, which renders logging in an application practically useless. Furthermore, a handleError() method has no good way of correcting the problem, because the API does not expose any way to re-open the file after doRollover() has closed it. Unfortunately, this is a common occurrence on Windows, because doRollover() will fail if someone is running tail -f on the log file. Suggestions: - Make doRollover() always leave the handler object in a usable state, even if the rollover fails. - Add a reOpen() method to FileHandler, which an error handler could use to recover from problems like this. (It would also be useful for applications that want to re-open log files in response to a SIGHUP.) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-03 22:27 Message: Logged In: YES user_id=33168 Originator: NO Vinay, was this addressed? I thought there was a similar issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627575&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627244 ] xml.dom.minidom parse bug
Bugs item #1627244, was opened at 2007-01-03 10:04
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627244&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Pierre Imbaud (pmi)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom parse bug
Initial Comment:
xml.dom.minidom was unable to parse an xml file that came from an example
provided by an official organism.(http://www.iptc.org/IPTC4XMP)
The parsed file was somewhat hairy, but I have been able to reproduce the bug
with a simplified
version, attached. (ends with .xmp: its supposed
to be an xmp file, the xmp standard being built on
xml. Well, thats the short story).
The offending part is the one that goes: xmpPLUS=''
it triggers an exception: ValueError: too many values to unpack,
in _parse_ns_name. Some debugging showed an obvious mistake
in the scanning of the name argument, that goes beyond the closing
" ' ".
I digged a little further thru a pdb session, but the bug seems to be located
in c code.
Thats the very first time I report a bug, chances are I provide too much or too
little information...
To whoever it may concern, here is the invoking code:
from xml.dom import minidom
...
class xmp(dict):
def __init__(self, inStream):
xmldoc = minidom.parse(inStream)
x = xmp('/home/pierre/devt/port/IPTCCore-Full/x.xmp')
traceback:
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xmpLib.py in
__init__(self, inStream)
26 def __init__(self, inStream):
27 print minidom
---> 28 xmldoc = minidom.parse(inStream)
29 xmpmeta = xmldoc.childNodes[1]
30 rdf = xmpmeta.childNodes[1]
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/nxml/dom/minidom.py in
parse(file, parser, bufsize)
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in parse(file, namespaces)
922 fp = open(file, 'rb')
923 try:
--> 924 result = builder.parseFile(fp)
925 finally:
926 fp.close()
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in parseFile(self, file)
205 if not buffer:
206 break
--> 207 parser.Parse(buffer, 0)
208 if first_buffer and self.document.documentElement:
209 self._setup_subset(buffer)
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in start_element_handler(self, name, attributes)
743 def start_element_handler(self, name, attributes):
744 if ' ' in name:
--> 745 uri, localname, prefix, qname = _parse_ns_name(self, name)
746 else:
747 uri = EMPTY_NAMESPACE
/home/pierre/devt/fileInfo/svnRep/branches/xml/xmpLib/xml/dom/expatbuilder.py
in _parse_ns_name(builder, name)
125 localname = intern(localname, localname)
126 else:
--> 127 uri, localname = parts
128 prefix = EMPTY_PREFIX
129 qname = localname = intern(localname, localname)
ValueError: too many values to unpack
The offending c statement:
/usr/src/packages/BUILD/Python-2.4/Modules/pyexpat.c(582)StartElement()
The returned 'name':
(Pdb) name
Out[5]: u'XMP Photographic Licensing Universal System (xmpPLUS,
http://ns.adobe.com/xap/1.0/PLUS/) CreditLineReq xmpPLUS'
Its obvious the scanning went beyond the attribute.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-03 22:32
Message:
Logged In: YES
user_id=33168
Originator: NO
Dupe of 1627096
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627244&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
