[ python-Bugs-900898 ] urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr
Bugs item #900898, was opened at 2004-02-20 06:51
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900898&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: James Kruth (jk7)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr
Initial Comment:
If the Request object being used returns a URI with a
port included (e.g. http://www.mysite.com:/index.html)
If Request.get_full_url() or Request.get_host() returns
a URI or host with a port included (e.g.
http://www.mysite.com:/index.html or
www.mysite.com:, respectively), and authentication
(proxy or http, basic only) is required, then the
respective AuthHandlers (HTTPBasicAuthHandler,
ProxyBasicAuthHandler) end up calling
http_error_auth_reqed with a host looking like
"www.mysite.com:". http_error_auth_reqed then
precedes to call retry_http_basic_auth with the same
host parameter, which in turn calls
HTTPPasswordMgr.find_user_password. The problem is
that find_user_password appears to expect a full URI,
and attempts to reduce it to just a host, by calling
reduce_uri. If a bare host with a port is passed (like
"www.mysite.com:"), then reduce_uri returns just
the port number in the netloc position - which
find_user_password then attempts to compare against the
correct host name you've stored in your HTTPPasswordMgr
object along with your user name and password. I
believe either find_user_password should not reduce the
host, or the Auth Handler objects should pass full
hostnames to find_user_password.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 08:22
Message:
Logged In: YES
user_id=849994
Fixed with commit of patch 1470846.
--
Comment By: John J Lee (jjlee)
Date: 2006-04-15 17:59
Message:
Logged In: YES
user_id=261020
This is fixed by patch 1470846, which includes tests and doc
fix / update (though I neglected to mention that the patch
fixes this problem in the initial patch comment; I'll
rectify that now).
--
Comment By: Brad Clements (bkc)
Date: 2004-04-06 19:58
Message:
Logged In: YES
user_id=4631
I ran into this problem today with Python 2.3.3 on RedHat 9.
I'm using port numbers in my URLs, and I found that the Auth
Handler did NOT correctly find the userid and password
registered.
ie:
authinfo = urllib2.HTTPPasswordMgrWithDefaultRealm()
authinfo.add_password(None, host, userid, password)
authHandler = urllib2.HTTPBasicAuthHandler(authinfo)
opener = urllib2.build_opener(authHandler)
where host = "http://localhost:7993";
I've tested the proposed fix shown in urllib2_bug.py at line 31,
to whit, this:
class HTTPBasicAuthHandlerF(AbstractBasicAuthHandler,
BaseHandler):
auth_header = 'Authorization'
def http_error_401(self, req, fp, code, msg, headers):
host = req.get_full_url()
return self.http_error_auth_reqed('www-authenticate',
host, req, headers)
This appears to have corrected the problem.
test_urllib2.py and test_urllib.py both pass after making
this change. I did not test the ProxyBasicAuthHandler change
(I don't have a proxy)
--
Comment By: James Kruth (jk7)
Date: 2004-02-20 21:25
Message:
Logged In: YES
user_id=979977
Here's a sample of the problem...
--
Comment By: James Kruth (jk7)
Date: 2004-02-20 14:39
Message:
Logged In: YES
user_id=979977
I've made up a file with some source code and comments that
will hopefully clarify what I posted. I will post an
example of the problem a bit later today.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900898&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1479226 ] test_inspect fails on WinXP (2.5a2)
Bugs item #1479226, was opened at 2006-04-30 11: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=1479226&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_inspect fails on WinXP (2.5a2) Initial Comment: test_inspect fails after installing 2.5a2 on WinXP Output of python -c "from test.test_inspect import test_main; test_main()" is attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479226&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1473560 ] urllib2.Request constructor to urllib.quote the url given
Bugs item #1473560, was opened at 2006-04-20 14:02
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&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
Submitted By: Nikos Kouremenos (nkour)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2.Request constructor to urllib.quote the url given
Initial Comment:
urllib2.Request('http://www.google.com/search?client=firefox&q=foo
bar', None)
this fails. it shouldn't
--
Comment By: Nikos Kouremenos (nkour)
Date: 2006-04-29 11:34
Message:
Logged In: YES
user_id=865368
it's foo bar not foobar. and space should be automatcally
become %20 (urllib.quote()) but it doesn't. please reopen
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 19:19
Message:
Logged In: YES
user_id=849994
I don't know what your problem is. This works perfectly for me:
>>> r =
urllib2.Request("http://www.google.com/search?client=firefox&q=foobar";,
None)
>>> o = urllib2.HTTPHandler()
>>> u = o.http_open(r)
>>> u.read()
"..."
Closing as "Works for me". If you have another problem,
please reopen
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1473560 ] urllib2.Request constructor to urllib.quote the url given
Bugs item #1473560, was opened at 2006-04-20 14:02
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&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: Nikos Kouremenos (nkour)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2.Request constructor to urllib.quote the url given
Initial Comment:
urllib2.Request('http://www.google.com/search?client=firefox&q=foo
bar', None)
this fails. it shouldn't
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 09:25
Message:
Logged In: YES
user_id=849994
The docs say that the argument to the Request constructor
must be a valid URL. A valid URL doesn't contain spaces, so
the behavior is consistent.
--
Comment By: Nikos Kouremenos (nkour)
Date: 2006-04-29 11:34
Message:
Logged In: YES
user_id=865368
it's foo bar not foobar. and space should be automatcally
become %20 (urllib.quote()) but it doesn't. please reopen
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 19:19
Message:
Logged In: YES
user_id=849994
I don't know what your problem is. This works perfectly for me:
>>> r =
urllib2.Request("http://www.google.com/search?client=firefox&q=foobar";,
None)
>>> o = urllib2.HTTPHandler()
>>> u = o.http_open(r)
>>> u.read()
"..."
Closing as "Works for me". If you have another problem,
please reopen
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1281692 ] urllib violates rfc 959
Bugs item #1281692, was opened at 2005-09-04 17:30 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&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: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib violates rfc 959 Initial Comment: [forwarded from http://bugs.debian.org/324023] python's urllib does the following things "on the line" when retrieving a file by ftp: send(3, "PASV\r\n", 6, 0) = 6 send(3, "NLST ftp-master.debian.org\r\n", 28, 0) = 28 But RFC 959 states: This command [NLST] causes a directory listing to be sent from server to user site. The pathname should specify a directory or other system-specific file group descriptor So, according to the robustness principle, it is wrong that python aborts file transfer if the server refuses to support NLST on files. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 09:28 Message: Logged In: YES user_id=849994 Fixed by applying said patch. -- Comment By: John J Lee (jjlee) Date: 2006-04-15 20:06 Message: Logged In: YES user_id=261020 Patch 1470976 fixes this bug. -- Comment By: John J Lee (jjlee) Date: 2006-02-06 01:16 Message: Logged In: YES user_id=261020 Bug 1357260 reports the same issue for both urllib and urllib2. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-08 06:18 Message: Logged In: YES user_id=341410 "The pathname should specify a directory or other system-specific file group descriptor." If the system (ftp server) does not support a particular 'file name' as a 'file group descriptor', it seems to me that the system (ftp server) is braindead. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1357260 ] urllib/urllib2 cannot ftp files which are not listable.
Bugs item #1357260, was opened at 2005-11-15 10:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&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: Fixed Priority: 5 Submitted By: Bugs Fly (mozbugbox) Assigned to: Nobody/Anonymous (nobody) Summary: urllib/urllib2 cannot ftp files which are not listable. Initial Comment: For whatever reason (security, privacy), there are ftp sites which will not allow ftp list command while normal downloading can be performed "blindly". This mostly happens on direct linked ftp urls. In urllib.py, the ftp wrapper first check with "self.ftp.nlst(file)" before downloading, thus prevent the above sites from being useful. From the codes around, I saw no reason this extra step/check was performed at all. If the file really did not exist, RETR would return a suitable error anyway as checked by the code below. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 09:28 Message: Logged In: YES user_id=849994 Fixed by applying said patch. -- Comment By: John J Lee (jjlee) Date: 2006-04-15 20:06 Message: Logged In: YES user_id=261020 Patch 1470976 fixes this bug. -- Comment By: John J Lee (jjlee) Date: 2006-02-06 01:16 Message: Logged In: YES user_id=261020 Bug 1281692 reports the same issue for the urllib case, and includes a reference to the RFC. -- Comment By: Bugs Fly (mozbugbox) Date: 2005-11-17 05:38 Message: Logged In: YES user_id=1033842 File "/usr/lib/python2.4/ftplib.py", line 241, in sendcmd return self.getresp() File "/usr/lib/python2.4/ftplib.py", line 216, in getresp raise error_perm, resp IOError: [Errno ftp error] [Errno ftp error] 550 tompda_685692_Professional.Palm.OS.Programming.part12.rar: No such file or directory. -- Comment By: Thomas Lee (krumms) Date: 2005-11-15 13:34 Message: Logged In: YES user_id=315535 what's the expected response/error code from the FTP server if the NLST fails? -- Comment By: Bugs Fly (mozbugbox) Date: 2005-11-15 11:37 Message: Logged In: YES user_id=1033842 This might be related to bug #635453 but this is a bigger bug than a directory list is returned. If an existing file cannot be retrieved, then functionally is totally broken, there are no work around in this case. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion
Bugs item #1478253, was opened at 2006-04-28 08:59 Message generated for change (Comment added) made by balducci You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&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: 5 Submitted By: balducci (balducci) Assigned to: Thomas Heller (theller) Summary: test_ctypes: undefined symbol: XGetExtensionVersion Initial Comment: Dear python maintainers, apologies if I'm wrong or I'm missing some evident point. Just built 2.5a2 on linux: myhost> uname -a Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST 2006 i686 unknown I find that `make test' chokes in test_ctypes. Running the single test with `./python -E -tt ./Lib/test/regrtest.py -l -v -s test_ctypes' gives me the output shown in the attached file. As far as I could google around, I seem to understand that this problem has already appeared in the past. Basically, it is due to the fact that libglut (version 3.7) does not contain the XGetExtensionVersion function, which is instead defined in libXi: myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i xgetextensionversion U XGetExtensionVersion myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i xgetextensionversion 3930 T XGetExtensionVersion I seem to understand that libglut should be dlopen'ed together with libXi, in order to have XGetExtensionVersion available. Unfortunately, I don't speak python, so I'm not in the position to suggest any reasonable fix for this. I send this message in the hope of making something useful: if this is not the case, please, accept my apologies. I thank you very much for your time and effort in maintaining python. Ciao Gabriele -- >Comment By: balducci (balducci) Date: 2006-04-30 09:46 Message: Logged In: YES user_id=1452725 Dear Thomas, I thank you very much for your time and effort. I think I have solved the problem and, as I suspected, the problem was on my side and not on python's. ^ I have two shared libglut's installed: one is from orginal RedHat-7.1 distro and the other was installed by me some time ago. Now, if I check dependencies of the two libs, I get: RedHat's libglut: myhost> ldd /usr/lib/libglut.so linux-gate.so.1 => (0xe000) libSM.so.6 => /usr/local/X11R6/lib/libSM.so.6 (0xb7f1e000) libICE.so.6 => /usr/local/X11R6/lib/libICE.so.6 (0xb7f06000) libXmu.so.6 => /usr/local/X11R6/lib/libXmu.so.6 (0xb7ef) libXext.so.6 => /usr/local/X11R6/lib/libXext.so.6 (0xb7ee2000) libXi.so.6 => /usr/local/X11R6/lib/libXi.so.6 (0xb7eda000) libX11.so.6 => /usr/local/X11R6/lib/libX11.so.6 (0xb7e0e000) libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7cea000) libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7ce) libXt.so.6 => /usr/local/X11R6/lib/libXt.so.6 (0xb7c8d000) libdl.so.2 => /usr/local/glibc/lib/libdl.so.2 (0xb7c89000) /usr/local/glibc/lib/ld-linux.so.2 (0x8000) My libglut installation: --- myhost> ldd /usr/local/X11R6/lib/libglut.so linux-gate.so.1 => (0xe000) libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7f99000) libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7e76000) /usr/local/glibc/lib/ld-linux.so.2 (0x8000) Things seem to be clear for me now: /usr/lib/libglut.so contains all the necessary dependencies to resolve any reference which is not defined in it, while /usr/local/X11R6/lib/libglut.so does not contain any dependency from the X11 libs, which instead is NEEDED (e.g. the XGetExtensionVersion problem shown up). In fact, if I run `LD_LIBRARY_PATH=/usr/lib make test', i.e. force runtime loader to use /usr/lib/libglut.so, everything works nicely, even without the patch you sent. On the other hand, if /usr/local/X11R6/lib/libglut.so is picked up, then the errors occur and your patch does not solve the problem (and it could not in any case, given the above, I guess). Going back to my libglut installation notes, I could verify that no X11 dependencies were compiled in (most probably due to some misconfiguration by me). In the end, I think you can close this (which is not a) bug. I apologize once again for wasting your time on an issue which I could have investigated more deeply before claiming a bug in python. THANK YOU and ciao Gabriele -- Comment By: Thomas Heller (theller) Date: 2006-04-28 19:06 Message: Logged In: YES user_id=11105 Gabriele, from the thread you mention I would assume that this patch may fix the problem for you - it should be applied to Lib/ctypes/test/test_find.py: Index: test_find.py === --
[ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion
Bugs item #1478253, was opened at 2006-04-28 08:59 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&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: Closed >Resolution: Invalid Priority: 5 Submitted By: balducci (balducci) Assigned to: Thomas Heller (theller) Summary: test_ctypes: undefined symbol: XGetExtensionVersion Initial Comment: Dear python maintainers, apologies if I'm wrong or I'm missing some evident point. Just built 2.5a2 on linux: myhost> uname -a Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST 2006 i686 unknown I find that `make test' chokes in test_ctypes. Running the single test with `./python -E -tt ./Lib/test/regrtest.py -l -v -s test_ctypes' gives me the output shown in the attached file. As far as I could google around, I seem to understand that this problem has already appeared in the past. Basically, it is due to the fact that libglut (version 3.7) does not contain the XGetExtensionVersion function, which is instead defined in libXi: myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i xgetextensionversion U XGetExtensionVersion myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i xgetextensionversion 3930 T XGetExtensionVersion I seem to understand that libglut should be dlopen'ed together with libXi, in order to have XGetExtensionVersion available. Unfortunately, I don't speak python, so I'm not in the position to suggest any reasonable fix for this. I send this message in the hope of making something useful: if this is not the case, please, accept my apologies. I thank you very much for your time and effort in maintaining python. Ciao Gabriele -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 09:51 Message: Logged In: YES user_id=849994 Closing. Thank you for your thorough investigation. -- Comment By: balducci (balducci) Date: 2006-04-30 09:46 Message: Logged In: YES user_id=1452725 Dear Thomas, I thank you very much for your time and effort. I think I have solved the problem and, as I suspected, the problem was on my side and not on python's. ^ I have two shared libglut's installed: one is from orginal RedHat-7.1 distro and the other was installed by me some time ago. Now, if I check dependencies of the two libs, I get: RedHat's libglut: myhost> ldd /usr/lib/libglut.so linux-gate.so.1 => (0xe000) libSM.so.6 => /usr/local/X11R6/lib/libSM.so.6 (0xb7f1e000) libICE.so.6 => /usr/local/X11R6/lib/libICE.so.6 (0xb7f06000) libXmu.so.6 => /usr/local/X11R6/lib/libXmu.so.6 (0xb7ef) libXext.so.6 => /usr/local/X11R6/lib/libXext.so.6 (0xb7ee2000) libXi.so.6 => /usr/local/X11R6/lib/libXi.so.6 (0xb7eda000) libX11.so.6 => /usr/local/X11R6/lib/libX11.so.6 (0xb7e0e000) libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7cea000) libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7ce) libXt.so.6 => /usr/local/X11R6/lib/libXt.so.6 (0xb7c8d000) libdl.so.2 => /usr/local/glibc/lib/libdl.so.2 (0xb7c89000) /usr/local/glibc/lib/ld-linux.so.2 (0x8000) My libglut installation: --- myhost> ldd /usr/local/X11R6/lib/libglut.so linux-gate.so.1 => (0xe000) libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7f99000) libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7e76000) /usr/local/glibc/lib/ld-linux.so.2 (0x8000) Things seem to be clear for me now: /usr/lib/libglut.so contains all the necessary dependencies to resolve any reference which is not defined in it, while /usr/local/X11R6/lib/libglut.so does not contain any dependency from the X11 libs, which instead is NEEDED (e.g. the XGetExtensionVersion problem shown up). In fact, if I run `LD_LIBRARY_PATH=/usr/lib make test', i.e. force runtime loader to use /usr/lib/libglut.so, everything works nicely, even without the patch you sent. On the other hand, if /usr/local/X11R6/lib/libglut.so is picked up, then the errors occur and your patch does not solve the problem (and it could not in any case, given the above, I guess). Going back to my libglut installation notes, I could verify that no X11 dependencies were compiled in (most probably due to some misconfiguration by me). In the end, I think you can close this (which is not a) bug. I apologize once again for wasting your time on an issue which I could have investigated more deeply before claiming a bug in python. THANK YOU and ciao Gabriele -- Comment By: Thomas Heller (theller) Date: 2006-04-28 19:06 Message: Logged In: YES user_id=11105 Gabriele, fro
[ python-Bugs-1478529 ] size limit exceeded for read() from network drive
Bugs item #1478529, was opened at 2006-04-28 18:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Mark Sheppard (markshep) Assigned to: Nobody/Anonymous (nobody) Summary: size limit exceeded for read() from network drive Initial Comment: If you've got a network share mounted as a local drive then Windows has a limit of 67,076,095 (0x03ff7fff) bytes for a read from an open file on that drive. Running the python read() method on an open file larger than this size throws an "IOError: [Errno 22] Invalid argument" exception. A fix would be for python to internally use multiple reads so as to not exceed this limit. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-30 12:10 Message: Logged In: YES user_id=21627 What version of Windows are you using? Do you know of any documentation of this limit? (without actually testing, I find it hard to believe that this limit exists in Windows) -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-29 15:23 Message: Logged In: YES user_id=849994 How can it be determined whether exactly this restriction caused the "invalid argument" error? If it can't, there's nothing that can be done -- restricting all reads just because of a Windows limitation doesn't seem right. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1110705 ] list comprehension scope
Bugs item #1110705, was opened at 2005-01-27 14:27 Message generated for change (Comment added) made by cito You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: list comprehension scope Initial Comment: The variable used for iteration in list comprehensions is still in scope after the list comprehension. >>>foo = [1, 2, 3] >>>bar = [dummy + 1 for dummy in foo] >>>dummy 3 Expected result: NameError: name 'dummy' is not defined -- Comment By: Christoph Zwerschke (cito) Date: 2006-04-30 13:52 Message: Logged In: YES user_id=193957 Either this is a bug that should be fixed, or the documentation that says it is a bug should be fixed (http://www.python.org/doc/current/ref/lists.html#foot4519). That fact that an ordinary for loop leaks the control variables into the containing scope may be a design feature, but the same behavior for list comprehensions can hardly be called a design feature. At least not one that is reasonable. I would rather call it a bug. It definitely contradicts the principle of least surprise. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 20:54 Message: Logged In: YES user_id=341410 "this behavior is deprecated, and relying on it will not work once this bug is fixed in a future release" As we have not yet reached the future release in which this will happen, and the 'bug' is both known and documented, it will be 'fixed' when it is fixed. The reason that it has not yet been 'fixed' is because there is a nontrivial amount of code that would break if it was. I personally would call it a deprecated 'feature'. Then again, I use it more often than I should. -- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-01-27 15:11 Message: Logged In: YES user_id=750513 Seemingly (according to: http://docs.python.org/ref/lists.html) this is indeed a bug that should be fixed. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-27 14:48 Message: Logged In: YES user_id=80475 This is not a bug. It is behaving as designed. The thought was to emulate the behavior of an equivalent for-loop. In future versions of Python, Guido would like to change the design to hide the induction variable. So, someday, you'll get your wish. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478529 ] size limit exceeded for read() from network drive
Bugs item #1478529, was opened at 2006-04-28 12:46 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Mark Sheppard (markshep) Assigned to: Nobody/Anonymous (nobody) Summary: size limit exceeded for read() from network drive Initial Comment: If you've got a network share mounted as a local drive then Windows has a limit of 67,076,095 (0x03ff7fff) bytes for a read from an open file on that drive. Running the python read() method on an open file larger than this size throws an "IOError: [Errno 22] Invalid argument" exception. A fix would be for python to internally use multiple reads so as to not exceed this limit. -- >Comment By: Tim Peters (tim_one) Date: 2006-04-30 12:23 Message: Logged In: YES user_id=31435 Martin, here's an MS article seemingly related to this: http://support.microsoft.com/default.aspx?scid=kb;en-us;899149 However, it's about writing to a file on a network drive, not reading from it. It says that opening the file in 'w+b' mode, instead of 'wb' mode, is a workaround. I couldn't find anything documenting the same kind of problem for reading. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-30 06:10 Message: Logged In: YES user_id=21627 What version of Windows are you using? Do you know of any documentation of this limit? (without actually testing, I find it hard to believe that this limit exists in Windows) -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-29 09:23 Message: Logged In: YES user_id=849994 How can it be determined whether exactly this restriction caused the "invalid argument" error? If it can't, there's nothing that can be done -- restricting all reads just because of a Windows limitation doesn't seem right. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1479226 ] test_inspect fails on WinXP (2.5a2)
Bugs item #1479226, was opened at 2006-04-30 08:49 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479226&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_inspect fails on WinXP (2.5a2) Initial Comment: test_inspect fails after installing 2.5a2 on WinXP Output of python -c "from test.test_inspect import test_main; test_main()" is attached. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 17:43 Message: Logged In: YES user_id=849994 Thanks for reporting! This was caused by a bug in inspect.py which is was fixed in revisions 45822 and 45824. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479226&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active
Bugs item #1199282, was opened at 2005-05-10 18:24
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&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: Pending
>Resolution: Fixed
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Peter Ã
strand (astrand)
Summary: subprocess _active.remove(self) self not in list _active
Initial Comment:
I start a subprocess in a seperate thread (25 concurrent
threads)
in some of the threads the following error occurs
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
self.run()
File "upgrade.py", line 45, in run
returncode = p.wait()
File "C:\Python24\lib\subprocess.py", line 765, in wait
_active.remove(self)
ValueError: list.remove(x): x not in list
this is the code that starts the subprocess and where I
wait for the result
p = subprocess.Popen('command', \
stdin=None,
stdout=subprocess.PIPE, \
stderr=subprocess.STDOUT,
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 19:52
Message:
Logged In: YES
user_id=849994
The error causing "_active.remove(self)" call was removed
from wait() with patch 1467770, so I think this is fixed.
--
Comment By: cheops (atila-cheops)
Date: 2006-04-11 20:10
Message:
Logged In: YES
user_id=1276121
there are 2 definitions of the function poll, one for
windows and one for POSIX systems
in the windows version _deadlock is not used
in the POSIX version _deadlock is used
see also modification made by loewis in committed version
45234
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-04-11 07:21
Message:
Logged In: YES
user_id=1434251
I looked at the patch #1467770 you mentioned and
downloaded the patch.
Is it correct that _deadlock variable is used in the
definition of poll but it is not in the argument list?
--
Comment By: cheops (atila-cheops)
Date: 2006-04-10 14:57
Message:
Logged In: YES
user_id=1276121
see patch #1467770
--
Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 13:50
Message:
Logged In: YES
user_id=1488657
> Simply list operations such as remove() and append() are
> thread safe,
OK, my apologies... I did not know.
I did some more tests. On Linux, I found lots of:
File "./subprocess.py", line 428, in call
return Popen(*args, **kwargs).wait()
File "./subprocess.py", line 1023, in wait
pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes
The try...except solution does not handle this (since we are
in the "posix" section).
In my opinion, the call to _cleanup() in Popen.__init__() is
useless (it just checks if older processes have stopped when
a new one is started. I cannot see why it could be
mandatory) and it is the root of this bug.
I commented it out (line 506) and retried my tests on Linux
& Windows plateforms: I had no exception at all.
--
Comment By: Peter Ã
strand (astrand)
Date: 2006-03-29 05:11
Message:
Logged In: YES
user_id=344921
>I think accesses to _active should be serialized in a
>thread-safe way. _active could be a Queue (from the Queue
>module) for example
Simply list operations such as remove() and append() are
thread safe, so there should be no need for a Queue. Also, a
Queue cannot be used since the subprocess module needs to be
compatible with Python 2.2.
--
Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-28 23:17
Message:
Logged In: YES
user_id=1488657
I am running into the same problem on a Windows 2k/XP
plateform with a multi-threaded application. It occurs randomly.
It has never appened (yet) on a Linux plateform.
I think accesses to _active should be serialized in a
thread-safe way. _active could be a Queue (from the Queue
module) for example.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-25 08:10
Message:
Logged In: YES
user_id=1434251
Wouldn't it be best to completely remove any references
to "_active" and "_cleanup"?
--
Comment By: cheops (atila-cheops)
Date
[ python-Bugs-1385040 ] compiler module does not detect a syntax error
Bugs item #1385040, was opened at 2005-12-19 09:58
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler module does not detect a syntax error
Initial Comment:
import compiler
compiler.parse("def foo(a=1,b): pass")
Gives:
Module(None, Stmt([Function(None, 'foo', ['a', 'b'],
[Const(1)], 0, None, Stmt([Pass()]))]))
However, the python interpreter itself barks for the
same code:
SyntaxError: non-default argument follows default
argument
-Harri
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 20:20
Message:
Logged In: YES
user_id=849994
Attaching patch. Please review.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-25 21:59
Message:
Logged In: YES
user_id=33168
FYI.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1479586 ] Segmentation fault while using Tkinter
Bugs item #1479586, was opened at 2006-05-01 09:25 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=1479586&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 Submitted By: Ali Gholami Rudi (aligrudi) Assigned to: Martin v. Löwis (loewis) Summary: Segmentation fault while using Tkinter Initial Comment: While using Tkinter I encountere segmentation faults regularly. I ran my program using gdb using python2.4 and Fedora Core 5 and received: (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1209063760 (LWP 2024)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread -1212232800 (LWP 2027)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type to continue, or q to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1209063760 (LWP 2024)] 0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so (gdb) I ran the same program using python2.5a2 and again received: Starting program: /usr/local/bin/python ~/temp/rope/rope/rope.py Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xa05000 [Thread debugging using libthread_db enabled] [New Thread -1208899920 (LWP 2415)] [New Thread -1212068960 (LWP 2418)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208899920 (LWP 2415)] 0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so (gdb) Are these information enough for fixing the problem or should I send my program? Thanks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1475162 ] Tkinter hangs in test_tcl
Bugs item #1475162, was opened at 2006-04-23 23:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475162&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Martin v. Löwis (loewis) Summary: Tkinter hangs in test_tcl Initial Comment: For a while now, I've noticed test_tcl locking up when trying to refleaktest it. I was able to reproduce it quite simply: import Tkinter, os if "DISPLAY" in os.environ: del os.environ["DISPLAY"] tcl = Tkinter.Tcl() try: tcl.loadtk() except Exception, e: print e tcl.loadtk() Or using _tkinter directly: import _tkinter, os if "DISPLAY" in os.environ: del os.environ["DISPLAY"] tk = _tkinter.create(None, "test", "Tk", 0, 1, 0) try: tk.loadtk() except: pass tk.loadtk() In either case, the second loadtk never finishes. It seems that, on my platform at least, Tk_Init() doesn't like being called twice even when the first call resulted in an error. That's Tcl and Tk 8.4.12. Tkapp_Init() (which is the Tkinter part that calls Tk_Init()) does its best to guard against calling Tk_Init() twice when the first call was succesful, but it doesn't remember failure cases. I don't know enough about Tcl/Tk or Tkinter to know how this is best handled. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-05-01 08:30 Message: Logged In: YES user_id=21627 This should now be fixed with r45833 and r45834. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475162&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1479586 ] Segmentation fault while using Tkinter
Bugs item #1479586, was opened at 2006-05-01 06:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&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 Submitted By: Ali Gholami Rudi (aligrudi) Assigned to: Martin v. Löwis (loewis) Summary: Segmentation fault while using Tkinter Initial Comment: While using Tkinter I encountere segmentation faults regularly. I ran my program using gdb using python2.4 and Fedora Core 5 and received: (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1209063760 (LWP 2024)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread -1212232800 (LWP 2027)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type to continue, or q to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1209063760 (LWP 2024)] 0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so (gdb) I ran the same program using python2.5a2 and again received: Starting program: /usr/local/bin/python ~/temp/rope/rope/rope.py Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xa05000 [Thread debugging using libthread_db enabled] [New Thread -1208899920 (LWP 2415)] [New Thread -1212068960 (LWP 2418)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208899920 (LWP 2415)] 0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so (gdb) Are these information enough for fixing the problem or should I send my program? Thanks -- >Comment By: Martin v. Löwis (loewis) Date: 2006-05-01 08:34 Message: Logged In: YES user_id=21627 Please do send your program, or better yet a small test case that allows to reproduce the problem. It looks like a Tk bug at first glance, in TkUndoSetDepth. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
