[ python-Bugs-1513611 ] xml.sax.ParseException weirdness in python 2.5b1
Bugs item #1513611, was opened at 2006-06-27 23:06
Message generated for change (Comment added) made by zseil
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.ParseException weirdness in python 2.5b1
Initial Comment:
There is something weird going on with xml.sax
exceptions, probably related to the xml/xmlcore shuffle:
from xml.sax import make_parser, SAXParseException
from StringIO import StringIO
parser = make_parser()
try:
parser.parse(StringIO('invalid'))
except SAXParseException:
print 'caught it!'
On python 2.4.3 this prints "caught it!". On python
2.5b1 the exception is not caught, because it is a
different exception: an
xmlcore.sax._exceptions.SAXParseException. Printing the
SAXParseException imported from xml.sax gives "".
Stumbled on this running the logilab-common (see
logilab.org) tests with python 2.5b1, but it seems
likely other code will be affected.
--
Comment By: iga Seilnacht (zseil)
Date: 2006-07-10 09:37
Message:
Logged In: YES
user_id=1326842
This bug is simmilar to http://python.org/sf/1511497.
It is caused by absolute imports in xmlcore.sax.expatreader.
Patch #1519796 ( http://python.org/sf/1519796 )
should fix it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1511497 ] xml.sax.expatreader is missing
Bugs item #1511497, was opened at 2006-06-23 20:14 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax.expatreader is missing Initial Comment: Hi, when testing the new Python 2.5 subversion tree I encountered this behaviour: $ python2.5 Python 2.5b1 (trunk:47065, Jun 22 2006, 20:56:23) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.sax.expatreader >>> print xml.sax.expatreader Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'expatreader' >>> So the import went ok, but using the attribute gave an error. This is very strange. Python 2.4 did not have this behaviour. -- Comment By: iga Seilnacht (zseil) Date: 2006-07-10 09:38 Message: Logged In: YES user_id=1326842 See patch #1519796: http://python.org/sf/1519796 -- Comment By: iga Seilnacht (zseil) Date: 2006-06-27 00:52 Message: Logged In: YES user_id=1326842 I see the same behaviour with the official Python 2.5 beta 1 Windows installer. The interesting thing is that the expatreader module is present in sys.modules: Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC v.1310 32 bit (Intel)] on win32 ... >>> import xml.sax.expatreader >>> xml.sax.expatreader Traceback (most recent call last): ... AttributeError: 'module' object has no attribute 'expatreader' >>> import sys >>> sys.modules['xml.sax.expatreader'] All of the other modules in xml package can be imported without any trouble. I don't understand what is the real problem here, but it goes away if you import xmlcore.sax package before expatreader: [restart python] >>> import xmlcore.sax >>> import xml.sax.expatreader >>> xml.sax.expatreader The simplest fix would be to use at least one absolute import in ...\lib\xmlcore\sax\__init__.py, for example you could change line 22: from xmlreader import InputSource to: from xmlcore.sax.xmlreader import InputSource but that might just hide the real bug. -- Comment By: Wummel (calvin) Date: 2006-06-26 20:15 Message: Logged In: YES user_id=9205 I built Python directly from the SVN trunk repository with $ ./configure && make altinstall I attached the pyconfig.h that was generated. If you need more info, feel free to ask. After building and installing, I started up python2.5 and executed "import xml.sax.expatreader" and then "print xml.sax.expatreader", and nothing else. Another thing I tried is "import from", which works. But importing xml.sax.expatreader directly, as noted above, does not work. Here is the log with the "import from" test: Python 2.5b1 (trunk:47090, Jun 25 2006, 09:59:02) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from xml.sax import expatreader >>> print expatreader >>> print xml.sax.expatreader Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'expatreader' -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-24 12:39 Message: Logged In: YES user_id=21627 How precisely did you test it? What configure options did you set up, what commands did you provide to build Python? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3
Bugs item #1467450, was opened at 2006-04-10 03:21
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&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
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on OSX 10.3
Initial Comment:
test test_ctypes failed -- Traceback (most recent call
last):
File
"/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py",
line 30, in test_load
cdll.load(libc_name)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 112, in load
return self._load(libname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 153, in _load
return self.load_library(pathname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 124, in load_library
return self._dlltype(libname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/__init__.py",
line 288, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlcompat: unable to open this file with RTLD_LOCAL
This happens both with and without the patch in r43748.
Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power
Macintosh powerpc
GCC version:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)
--
>Comment By: Thomas Heller (theller)
Date: 2006-07-10 10:13
Message:
Logged In: YES
user_id=11105
Here is a patch that I hope will fix this problem. Ronald
Oussuren suggested in private email to use RTLD_GLOBAL as
default library loading mode on OS X 10.3. He suggested to
use the platform module to find out the osx version, however
I don't like. Instead I found by examining platform that
gestalt.gestalt("sysv") returns the information I need.
I still don't have access to 10.3 (and Python does not
compile on the 10.2.8 sourceforge osx compile farm machine -
should I add a bug for that one?), so I cannot really test
the patch myself.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 06:14
Message:
Logged In: YES
user_id=33168
Anthony is this still a problem?
--
Comment By: Thomas Heller (theller)
Date: 2006-05-09 20:38
Message:
Logged In: YES
user_id=11105
Does this failure still occur with Python 2.5a2, or the
current SVN trunk?
--
Comment By: Thomas Heller (theller)
Date: 2006-04-13 08:59
Message:
Logged In: YES
user_id=11105
I'm trying to get a copy of OS X 10.3, then will try to
install it and look after this problem.
OTOH, the ctypes loading code is currently rewritten in the
upstream version - this will probably prevent this failure.
In the meantime, can you try to find out the cause of this
failure? Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is
the library file missing?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&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 ] Proxy does not work in 2.4.3
Bugs item #1519816, was opened at 2006-07-10 10:29 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=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 Submitted By: Michal Niklas (mniklas) Assigned to: Nobody/Anonymous (nobody) Summary: 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 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&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 ] Proxy does not work in 2.4.3
Bugs item #1519816, was opened at 2006-07-10 10:29
Message generated for change (Comment added) made by mniklas
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
Submitted By: Michal Niklas (mniklas)
Assigned to: Nobody/Anonymous (nobody)
Summary: 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: Michal Niklas (mniklas)
Date: 2006-07-10 10:41
Message:
Logged In: YES
user_id=226518
Cannot add attachment via upload so I put it here:
#!/usr/bin/python
# -*- coding: cp1250 -*-
import urllib
import urllib2
def get_page():
url = 'http://www.python.org'
print "trying %s ..." % (url)
# Setup proxy & authentication
proxy = "poczta.heuthes:8080"
usr1 = "USER"
pass1 = "PASSWD"
proxy_handler = urllib2.ProxyHandler({"http" : "http:/
/" + proxy})
pass_mgr = urllib2.HTTPPasswordMgrWithDefaultRealm()
pass_mgr.add_password(None, "http://"; + proxy, usr1,
pass1)
pass_mgr.add_password(None, proxy, usr1, pass1)
auth_handler = urllib2.HTTPBasicAuthHandler(pass_mgr)
proxy_auth_handler =
urllib2.ProxyBasicAuthHandler(pass_mgr)
# Now build a new URL opener and install it
opener = urllib2.build_opener(proxy_handler,
proxy_auth_handler, auth_handler, urllib2.HTTPHandler)
urllib2.install_opener(opener)
request = urllib2.Request(url)
f = urllib2.urlopen(request)
data = f.read()
print "OK. We have reply from %s.\nSize: %d [b]" %
(url, len(data))
if len(data) < 400:
print data
else:
print data[:200]
print "..."
print data[-200:]
get_page()
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3
Bugs item #1467450, was opened at 2006-04-10 03:21
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&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
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on OSX 10.3
Initial Comment:
test test_ctypes failed -- Traceback (most recent call
last):
File
"/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py",
line 30, in test_load
cdll.load(libc_name)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 112, in load
return self._load(libname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 153, in _load
return self.load_library(pathname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 124, in load_library
return self._dlltype(libname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/__init__.py",
line 288, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlcompat: unable to open this file with RTLD_LOCAL
This happens both with and without the patch in r43748.
Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power
Macintosh powerpc
GCC version:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)
--
>Comment By: Thomas Heller (theller)
Date: 2006-07-10 11:07
Message:
Logged In: YES
user_id=11105
Even better would imo be to call the Gestalt function in the
_ctypes extensions module itself.
--
Comment By: Thomas Heller (theller)
Date: 2006-07-10 10:13
Message:
Logged In: YES
user_id=11105
Here is a patch that I hope will fix this problem. Ronald
Oussuren suggested in private email to use RTLD_GLOBAL as
default library loading mode on OS X 10.3. He suggested to
use the platform module to find out the osx version, however
I don't like. Instead I found by examining platform that
gestalt.gestalt("sysv") returns the information I need.
I still don't have access to 10.3 (and Python does not
compile on the 10.2.8 sourceforge osx compile farm machine -
should I add a bug for that one?), so I cannot really test
the patch myself.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 06:14
Message:
Logged In: YES
user_id=33168
Anthony is this still a problem?
--
Comment By: Thomas Heller (theller)
Date: 2006-05-09 20:38
Message:
Logged In: YES
user_id=11105
Does this failure still occur with Python 2.5a2, or the
current SVN trunk?
--
Comment By: Thomas Heller (theller)
Date: 2006-04-13 08:59
Message:
Logged In: YES
user_id=11105
I'm trying to get a copy of OS X 10.3, then will try to
install it and look after this problem.
OTOH, the ctypes loading code is currently rewritten in the
upstream version - this will probably prevent this failure.
In the meantime, can you try to find out the cause of this
failure? Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is
the library file missing?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1518190 ] c_void_pointer should accept a long pointer > 0x7fffffff
Bugs item #1518190, was opened at 2006-07-06 16:46 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518190&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: Closed Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: c_void_pointer should accept a long pointer > 0x7fff Initial Comment: Mike Fletcher reported this problem: http://tinyurl.com/esneq Currently, the c_void_p constructor calls PyLong_AsVoidPtr(value), in Modules/_ctypes/cfield.c, near line 1491. This call should be changed to use either PyLong_AsUnsignedLongMask() or PyLong_AsUnsignedLongLongMask() depending on sizeof(void *), and cast the result to (void *). This change would also make the c_void_p behaviour more consistent with the other c_int, c_long and so on constructors since all of them mask the value to the number of bits they can accept. -- >Comment By: Thomas Heller (theller) Date: 2006-07-10 11:12 Message: Logged In: YES user_id=11105 Committed as r50513. Neal, I'm not sure I got the #elif instead of #if issue as you were requesting it, if not, feel free to fix that yourself. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 02:32 Message: Logged In: YES user_id=33168 This patch is fine. Please try to apply before the freeze for b2. Also, please use #elif instead of nested #if. It makes the code a little shorter and easier to read. This looks like a bug fix which is fine, though I'm not sure of all the consequences of the change. Be sure to add a note to Misc/NEWS. -- Comment By: Thomas Heller (theller) Date: 2006-07-06 19:03 Message: Logged In: YES user_id=11105 Assigning to Neal for review (please). The #if block is not really needed imo, but I used it for clarity - it is copied verbatim from Objects/longobject.c, which would throw compile errors if the conditions are not fulfilled. -- Comment By: Thomas Heller (theller) Date: 2006-07-06 18:56 Message: Logged In: YES user_id=11105 Attached a patch, with tests, that fixes this bug. PyInt_AsUnsignedLongMask() and PyInt_AsUnsignedLongLongMask() is what we need to use. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1518190&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3
Bugs item #1467450, was opened at 2006-04-10 11:21
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&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
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on OSX 10.3
Initial Comment:
test test_ctypes failed -- Traceback (most recent call
last):
File
"/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py",
line 30, in test_load
cdll.load(libc_name)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 112, in load
return self._load(libname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 153, in _load
return self.load_library(pathname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 124, in load_library
return self._dlltype(libname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/__init__.py",
line 288, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlcompat: unable to open this file with RTLD_LOCAL
This happens both with and without the patch in r43748.
Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power
Macintosh powerpc
GCC version:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)
--
>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-10 19:43
Message:
Logged In: YES
user_id=29957
I'm not going to get the opportunity to look at this before
the b2 freeze tomorrow morning, but will look at it soon after.
--
Comment By: Thomas Heller (theller)
Date: 2006-07-10 19:07
Message:
Logged In: YES
user_id=11105
Even better would imo be to call the Gestalt function in the
_ctypes extensions module itself.
--
Comment By: Thomas Heller (theller)
Date: 2006-07-10 18:13
Message:
Logged In: YES
user_id=11105
Here is a patch that I hope will fix this problem. Ronald
Oussuren suggested in private email to use RTLD_GLOBAL as
default library loading mode on OS X 10.3. He suggested to
use the platform module to find out the osx version, however
I don't like. Instead I found by examining platform that
gestalt.gestalt("sysv") returns the information I need.
I still don't have access to 10.3 (and Python does not
compile on the 10.2.8 sourceforge osx compile farm machine -
should I add a bug for that one?), so I cannot really test
the patch myself.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 14:14
Message:
Logged In: YES
user_id=33168
Anthony is this still a problem?
--
Comment By: Thomas Heller (theller)
Date: 2006-05-10 04:38
Message:
Logged In: YES
user_id=11105
Does this failure still occur with Python 2.5a2, or the
current SVN trunk?
--
Comment By: Thomas Heller (theller)
Date: 2006-04-13 16:59
Message:
Logged In: YES
user_id=11105
I'm trying to get a copy of OS X 10.3, then will try to
install it and look after this problem.
OTOH, the ctypes loading code is currently rewritten in the
upstream version - this will probably prevent this failure.
In the meantime, can you try to find out the cause of this
failure? Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is
the library file missing?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1510172 ] Absolute/relative import not working?
Bugs item #1510172, was opened at 2006-06-22 05:35 Message generated for change (Settings changed) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510172&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nick Coghlan (ncoghlan) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = "spam" According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File "moduleX.py", line 3, in from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? -- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-10 21:08 Message: Logged In: YES user_id=1038590 Punting on this until 2.6. See updated PEP 338 for the gory details. -- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-01 02:51 Message: Logged In: YES user_id=1038590 Patch attached that allows relative imports from a main module to work so long as: a. the top level package is either in the current directory or somewhere else on sys.path; and b. the module is executed using -m so Python knows where it fits in the package hierarchy So to get the PEP 328 example to work, you'd have to run it as: $python2.5 -m package.subpackage1.moduleX The patch relies on a feature added to runpy in rev 47142 (post beta 1). I've added a question to PEP 356 as to how this should be handled, since we're technically in feature freeze. Patch attached directly to the bug report because it's stupidly early in the morning and I don't feel like dealing with SF and then copying the patch tracker number here :) -- Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-27 21:46 Message: Logged In: YES user_id=1038590 All that said, PEP 328 currently says that "from ...sys import path" should be legal from moduleX in the example. I tried it, and it currently fails - the ValueError gets raised as soon as the number of dots in the relative path exceeds the number of dots in __name__, instead of treating a single excess dot as requesting an absolute import instead. (All of the other examples in the PEP work as specified when moduleX and subpackage1 are imported rather than executed directly) I believe fixing this would also fix Mitch's problem - an explicit relative import from __main__ would be treated as a top level import. I also have an idea regarding the -m switch that I will raise on python-dev. -- Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-27 21:34 Message: Logged In: YES user_id=1038590 The issue isn't actually unique to the -m switch - the problem is that relative imports are based on __name__, and in the main module, __name__ always has the value '__main__'. Hence, relative imports currently can't work properly from the main module of an application, because the main module doesn't know where it really fits in the Python module namespace (this is at least fixable in theory for the main modules executed through the -m switch, but directly executed files and the interactive interpreter are completely out of luck). With the old implicit relative imports this behaviour is masked by the fact that executing a module puts that module's directory on sys.path. When you execute a module in a package directly, it actually imports its sibling modules as top-level modules. The fact that the -m switch doesn't allow this to occur is a delib
[ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3
Bugs item #1519816, was opened at 2006-07-10 08:29
Message generated for change (Comment added) made by gbrandl
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
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: Georg Brandl (gbrandl)
Date: 2006-07-10 12:49
Message:
Logged In: YES
user_id=849994
Can you please try with 2.5b1? A lot of urllib2 related bugs
have been fixed before this release.
--
Comment By: Michal Niklas (mniklas)
Date: 2006-07-10 08:41
Message:
Logged In: YES
user_id=226518
Cannot add attachment via upload so I put it here:
#!/usr/bin/python
# -*- coding: cp1250 -*-
import urllib
import urllib2
def get_page():
url = 'http://www.python.org'
print "trying %s ..." % (url)
# Setup proxy & authentication
proxy = "poczta.heuthes:8080"
usr1 = "USER"
pass1 = "PASSWD"
proxy_handler = urllib2.ProxyHandler({"http" : "http:/
/" + proxy})
pass_mgr = urllib2.HTTPPasswordMgrWithDefaultRealm()
pass_mgr.add_password(None, "http://"; + proxy, usr1,
pass1)
pass_mgr.add_password(None, proxy, usr1, pass1)
auth_handler = urllib2.HTTPBasicAuthHandler(pass_mgr)
proxy_auth_handler =
urllib2.ProxyBasicAuthHandler(pass_mgr)
# Now build a new URL opener and install it
opener = urllib2.build_opener(proxy_handler,
proxy_auth_handler, auth_handler, urllib2.HTTPHandler)
urllib2.install_opener(opener)
request = urllib2.Request(url)
f = urllib2.urlopen(request)
data = f.read()
print "OK. We have reply from %s.\nSize: %d [b]" %
(url, len(data))
if len(data) < 400:
print data
else:
print data[:200]
print "..."
print data[-200:]
get_page()
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1516184 ] inspect.py: still infinite recursion inspecting frames
Bugs item #1516184, was opened at 2006-07-03 08:39 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516184&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Don Quijote (dq_searchlores) Assigned to: Phillip J. Eby (pje) Summary: inspect.py: still infinite recursion inspecting frames Initial Comment: Using python 2.5 beta 1 on Windows XP, and py2exe 0.6.5. After packing and compressing a project via py2exe, there's still an infinite recursion involving functions getsourcefile, getmodule and getabsfile in module inspect.py. I was able to fix this infinite recursion by 1) changing the declaration of getabsfile & getmodule to: def getabsfile(object, filename=None): def getmodule(object, filename=None): 2) including the "filename" parameter in all calls to getabsfile inside of function getmodule. 3) having getabsfile return the absolute and normalized filename if not null. Perhaps this change helps to clean up the 'ugliness' introduced in version 45822. Kind regards, Don Quijote -- >Comment By: Phillip J. Eby (pje) Date: 2006-07-10 19:05 Message: Logged In: YES user_id=56214 Fixed in revision 50526. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-05 01:53 Message: Logged In: YES user_id=33168 Phillip any comments? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516184&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1457312 ] AttributeError in upload_file on interrupted connection
Bugs item #1457312, was opened at 2006-03-23 21:33 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457312&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stefan Behnel (scoder) Assigned to: Phillip J. Eby (pje) Summary: AttributeError in upload_file on interrupted connection Initial Comment: I got the following error when my network interface went down while I was uploading a file to PyPI: - Traceback (most recent call last): File "setup.py", line 109, in ? classifiers = [ File "/usr/lib64/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib64/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib64/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib64/python2.4/site-packages/setuptools-0.6a10-py2.4.egg/setuptools/command/upload.py", line 65, in run self.upload_file(command, pyversion, filename) File "/usr/lib64/python2.4/site-packages/setuptools-0.6a10-py2.4.egg/setuptools/command/upload.py", line 158, in upload_file self.announce(e.msg, log.ERROR) AttributeError: error instance has no attribute 'msg' - I was told that these setuptools files were copied from Py2.5 distutils, that's why I'm reporting the error here. -- >Comment By: Phillip J. Eby (pje) Date: 2006-07-10 19:18 Message: Logged In: YES user_id=56214 Fixed in revision 50528. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457312&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1520176 ] non-uniform behavior in 'startswith' / 'endswith'
Bugs item #1520176, was opened at 2006-07-10 19: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=1520176&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Milind (t-milich)
Assigned to: Nobody/Anonymous (nobody)
Summary: non-uniform behavior in 'startswith' / 'endswith'
Initial Comment:
compare the two versions of 'endswith'.
Either both of them should throw TypeErorr or both
should return boolean value.
>>> 'abc'.endswith( ('abc',None))
True
>>> 'abc'.endswith( ('abc',None),4,3)
Traceback (most recent call last):
File "", line 1, in
TypeError: expected a character buffer object
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520176&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446119 ] subprocess interpreted double quotation wrong on windows
Bugs item #1446119, was opened at 2006-03-09 05:26 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446119&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: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: simon (simonhang) Assigned to: Peter à strand (astrand) Summary: subprocess interpreted double quotation wrong on windows Initial Comment: If we run below python command print subprocess.Popen([r'c:\test.bat', r'test"string:']).pid Actually c:\test.bat test\"string\" is executed. Module subprocess doesn't interpret double quotation mark right. Back slash shouldn't be added. I believe problem is in function subprocess.list2cmdline. -- >Comment By: Peter à strand (astrand) Date: 2006-07-10 22:12 Message: Logged In: YES user_id=344921 As far as I can tell, there's nothing wrong with subprocess.list2cmdline. Take a look at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/progs_12.asp. There, you will find: ab"c which corresponds to: "ab\"c" In other words: a backslash should be added when converting from an argument to a string. Or do you intepret the MS web page differently? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446119&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1520176 ] non-uniform behavior in 'startswith' / 'endswith'
Bugs item #1520176, was opened at 2006-07-10 19:49
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520176&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Milind (t-milich)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: non-uniform behavior in 'startswith' / 'endswith'
Initial Comment:
compare the two versions of 'endswith'.
Either both of them should throw TypeErorr or both
should return boolean value.
>>> 'abc'.endswith( ('abc',None))
True
>>> 'abc'.endswith( ('abc',None),4,3)
Traceback (most recent call last):
File "", line 1, in
TypeError: expected a character buffer object
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-10 20:15
Message:
Logged In: YES
user_id=849994
The current code shortcuts if it finds a match, so I think
this is not a bug. Raymond?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520176&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1444408 ] subprocess test cases fail with noexec-mounted /tmp
Bugs item #108, was opened at 2006-03-06 21:48 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=108&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Wummel (calvin) Assigned to: Peter à strand (astrand) Summary: subprocess test cases fail with noexec-mounted /tmp Initial Comment: Hi, on my Linux box two subprocess tests always fail (see below for a log output). The reason is those two tests try to execute files created with tempfile.mkstemp(), which generates files in /tmp. And my /tmp directory forbids to execute files, it is mounted with the "noexec" option. What I expected from the tests is to either find a temporary directory where execution is allowed (eg. the directory where sys.executable lies), or simply skip those tests. Test output: [...] == ERROR: test_args_string (test.test_subprocess.ProcessTestCase) -- Traceback (most recent call last): File "/home/calvin/src/python-svn/Lib/test/test_subprocess.py", line 490, in test_args_string p = subprocess.Popen(fname) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 580, in __init__ errread, errwrite) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 1033, in _execute_child raise child_exception OSError: [Errno 13] Permission denied == ERROR: test_call_string (test.test_subprocess.ProcessTestCase) -- Traceback (most recent call last): File "/home/calvin/src/python-svn/Lib/test/test_subprocess.py", line 532, in test_call_string rc = subprocess.call(fname) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 431, in call return Popen(*popenargs, **kwargs).wait() File "/home/calvin/src/python-svn/Lib/subprocess.py", line 580, in __init__ errread, errwrite) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 1033, in _execute_child raise child_exception OSError: [Errno 13] Permission denied -- >Comment By: Peter à strand (astrand) Date: 2006-07-10 22:30 Message: Logged In: YES user_id=344921 The directory with sys.executable is certainly not guaranteed to be writable. For example, when I run the test suite with the Python shipped with my Linux distribution, os.path.dirname(sys.executable) is /usr/bin, which I cannot write to. So, I don't like this patch. Having /tmp mounted with "noexec" is just stupid, IMHO. Which Linux distribution does this? I do have some experience with working around "noexec" mounts and my experience is that /tmp is "as good as it gets". If someone can prove me wrong, then we can think of patching test_subprocess, but until that, I'm going to close this bug. -- Comment By: Wummel (calvin) Date: 2006-03-16 17:20 Message: Logged In: YES user_id=9205 I attached a patch that creates temp files in the directory of sys.executable. This directory is guaranteed to have executable permissions, and should also have write permissions (since sys.executable should have been generated from a previous make run). With the patch the test case runs ok. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=108&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1376309 ] subprocess.CalledProcessError uses errno incorrectly
Bugs item #1376309, was opened at 2005-12-08 15:14 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376309&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.5 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Peter à strand (astrand) Summary: subprocess.CalledProcessError uses errno incorrectly Initial Comment: I have some code which uses subprocess.check_call(), which is buried in other code that catches an OSError, and does different things depending on OSError.errno. Since subprocess.CalledProcessError overloads errno for its own return code values, this leads to confusing error messages. The return code is NOT an errno, and I do not think this field should be overloaded in this way. Additionally, since OSError exceptions generally have an errno attribute set, and exception-handling code expects this, I do not think that CalledProcessError should subclass from it. -- >Comment By: Peter à strand (astrand) Date: 2006-07-10 22:33 Message: Logged In: YES user_id=344921 Duplicate of 1223937. -- Comment By: Michael Hoffman (hoffmanm) Date: 2005-12-08 15:27 Message: Logged In: YES user_id=987664 Ugh, this was supposed to be a bug, not a patch. Is there anyway to change this or should I just resumbit? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376309&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1223937 ] subprocess.py abuse of errno
Bugs item #1223937, was opened at 2005-06-20 08:56 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&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 Submitted By: Oren Tirosh (orenti) Assigned to: Peter à strand (astrand) Summary: subprocess.py abuse of errno Initial Comment: The CalledProcessError exception's .errno attribute is set to a child process return code which is not an errno. Any attempt to look up this number with os.strerror() or errno.errorcode[] will result in meaningless output. This can break existing code that catches OSError and does not expect CalledProcessError. Possible resolutions: 1. Don't make CalledProcessError a subclass of OSError 2. If CalledProcessError stays a subclass of OSError .errno should be set to some specific meaningful value (which one? add new value to errnomodule.c?) and use a separate attribute for the child process return code. -- >Comment By: Peter à strand (astrand) Date: 2006-07-10 22:34 Message: Logged In: YES user_id=344921 Bug 1376309 has been marked as a duplicate of this bug. -- Comment By: Peter à strand (astrand) Date: 2005-06-21 22:13 Message: Logged In: YES user_id=344921 I've changed my mind, since CalledProcessError is only in the development version of Python. Perhaps it's acceptable to change the API after all, then. Re-opening. -- Comment By: Peter à strand (astrand) Date: 2005-06-21 17:52 Message: Logged In: YES user_id=344921 In hindsight, CalledProcessError should perhaps have been designed some other way. But now when we have it, it's not easy to change it. It all comes down to what is the documented behaviour and not. As far as I understand, there's no requirement that the errno number or an OSError should be possible to look up with os.strerror(). I cannot find anything about this at http://docs.python.org/lib/module-exceptions.html, at least. All it says is "[errno is] assumed to be an error number". In my opinion, code should be prepared for "unknown" error numbers. So currently, I'm not prepared to make any changes to CalledProcessError. (If you disagree with me, post to python-dev and see what others think.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1223937 ] subprocess.py abuse of errno
Bugs item #1223937, was opened at 2005-06-20 08:56 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&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 Submitted By: Oren Tirosh (orenti) Assigned to: Peter à strand (astrand) Summary: subprocess.py abuse of errno Initial Comment: The CalledProcessError exception's .errno attribute is set to a child process return code which is not an errno. Any attempt to look up this number with os.strerror() or errno.errorcode[] will result in meaningless output. This can break existing code that catches OSError and does not expect CalledProcessError. Possible resolutions: 1. Don't make CalledProcessError a subclass of OSError 2. If CalledProcessError stays a subclass of OSError .errno should be set to some specific meaningful value (which one? add new value to errnomodule.c?) and use a separate attribute for the child process return code. -- >Comment By: Peter à strand (astrand) Date: 2006-07-11 00:53 Message: Logged In: YES user_id=344921 If we fix this before Python 2.5, I guess we don't need to think about backwards compatibility. See the attached patch for a suggested solution. -- Comment By: Peter à strand (astrand) Date: 2006-07-10 22:34 Message: Logged In: YES user_id=344921 Bug 1376309 has been marked as a duplicate of this bug. -- Comment By: Peter à strand (astrand) Date: 2005-06-21 22:13 Message: Logged In: YES user_id=344921 I've changed my mind, since CalledProcessError is only in the development version of Python. Perhaps it's acceptable to change the API after all, then. Re-opening. -- Comment By: Peter à strand (astrand) Date: 2005-06-21 17:52 Message: Logged In: YES user_id=344921 In hindsight, CalledProcessError should perhaps have been designed some other way. But now when we have it, it's not easy to change it. It all comes down to what is the documented behaviour and not. As far as I understand, there's no requirement that the errno number or an OSError should be possible to look up with os.strerror(). I cannot find anything about this at http://docs.python.org/lib/module-exceptions.html, at least. All it says is "[errno is] assumed to be an error number". In my opinion, code should be prepared for "unknown" error numbers. So currently, I'm not prepared to make any changes to CalledProcessError. (If you disagree with me, post to python-dev and see what others think.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Bugs item #1494314, was opened at 2006-05-24 06:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Michael Smith (mlrsmith) Assigned to: Neal Norwitz (nnorwitz) Summary: Cannot use high-numbered sockets in 2.4.3 Initial Comment: Python 2.4.3 introduced (in Modules/socketmodule.c) the IS_SELECTABLE() macro, to check whether calling select() on a given file descriptor is permissible. However, it executes this check even when it won't actually call select(). Specifically, select() is called ONLY when s->sock_timeout > 0 (in internal_select mostly, but also internal_connect). I have a twisted application which uses many FDs (several thousand), and upgrading python to 2.4.3 makes it hit this limit (at 1024 file descriptors), regardless of ulimit settings. Twisted itself always uses non-blocking I/O on sockets, so with older versions of python this worked fine. A simple solution relies on the fact that select is only ever actually called, and changes the IS_SELECTABLE macro as in the attached fairly trivial patch. This is sufficient to restore my application to its previous state (where it works fine). This doesn't solve the more general problem in socketmodule - that we simply can't do all operations properly with the current reliance on select(), though, and it seems like a bit of a hack... If I wrote up a patch to use poll() on systems where it's available, throughout socketmodule.c, in preference to select(), would this be accepted? Mike -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 19:53 Message: Logged In: YES user_id=33168 Anthony checked this in to 2.5 as 50567. I will backport at least part of it later. -- Comment By: Martin v. Löwis (loewis) Date: 2006-07-09 22:47 Message: Logged In: YES user_id=21627 The patch is fine, please apply. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-09 16:57 Message: Logged In: YES user_id=33168 I meant I don't think we *care* in this case (not can). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-09 16:55 Message: Logged In: YES user_id=33168 I think you're right Martin. Looking at what it means to have a broken poll, I don't think we can in this instance. So I removed all refs to HAVE_BROKEN_POLL. What do you think of the new version? -- Comment By: Martin v. Löwis (loewis) Date: 2006-07-07 08:50 Message: Logged In: YES user_id=21627 The __APPLE__ stuff looks wrong in file 184131. You would have to use selectmodule.c:select_have_broken_poll at run-time to be sure you can use poll(2) on OS X (you can use it on 10.4, but can't on 10.3, IIRC). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-06 23:10 Message: Logged In: YES user_id=33168 I've added a more complete patch (against 2.5, hopefully applies to 2.4 too). It cleans up some things and adds support for SSL sockets too. Can people please review/test this? I manually tested this with regular sockets and it seemed to work. All the tests pass, but this is somewhat tricky. I hate the duplicated code between socket and ssl modules, but added to it. It would be great to clean this up for 2.6. If you are forced to use select with a high socket, the exception on connect is operation in progress rather than can't select on socket. I guess that's ok, it doesn't actually change the existing behaviour. That would have been more involved and I'm not sure it's worth it. -- Comment By: Michael Smith (mlrsmith) Date: 2006-06-09 03:31 Message: Logged In: YES user_id=1488997 Ok, I'll attach a patch that uses poll when available (HAVE_POLL is already being set by the configure stuff appropriately). It replaces one of the two uses of select() (specifically, the internal_select() function) in socketmodule.c. The other is win32-specific, so replacing it with poll() wouldn't make sense. greg: epoll/kevent don't make sense for replacing the use of select/poll in this particular case - socketmodule.c always selects/polls precisely one file descriptor. I've tested this locally, and it fixes the problem (linux/x86). I don't have a windows system to test it on, but it shouldn't change behaviour in a
[ python-Bugs-1520327 ] __missing__ does not get called
Bugs item #1520327, was opened at 2006-07-11 03:40
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=1520327&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Milind (t-milich)
Assigned to: Nobody/Anonymous (nobody)
Summary: __missing__ does not get called
Initial Comment:
On the last step a[10] we expect 100
>>> class A(dict):
... pass
...
>>> a = A({1:2})
>>> def foo(a,b): return 100
...
>>> a.__missing__ = foo
>>> a[1]
2
>>> a.__missing__(10,20)
100
>>> a[10]
Traceback (most recent call last):
File "", line 1, in
KeyError: 10
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520327&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Bugs item #1494314, was opened at 2006-05-24 23:51 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Smith (mlrsmith) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Cannot use high-numbered sockets in 2.4.3 Initial Comment: Python 2.4.3 introduced (in Modules/socketmodule.c) the IS_SELECTABLE() macro, to check whether calling select() on a given file descriptor is permissible. However, it executes this check even when it won't actually call select(). Specifically, select() is called ONLY when s->sock_timeout > 0 (in internal_select mostly, but also internal_connect). I have a twisted application which uses many FDs (several thousand), and upgrading python to 2.4.3 makes it hit this limit (at 1024 file descriptors), regardless of ulimit settings. Twisted itself always uses non-blocking I/O on sockets, so with older versions of python this worked fine. A simple solution relies on the fact that select is only ever actually called, and changes the IS_SELECTABLE macro as in the attached fairly trivial patch. This is sufficient to restore my application to its previous state (where it works fine). This doesn't solve the more general problem in socketmodule - that we simply can't do all operations properly with the current reliance on select(), though, and it seems like a bit of a hack... If I wrote up a patch to use poll() on systems where it's available, throughout socketmodule.c, in preference to select(), would this be accepted? Mike -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-11 13:52 Message: Logged In: YES user_id=29957 Applied. Patch will be in 2.5b2 (to be released shortly). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-11 12:53 Message: Logged In: YES user_id=33168 Anthony checked this in to 2.5 as 50567. I will backport at least part of it later. -- Comment By: Martin v. Löwis (loewis) Date: 2006-07-10 15:47 Message: Logged In: YES user_id=21627 The patch is fine, please apply. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 09:57 Message: Logged In: YES user_id=33168 I meant I don't think we *care* in this case (not can). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 09:55 Message: Logged In: YES user_id=33168 I think you're right Martin. Looking at what it means to have a broken poll, I don't think we can in this instance. So I removed all refs to HAVE_BROKEN_POLL. What do you think of the new version? -- Comment By: Martin v. Löwis (loewis) Date: 2006-07-08 01:50 Message: Logged In: YES user_id=21627 The __APPLE__ stuff looks wrong in file 184131. You would have to use selectmodule.c:select_have_broken_poll at run-time to be sure you can use poll(2) on OS X (you can use it on 10.4, but can't on 10.3, IIRC). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-07 16:10 Message: Logged In: YES user_id=33168 I've added a more complete patch (against 2.5, hopefully applies to 2.4 too). It cleans up some things and adds support for SSL sockets too. Can people please review/test this? I manually tested this with regular sockets and it seemed to work. All the tests pass, but this is somewhat tricky. I hate the duplicated code between socket and ssl modules, but added to it. It would be great to clean this up for 2.6. If you are forced to use select with a high socket, the exception on connect is operation in progress rather than can't select on socket. I guess that's ok, it doesn't actually change the existing behaviour. That would have been more involved and I'm not sure it's worth it. -- Comment By: Michael Smith (mlrsmith) Date: 2006-06-09 20:31 Message: Logged In: YES user_id=1488997 Ok, I'll attach a patch that uses poll when available (HAVE_POLL is already being set by the configure stuff appropriately). It replaces one of the two uses of select() (specifically, the internal_select() function) in socketmodule.c. The other is win32-specific, so replacing it with poll() wouldn't make sense. greg: epoll/kevent don't make sense for replacing the use o
[ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3
Bugs item #1519816, was opened at 2006-07-10 10:29 Message generated for change (Comment added) made by mniklas 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 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: Michal Niklas (mniklas) Date: 2006-07-11 08:27 Message: Logged In: YES user_id=226518 Tried it with 2.5 beta 1 and it is not better :( c:\tools\pyscripts\scripts>c:\python25\python2.5 Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC v.1310 32 bit (Intel)] on win32 c:\tools\pyscripts\scripts>c:\python25\python2.5 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 "c:\python25\lib\urllib2.py", line 121, in urlopen return _opener.open(url, data) File "c:\python25\lib\urllib2.py", line 380, in open response = meth(req, response) File "c:\python25\lib\urllib2.py", line 491, in http_response 'http', request, response, code, msg, hdrs) File "c:\python25\lib\urllib2.py", line 412, in error result = self._call_chain(*args) File "c:\python25\lib\urllib2.py", line 353, in _call_chain result = func(*args) File "c:\python25\lib\urllib2.py", line 831, in http_error_407 authority, req, headers) File "c:\python25\lib\urllib2.py", line 795, in http_error_auth_reqed return self.retry_http_basic_auth(host, req, realm) File "c:\python25\lib\urllib2.py", line 805, in retry_http_basic_auth return self.parent.open(req) File "c:\python25\lib\urllib2.py", line 380, in open response = meth(req, response) File "c:\python25\lib\urllib2.py", line 491, in http_response 'http', request, response, code, msg, hdrs) File "c:\python25\lib\urllib2.py", line 418, in error return self._call_chain(*args) File "c:\python25\lib\urllib2.py", line 353, in _call_chain result = func(*args) File "c:\python25\lib\urllib2.py", line 499, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 407: Proxy Authentication Required -- Comment By: Georg Brandl (gbrandl) Date: 2006-07-10 14:49 Message: Logged In: YES user_id=849994 Can you please try with 2.5b1? A lot of urllib2 related bugs have been fixed bef
