[ python-Bugs-998998 ] pickle bug - recursively memoizing class?
Bugs item #998998, was opened at 2004-07-27 22:55 Message generated for change (Comment added) made by grubert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998998&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: pickle bug - recursively memoizing class? Initial Comment: The attached script (picklecycle.py) gives me an assertion error in Pickler.memoize(). Maybe I'm just doing something dumb. I have very little experience with pickle and even less experience pickling new-style class instances. I'm just trying to adapt an existing messy object graph to allow it to be pickled. I realize the two instances refer to each other, but I thought pickle was supposed to gracefully handle cyclic object graphs. I can worm around the problem a couple ways. First, getting rid of new-style classes does the trick. Also modifying B.__reduce__ to not return self.__dict__ seems to do the trick. Output (cycle.out) and a modified version of Pickler.memoize (memoize.py) will be attached momentarily. -- Comment By: engelbert gruber (grubert) Date: 2005-05-19 13:00 Message: Logged In: YES user_id=147070 it does memoize recursively, but "asserts" not to get stuck in cycles. that's how i understand the code if :: assert id(obj) not in self.memo is replaced by :: if id(obj) in self.memo: return it works (better). and test_pickle.py still passes. -- Comment By: Skip Montanaro (montanaro) Date: 2004-07-27 22:57 Message: Logged In: YES user_id=44345 Attaching the output I see when running picklecycle.py w/ the modified memoize() method (cycle.out). -- Comment By: Skip Montanaro (montanaro) Date: 2004-07-27 22:56 Message: Logged In: YES user_id=44345 Attaching chatty version of Pickler.memoize() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998998&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153016 ] Setting socket timeout crashes SSL
Bugs item #1153016, was opened at 2005-02-27 19:41
Message generated for change (Comment added) made by tarek-ziade
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153016&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: pristine777 (pristine777)
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting socket timeout crashes SSL
Initial Comment:
This bug was fixed in Python 2.3 but has resurfaced in
Python 2.4
The original bug report can be found at:
https://sourceforge.net/tracker/?
func=detail&atid=105470&aid=673797&group_id=5470
The method urlopen both in urllib and in urllib2 crashes
if socket.setdefaulttimeout has been called. Below is a
cut and paste when using the function in urllib.
>>> import socket
>>> socket.setdefaulttimeout(30.0)
>>> import urllib
>>> urllib.urlopen('https://members.tufts-
health.com/memindex.html')
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python24\lib\urllib.py", line 77, in urlopen
return opener.open(url)
File "C:\Python24\lib\urllib.py", line 180, in open
return getattr(self, name)(url)
File "C:\Python24\lib\urllib.py", line 374, in open_https
h.endheaders()
File "C:\Python24\lib\httplib.py", line 794, in
endheaders
self._send_output()
File "C:\Python24\lib\httplib.py", line 675, in
_send_output
self.send(msg)
File "C:\Python24\lib\httplib.py", line 642, in send
self.connect()
File "C:\Python24\lib\httplib.py", line 1069, in connect
ssl = socket.ssl(sock, self.key_file, self.cert_file)
File "C:\Python24\lib\socket.py", line 74, in ssl
return _realssl(sock, keyfile, certfile)
IOError: [Errno socket error] (2, 'The operation did not
complete (read)')
Thanks a ton!
--
Comment By: Tarek Ziadé (tarek-ziade)
Date: 2005-05-19 13:53
Message:
Logged In: YES
user_id=1163510
having same issue here, using imaplib thru ssl :/
>>> import socket
>>> socket.setdefaulttimeout(10)
>>> i = imaplib.IMAP4_SSL('mail..com')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/imaplib.py", line 1101, in __init__
IMAP4.__init__(self, host, port)
File "/usr/lib/python2.4/imaplib.py", line 181, in __init__
self.welcome = self._get_response()
File "/usr/lib/python2.4/imaplib.py", line 876, in
_get_response
resp = self._get_line()
File "/usr/lib/python2.4/imaplib.py", line 969, in _get_line
line = self.readline()
File "/usr/lib/python2.4/imaplib.py", line 1136, in readline
char = self.sslobj.read(1)
socket.sslerror: The read operation timed out
so i can't get timeouts with ssl in imap :/
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153016&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 23:43
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
>Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: a bunch of infinite C recursions
Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level,
and I have no clue at the moment how it could be reasonably fixed. The idea is
to define special __xxx__ methods in such a way that no Python code is actually
called before they invoke more special methods (e.g. themselves).
>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault
--
>Comment By: Armin Rigo (arigo)
Date: 2005-05-19 15:05
Message:
Logged In: YES
user_id=4771
This is not about the new module. The same example can be written as:
import types
class A: pass
A.__mul__ = types.MethodType(operator.mul, None, A)
If this still looks essentially like an indirect way of using the new module,
here is another example:
class A(str): __get__ = getattr
a = A('a')
A.a = a
a.a
Or, as I just found out, new-style classes are again vulnerable to the older
example based __call__, which was fixed for old-style classes:
class A(object): pass
A.__call__ = A()
A()()
I'm not denying that these examples look convoluted :-)
My point here is that we can basically build a lot of examples based only on
core (if not necessarily widely understood) language features. It appears to
go against the basic hope that CPython cannot be crashed as long as you don't
use features explicitely marked as dangerous.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-19 02:02
Message:
Logged In: YES
user_id=593130
On Windows, this caused the interactive window to just
disappear.so I suspect something similar occurred.
New is a known dangerous, use at your own risk, implementation
specific module whose use, like byte code hacking, is outside
the language proper. Both bypass normal object creation syntax
and its checks and both can create invalid objects. A hold-your-
hand inplementation would not give such access to internals.
Lib Ref 3.28 says "This module provides a low-level interface to
the interpreter, so care must be exercised when using this
module. It is possible to supply non-sensical arguments which
crash the interpreter when the object is used." Should more or
different be said?
If not, I suspect this should be closed as 'won't fix', as in 'won't
remove the inherently dangerous new module'.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1
Bugs item #1178484, was opened at 2005-04-07 14:33
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&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: Accepted
Priority: 5
Submitted By: Timo Linna (tilinna)
Assigned to: Martin v. Löwis (loewis)
Summary: Erroneous line number error in Py2.4.1
Initial Comment:
For some reason Python 2.3.5 reports the error in the
following program correctly:
File "C:\Temp\problem.py", line 7
SyntaxError: unknown decode error
..whereas Python 2.4.1 reports an invalid line number:
File "C:\Temp\problem.py", line 2
SyntaxError: unknown decode error
- problem.py starts -
# -*- coding: ascii -*-
"""
Foo bar
"""
# Ä is not allowed in ascii coding
- problem.py ends -
Without the encoding declaration both Python versions
report the usual deprecation warning (just like they
should be doing).
My environment: Windows 2000 + SP3.
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2005-05-19 21:06
Message:
Logged In: YES
user_id=89016
> Walter, as I've said before: I know that you need buffering
> for the UTF-x readline support, but I don't see a
> requirement for it in most of the other codecs
The *charbuffer* is required for readline support, but the
*bytebuffer* is required for any non-charmap codec.
To have different buffering modes we'd either need a flag in
the StreamReader or use different classes, i.e. a class
hierarchy like the following:
StreamReader
UnbufferedStreamReader
CharmapStreamReader
ascii.StreamReader
iso_8859_1.StreamReader
BufferedStreamReader
utf_8.StreamReader
I don't think that we should introduce such a big change in
2.4.x. Furthermore there is another problem: The 2.4
buffering code automatically gives us universal newline
support. If you have a file foo.txt containing "a\rb", with
Python 2.4 you get:
>>> list(codecs.open("foo.txt", "rb", "latin-1"))
[u'a\r', u'b']
But with Python 2.3 you get:
>>> list(codecs.open("foo.txt", "rb", "latin-1"))
[u'a\rb']
If we would switch to the old StreamReader for the charmap
codecs, suddenly the stream reader for e.g. latin-1 and
UTF-8 would behave differently. Of course we could change
the buffering stream reader to only split lines on "\n", but
this would change functionality again.
> Your argument about applications making implications on the
> file position after having used .readline() is true, but
> still many applications rely on this behavior which is not
> as far fetched as it may seem given that they normally only
> expect 8-bit data.
If an application doesn't mix calls to read() with calls to
readline() (or different size values in these calls), the
change in behaviour from 2.3 to 2.4 shouldn't be this big.
No matter what we decide for the codecs, the tokenizer is
broken and should be fixed.
> Wouldn't it make things a lot safer if we only use buffering
> per default in the UTF-x codecs and revert back to the old
> non-buffered behavior for the other codecs which has worked
> well in the past ?!
Only if we'd drop the additional functionality added in 2.4.
(universal
newline support, the chars argument for read() and the
keepends argument for readline().), which I think could only
be done for 2.5.
> About your patch:
>
> * Please explain what firstline is supposed to do
> (preferably in the doc-string).
OK, I've added an explanation in the docstring.
> * Why is firstline always set in .readline() ?
firstline is only supposed to be used by readline(). We could
rename the argument to _firstline to make it clear that this is
a private parameter, or introduce a new method _read() that
has a firstline parameter. Then read() calls _read() with
firstline==False and readline() calls _read() with
firstline==True.
The purpose of firstline is to make sure that if an input
stream has
its first decoding error in line n, that the
UnicodeDecodeError will only be raised by the n'th call to
readline().
> * Please remove the print repr()
OK, done.
> * You cannot always be sure that exc has a .start attribute,
> so you need to accomocate for this situation as well
I don't understand that. A UnicodeDecodeError is created by
PyUnicodeDecodeError_Create() in exceptions.c, so any
UnicodeDecodeError instance without a start attribute would
be severely broken.
Thanks for reviewing the patch.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-05-18 11:31
Message:
Logged In: YES
user_id=38388
Walter, as I've said before: I know that you need buffering
for the UTF-x readline support, but I
[ python-Bugs-1178145 ] urllib2.py assumes 206 is an error
Bugs item #1178145, was opened at 2005-04-06 23:52 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178145&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.py assumes 206 is an error Initial Comment: I'm writting code that uses the Range header. The correct response is 206, but the urllib2.py is coded to treat any code that is not 200 as error. The correct code needs to treat 200 to 299 as success. The attached patch fixes the problem. -- Comment By: John J Lee (jjlee) Date: 2005-05-19 20:07 Message: Logged In: YES user_id=261020 Please close: this is already fixed in 2.4. -- Comment By: Jim Jewett (jimjjewett) Date: 2005-04-08 17:17 Message: Logged In: YES user_id=764593 Please re-attach. SF didn't get the file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178145&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175848 ] poorly named variable in urllib2.py
Bugs item #1175848, was opened at 2005-04-03 16:26 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175848&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: poorly named variable in urllib2.py Initial Comment: This is kind of trivial, but in urllib2.OpenerDirector.__init__, the local variable "server_version" is poorly named. The name makes it sound like it's the version of the HTTP (or whatever) server we're talking to. How about client_version or library_version or module_version? -- Comment By: John J Lee (jjlee) Date: 2005-05-19 20:10 Message: Logged In: YES user_id=261020 My, you're picky. ;-) Yes, that does seem a poor name, +1 on changing it to client_version. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175848&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1167397 ] Python 2.4 causes BitTorrent 3.4.2 failure
Bugs item #1167397, was opened at 2005-03-21 09:37 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167397&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: Andrew P. Lentvorski, Jr. (bsder) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 causes BitTorrent 3.4.2 failure Initial Comment: The following failure messages gets dumped out of BitTorrent 3.4.2 when run against Python 2.4: Traceback (most recent call last): File "/usr/local/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/local/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "/home/andrewl/python/lib/python2.4/site-packages/BitTorrent/Rerequester.py", line 84, in rerequest h = urlopen(url) 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 468, in http_response code, msg, hdrs = response.code, response.msg, response.info() AttributeError: addinfourldecompress instance has no attribute 'code' -- Comment By: John J Lee (jjlee) Date: 2005-05-19 20:18 Message: Logged In: YES user_id=261020 This is indeed http://python.org/sf/852995 again (the yum package manager bug). I don't think this is a Python bug, though it's possible a patch could insulate users from this change (even though the change was not to a public API). My detailed comments on the corresponding yum bug are here: https://bugzilla.redhat.com/beta/show_bug.cgi?id=138535#c44 Unless it's very new, addinfourldecompress is from BitTorrent, not Python. -- Comment By: Andrew P. Lentvorski, Jr. (bsder) Date: 2005-03-21 20:44 Message: Logged In: YES user_id=752864 The same BitTorrent version works just fine under 2.3.5. addinfourldecompress is a BitTorrent object which inherits from Python's addinfourl in urllib.py. The following comment was found in a patch that attempted to work around the issue: # As of Python 2.4 http_open response also has 'code' and 'msg' # members, and HTTPErrorProcessor breaks if they don't exist. This problem has been cited in a couple of different contexts. I saw it in a bug report for bittornado on FreeBSD. I also saw it in a RedHat list concerning breakage in the yum utility. Annoyingly, nobody seems to have filed it upstream with the Python folks. -- Comment By: Brett Cannon (bcannon) Date: 2005-03-21 14:55 Message: Logged In: YES user_id=357491 Does this happen if the exact same files are run in 2.3? I can't find addinfourldecompress in Python; is it a BitTorrent class? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167397&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153027 ] http_error_302() crashes with 'HTTP/1.1 400 Bad Request
Bugs item #1153027, was opened at 2005-02-27 20:16
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153027&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: pristine777 (pristine777)
Assigned to: Nobody/Anonymous (nobody)
Summary: http_error_302() crashes with 'HTTP/1.1 400 Bad Request
Initial Comment:
I was able to get to a website by using both IE and
FireFox but my Python code kept giving HTTP 400 Bad
request error. To debug, I set set_http_debuglevel(1) as
in the following code:
hh = urllib2.HTTPHandler()
hh.set_http_debuglevel(1)
opener = urllib2.build_opener
(hh,urllib2.HTTPCookieProcessor(self.cj))
The printed debug messages show that this crash
happens when there is a space in the redirected
location. Here's a cut-and-paste of the relevant debug
messages (note the line starting with send that
http_error_302 is sending):
reply: 'HTTP/1.1 302 Moved Temporarily\r\n'
header: Connection: close
header: Date: Sun, 27 Feb 2005 19:52:51 GMT
header: Server: Microsoft-IIS/6.0
<---other header data-->
send: 'GET /myEmail/User?asOf=02/26/2005 11:38:12
PM&
ddn=87cb51501730
<---remaining header data-->
reply: 'HTTP/1.1 400 Bad Request\r\n'
header: Content-Type: text/html
header: Date: Sun, 27 Feb 2005 19:56:45 GMT
header: Connection: close
header: Content-Length: 20
To fix this, I first tried to encode the redirected location
in the function http_error_302() in urllib2 using the
methods urllib.quote and urllib.urlencode but to no avail
(they encode other data as well).
A temporary solution that works is to replace any space
in the redirected URL by'%20'. Below is a snippet of the
function http_error_302 in urllib2 with this suggested fix:
def http_error_302(self, req, fp, code, msg, headers):
# Some servers (incorrectly) return multiple
Location headers
# (so probably same goes for URI). Use first
header.
if 'location' in headers:
newurl = headers.getheaders('location')[0]
elif 'uri' in headers:
newurl = headers.getheaders('uri')[0]
else:
return
newurl=newurl.replace(' ','%20') # <<< TEMP FIX -
inserting this line temporarily fixes this problem
newurl = urlparse.urljoin(req.get_full_url(), newurl)
<--- remainder of this function -->
Thanks!
--
Comment By: John J Lee (jjlee)
Date: 2005-05-19 20:30
Message:
Logged In: YES
user_id=261020
Sure, but if Firefox and IE do it, probably we should do the
same.
I think cookielib.escape_path(), or something similar
(perhaps without the case normalisation) is probably the
right thing to do. That's not part of any documented API; I
suppose that function or a similar one should be added to
module urlparse, and used by urllib2 and urllib when
redirecting.
--
Comment By: Jeff Epler (jepler)
Date: 2005-03-01 17:41
Message:
Logged In: YES
user_id=2772
When the server sends the 302 response with 'Location:
http://example.com/url%20with%20whitespace', urllib2 seems
to work just fine.
I believe based on reading rfc2396 that a URL that contains
spaces must contain quoted spaces (%20) not literal spaces,
because space is not an "unreserved character" [2.3] and
"[d]ata must be escaped if it does not have a representation
using an unreserved character" [2.4].
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153027&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1152723 ] urllib2 dont respect debuglevel in httplib
Bugs item #1152723, was opened at 2005-02-27 02:49
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152723&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: abbatini (abbatini)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 dont respect debuglevel in httplib
Initial Comment:
It is common habit to see http headers:
>>> import httplib
>>> httplib.HTTPConnection.debuglevel = 1
>>> import urllib
>>> feeddata =
urllib.urlopen('http://diveintomark.org/xml/atom.xml').read()
but this dont work with import urllib2 with python 2.4
In rev 1.57 was intoduced code to AbstractHTTPHandler class
that prevent above mentioned construction.
Init method always set debuglevel=0 then do_open method
always do:
h.set_debuglevel(self._debuglevel)
after instantiating HTTPConnection class.
Regards
--
Comment By: John J Lee (jjlee)
Date: 2005-05-19 20:40
Message:
Logged In: YES
user_id=261020
The .set_debuglevel() method allows debugging
per-HTTPConnection when using urllib2 (instead of turning on
debug prints for *all* HTTPConnection instances).
Since this is just turns on some debug prints, I don't see
any great need to contort the code and/or confuse people
further by attempting to "fix" this.
--
Comment By: abbatini (abbatini)
Date: 2005-02-27 02:57
Message:
Logged In: YES
user_id=1227778
of course:
# h.set_debuglevel(self._debuglevel)
work very well, but i dont know reason
this code was introduced,
maybe forgotten code since development
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1152723&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1070735 ] urllib2 authentication redirection error(?)
Bugs item #1070735, was opened at 2004-11-22 02:01 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1070735&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Allan B. Wilson (allanbwilson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 authentication redirection error(?) Initial Comment: I am trying to use urllib2 to retrieve a page from a site requiring authentication. I supply the authentication parameters, which succeed, and *a* page is returned -- but not the page I originally requested. As it turns out, the authentication is handled at a completely different URL (actually a different domain); I can confirm this by not supplying authentication data, because I see a 302 earlier in the traceback when authentication fails. What I think is happening is that the redirect happens to the authentication site, but the original URL that I wanted has been forgotten. The page I get back is the default page for the original (now authenticated) site, not the page itself, which is deeper down in the site hierarchy. Sorry, I can't supply a patch! Thanks -- Comment By: John J Lee (jjlee) Date: 2005-05-19 20:48 Message: Logged In: YES user_id=261020 Allan, unfortunately there's no way of investigating this without a running script that demonstrates the problem. Please supply one, or close the bug. Thanks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1070735&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1205239 ] Let shift operators take any integer value
Feature Requests item #1205239, was opened at 2005-05-19 19:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&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: None Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Let shift operators take any integer value Initial Comment: Let: 1 >> -4 be interpreted as: 1 << 4 This should be easy to do. It would be somewhat helpful for bit manipulations and multiplying by powers of two. Without the change, my code is laced with sections like: if y > 0: z = x << y else: z = x >> -y This is ugly and slow compared to a straight: z = x << y There is a precedent. See what is done with negative list indices for comparison. It saves even less code with x[len (x)-i] becoming x[i]. The reason for doing it is code simplication and clarity. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1205239&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-971965 ] urllib2 raises exception with non-200 success codes.
Bugs item #971965, was opened at 2004-06-13 05:00
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971965&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ed Watkeys (edw)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 raises exception with non-200 success codes.
Initial Comment:
If a server returns a code other than 200, specifically 201
(Created), urllib2.urlopen will raise an HTTPError exception. I ran
into this while implementing an Atom API client, which solicits 201
responses from the server when submitting a blog post.
File "/usr/local/lib/python2.3/urllib2.py", line 129, in urlopen
return _opener.open(url, data)
File "/usr/local/lib/python2.3/urllib2.py", line 326, in open
'_open', req)
File "/usr/local/lib/python2.3/urllib2.py", line 306, in _call_chain
result = func(*args)
File "/usr/local/lib/python2.3/urllib2.py", line 901, in http_open
return self.do_open(httplib.HTTP, req)
File "/usr/local/lib/python2.3/urllib2.py", line 895, in do_open
return self.parent.error('http', req, fp, code, msg, hdrs)
File "/usr/local/lib/python2.3/urllib2.py", line 352, in error
return self._call_chain(*args)
File "/usr/local/lib/python2.3/urllib2.py", line 306, in _call_chain
result = func(*args)
File "/usr/local/lib/python2.3/urllib2.py", line 412, in
http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 201: Created
--
Comment By: John J Lee (jjlee)
Date: 2005-05-19 21:05
Message:
Logged In: YES
user_id=261020
Before bug 912845 (CVS rev 1.69) added 206 to the list of
response codes considered "successful" by urllib2, I'd
assumed this would never be altered, for
backwards-compatibility reasons.
Note that this behaviour can be configured by module users,
since HTTPError exceptions support the urllib2 response
interface. This can be done by replacing
HTTPErrorProcessor, or by replacing HTTPDefaultErrorHandler,
or catching the exception "manually".
But maybe since the 206 issue was considered a valid bug
fix, this is OK too.
If so, it would be best if the other 20x responses were also
considered at the same time.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971965&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-944407 ] No documentation for urllib2 exception classes
Bugs item #944407, was opened at 2004-04-29 12:38 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944407&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No documentation for urllib2 exception classes Initial Comment: There's not even reference documentation for the exceptions used by urllib2. Documentation of what these are, how you're supposed to handle them and what attributes you're supposed to play with would be very handy. I guess I'll just have to try and glean something from the source :-S -- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:12 Message: Logged In: YES user_id=261020 This is not correct, these exceptions are documented. (from http://docs.python.org/lib/module-urllib2.html) The following exceptions are raised as appropriate: exception URLError The handlers raise this exception (or derived exceptions) when they run into a problem. It is a subclass of IOError. exception HTTPError A subclass of URLError, it can also function as a non-exceptional file-like return value (the same thing that urlopen() returns). This is useful when handling exotic HTTP errors, such as requests for authentication. exception GopherError A subclass of URLError, this is the error raised by the Gopher handler. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944407&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-844336 ] urllib2 fails its builtin test
Bugs item #844336, was opened at 2003-11-18 12:32 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 fails its builtin test Initial Comment: >python -u "ftplib.py" Traceback (most recent call last): File "ftplib.py", line 803, in ? test() File "ftplib.py", line 762, in test while sys.argv[1] == '-d': IndexError: list index out of range >Exit code: 1 >python -u "urllib2.py" gopher://gopher.lib.ncsu.edu/11/library/stacks/Alex socket.error: (7, 'getaddrinfo failed') gopher://gopher.vt.edu:10010/10/33 socket.error: (7, 'getaddrinfo failed') file:/etc/passwd Traceback (most recent call last): File "urllib2.py", line 1154, in ? f = urlopen(url, req) File "urllib2.py", line 136, in urlopen return _opener.open(url, data) File "urllib2.py", line 333, in open '_open', req) File "urllib2.py", line 313, in _call_chain result = func(*args) File "urllib2.py", line 928, in file_open return self.open_local_file(req) File "urllib2.py", line 943, in open_local_file stats = os.stat(localfile) OSError: [Errno 2] No such file or directory: '\etc\passwd' >Exit code: 1 -- Comment By: John J Lee (jjlee) Date: 2005-05-19 21:22 Message: Logged In: YES user_id=261020 This should be closed: this issue was resolved by patch 852995. -- Comment By: John J Lee (jjlee) Date: 2003-12-08 00:17 Message: Logged In: YES user_id=261020 Sorry, last comment not very useful. I think this should be closed. Two real problems: 1. urllib2.urlopen incorrectly raises OSError instead of URLError. This is already detected by my unit tests (852995), and I'll file a separate bug for this later (when/if 852995 is resolved). 2. Would be nice if urllib2's functional tests used PyUnit (so it is clear which tests are passing or failing), and worked on Windows. Again, I'll submit a separate patch. To the bug poster: 0. ftplib is not urllib2, please report bugs separately. 1. You're not invoking ftplib's test program correctly. It seems to work, at least partially: python ftplib.py ftp.python.org /pub/www.python.org/index.html 2. It seems you're using Windows, so you shouldn't expect opening /etc/password to work (though the test shouldn't crash as it does, of course, and it should work on Windows, and it should give an indication of pass/fail). -- Comment By: John J Lee (jjlee) Date: 2003-12-03 19:40 Message: Logged In: YES user_id=261020 It is broken. I'd like to know where functional tests officially live before fixing it. I'll ask on python-dev... -- Comment By: Colin J. Williams (cjwhrh) Date: 2003-11-18 22:04 Message: Logged In: YES user_id=285587 This is a response to quiver. Thanks for pointing out the correct usage of ftlib, I am slowly sorting out how to use ftplib from a script. Unfortunately my report did not make it clear that there is a problem with the operation of the test function. Usually, a test function gives some assurance that the main code of the module is functional. In this case, the test fails. That, I suggest, indicates a bug. The bug could be in test function or the module being exercised. You are probably right that a host needs to be specified. I suggest that the test function should be responsible for this. Incidentally, it would be very helpful to the potential user if the documentation made the names and roles of the various cmds's clearer. -- Comment By: George Yoshida (quiver) Date: 2003-11-18 15:48 Message: Logged In: YES user_id=671362 For the first one, you need to specify a host to run the test. For expample, >python ftplib.py ftp.python.org -l This gives drwxrwxr-x 5 webmaster webmaster 512 Jan 25 2003 pub There is a usage on the test in the script: '''Test program. Usage: ftp [-d] [-r[file]] host [-l[dir]] [-d[dir]] [-p] [file] ...''' I think this is not a bug. For the second one, catching OSError along with IOError might be needed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&group_id=5470 ___ Python-bugs-list mai
[ python-Bugs-745097 ] urllib2 doesn't handle urls without scheme
Bugs item #745097, was opened at 2003-05-28 19:54
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&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: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 doesn't handle urls without scheme
Initial Comment:
urllib2.urlopen does not handle URLs without a scheme, so the
following code will not work:
url = urllib.pathname2url('/etc/passwd')
urllib2.urlopen(url)
The same code does work with urllib.urlopen.
--
Comment By: John J Lee (jjlee)
Date: 2005-05-19 21:24
Message:
Logged In: YES
user_id=261020
Could somebody close this?
--
Comment By: John J Lee (jjlee)
Date: 2003-11-30 23:24
Message:
Logged In: YES
user_id=261020
Is it wise to allow this? Maybe it's unlikely to cause bugs, but
"/etc/passwd" could refer to any URI scheme, not only file:.
Since it seems reasonable to only allow absolute URLs, I think
it's a bad idea to guess the scheme is file: when given a
relative URL.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1046077 ] urllib2: better import ftplib and gopherlib etc late
Bugs item #1046077, was opened at 2004-10-13 10:41
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1046077&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2: better import ftplib and gopherlib etc late
Initial Comment:
I've always trouble shrinking a py2exe'd package,
because of this. its also a speed issue. urllib2 is
most time used only with http(s) ...?
*** urllib2_old.py Tue May 11 16:14:34 2004
--- urllib2.py Wed Oct 13 11:32:44 2004
*** f = urllib2.urlopen('http://www.python.o
*** 88,95
# check digest against correct (i.e. non-apache)
implementation
import base64
- import ftplib
- import gopherlib
import httplib
import inspect
import md5
--- 88,93
*** class FileHandler(BaseHandler):
*** 1009,1014
--- 1007,1013
class FTPHandler(BaseHandler):
def ftp_open(self, req):
+ import ftplib
host = req.get_host()
if not host:
raise IOError, ('ftp error', 'no host given')
*** class CacheFTPHandler(FTPHandler):
*** 1110,1115
--- 1109,1115
class GopherHandler(BaseHandler):
def gopher_open(self, req):
+ import gopherlib
host = req.get_host()
if not host:
raise GopherError('no host given')
--
Comment By: John J Lee (jjlee)
Date: 2005-05-19 21:38
Message:
Logged In: YES
user_id=261020
Since Jeremy doesn't like the idea, this should probably be
closed, but:
Robert re-submitted this as patch 1053150.
--
Comment By: Jeremy Hylton (jhylton)
Date: 2004-11-07 14:42
Message:
Logged In: YES
user_id=31392
I'd rather not move imports from their typical place for a
small performance chance in an unusual use case.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2004-10-15 23:55
Message:
Logged In: YES
user_id=593130
Since you have a patch, this should have been submitted as
a patch rather than a bug. In any case, the patch needs to
be submitted as separate file
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1046077&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1072623 ] FeedParser problem on end boundaries w/o newline
Bugs item #1072623, was opened at 2004-11-24 09:27
Message generated for change (Comment added) made by binaryfeed
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072623&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: Wont Fix
Priority: 5
Submitted By: Tessa Lau (tlau)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: FeedParser problem on end boundaries w/o newline
Initial Comment:
(Python 2.3.4, Linux Debian unstable)
The email module's as_string() method generates
messages that do not include a trailing CRLF on the
last line. This causes problems when Python-created
messages are piped to procmail and delivered to an mbox.
The attached test script illustrates this behavior.
You must have a working procmail configured to deliver
mail to an mbox (the default configuration will work).
If you then read the resulting mailbox with /bin/mail,
it appears as if there is only one message in the
mailbox, instead of two. The second is concatenated on
to the end of the first. The mbox does not contain a
blank line between the first message and the second.
Pop servers require this blank line delimiter between
messages.
You could argue that this is procmail's responsibility,
but as far as I can tell from reading RFC 2822, each
line in an email message must terminate in CRLF, and
Python's email module is violating that spec.
--
Comment By: Jeffrey Wescott (binaryfeed)
Date: 2005-05-19 14:42
Message:
Logged In: YES
user_id=189789
Well, idempotency is completely borked. If I do:
f = file('somemessage')
import email
m = email.message_from_file(f)
f2 = file('newmsg', 'w')
f2.write(m.as_string())
somemessage and newmsg will be *different*.
This is hardly "what goes in equals what goes out".
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-11-30 14:21
Message:
Logged In: YES
user_id=12800
Yep, it was someone else's posting, sorry about that.
As for the trailing newline on non-MIME messages, you will
need to make sure that your payload is terminated with a
newline. Generator won't do that on the basis that
maintaining idempotency (what goes in equals what goes out)
is more important.
--
Comment By: Tessa Lau (tlau)
Date: 2004-11-29 05:23
Message:
Logged In: YES
user_id=112896
It must have been someone else on the email sig; I haven't
posted there recently.
Thanks for the workaround. However, it only fixes the
problem for MIME messages, but not for non-MIME messages.
The second message constructed in my test script still lacks
a trailing newline.
I can work around it after the message is generated by
checking for a final newline on the string and adding it if
it's missing, but that seems clunky.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-11-28 17:10
Message:
Logged In: YES
user_id=12800
I must have been thinking about the message you posted to
the email sig, which uncovered the bug I commented on, and
fixed. In the case of the original bug report, I don't
believe this is fixable. There is, however a simple
workaround for you. In your sample code, set the outer
message's epilogue to the empty string, e.g.:
msg1.epilogue = ''
...
msg2.epilogue = ''
This will cause the Generator to add a newline at the end of
the outer message. We can't make that change in the Message
class because doing so would break inner message flattening.
However, if someone were to come up with a patch that fixes
this problem yet doesn't break any of the 217 tests in the
current test suite, I'd be happy to look at it. As it is,
nothing will be changed for Python 2.4. final.
--
Comment By: Tessa Lau (tlau)
Date: 2004-11-27 16:45
Message:
Logged In: YES
user_id=112896
My original bugreport had to do with email generation, not
parsing. Python seems to be generating email that is not
compliant with the RFC spec. In my situation, parsing is
done by 3rd party programs (procmail and /bin/mail) which
also fail to deal gracefully with the lack of trailing newline.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-11-27 16:03
Message:
Logged In: YES
user_id=12800
Changing the summary of this issue to reflect the real
problem. The attachment 1072623.py illustrates that if the
end boundary of a string being parsed by the FeedParser does
not have a trailing newline, the parser doesn't recognize
this as an end boundary. It just so happens that your
exam
[ python-Bugs-745097 ] urllib2 doesn't handle urls without scheme
Bugs item #745097, was opened at 2003-05-28 20:54
Message generated for change (Comment added) made by jackjansen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&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: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 doesn't handle urls without scheme
Initial Comment:
urllib2.urlopen does not handle URLs without a scheme, so the
following code will not work:
url = urllib.pathname2url('/etc/passwd')
urllib2.urlopen(url)
The same code does work with urllib.urlopen.
--
>Comment By: Jack Jansen (jackjansen)
Date: 2005-05-20 01:53
Message:
Logged In: YES
user_id=45365
I'm not convinced it isn't a bug. I agree that the URL '/etc/passwd' isn't
always a file: url, but I think that in that case urllib2 should get its own
pathname2url() method that returns urls with the file: prefix.
--
Comment By: John J Lee (jjlee)
Date: 2005-05-19 22:24
Message:
Logged In: YES
user_id=261020
Could somebody close this?
--
Comment By: John J Lee (jjlee)
Date: 2003-12-01 00:24
Message:
Logged In: YES
user_id=261020
Is it wise to allow this? Maybe it's unlikely to cause bugs, but
"/etc/passwd" could refer to any URI scheme, not only file:.
Since it seems reasonable to only allow absolute URLs, I think
it's a bad idea to guess the scheme is file: when given a
relative URL.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1082487 ] font lock keyword regular expressions
Bugs item #1082487, was opened at 2004-12-09 15:43 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&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: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Robert Brown (robert-brown) Assigned to: Skip Montanaro (montanaro) Summary: font lock keyword regular expressions Initial Comment: I've noticed that when I use Python mode (alpha 1) with font lock mode, "self" is highlighted in the following line: his_self() The problem appears to be a combination of using "\b" in the Python font lock regular expressions and my .emacs file, which does: (modify-syntax-entry ?\_ "_" py-mode-syntax-table) I do not experience similar problems with highlighting in C mode, but there "\<" and "\>" are used in the font lock regular expressions. Using these word delimiters instead of "\b" appears to fix the problem for me in Python mode. Please wrap keywords with "\<" and "\>" instead of with "\b" in the font lock regular expression. Thanks very much. Bob -- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-19 21:45 Message: Logged In: YES user_id=44345 python-mode.el 4.71. Raymond, sorry for taking so long with this. Please give it a try and let me know how it works. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 21:36 Message: Logged In: YES user_id=80475 Skip, can you field this one? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-967182 ] file("foo", "wU") is silently accepted
Bugs item #967182, was opened at 2004-06-05 12:15
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967182&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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: file("foo", "wU") is silently accepted
Initial Comment:
PEP 278 says at opening a file with "wU" is illegal, yet
file("foo", "wU") passes without complaint. There may
be other flags which the PEP disallows with "U" that need
to be checked.
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-05-19 22:08
Message:
Logged In: YES
user_id=44345
This has been idle for nearly a year with no further response.
Looks good to me. ;-)
Objects/fileobject.c 2.194
Lib/test/test_file.py 1.16
--
Comment By: Skip Montanaro (montanaro)
Date: 2004-06-11 00:44
Message:
Logged In: YES
user_id=44345
So this means I can't be explicit about what to accept, only about
what to reject. Simpler patch attached...
--
Comment By: Tim Peters (tim_one)
Date: 2004-06-07 22:01
Message:
Logged In: YES
user_id=31435
The C standard is open-ended about what a mode string can
contain, and Python has historically allowed users to exploit
platform-specific extensions here. On Windows, at least 't'
and 'c' mean something in mode strings, and 'c' is actually
useful (it forces writes to get committed to disk
immediately). Most platforms ignore characters in mode
strings that they don't understand. This is an exhaustive list
of the mode strings a conforming C implementation must
support (from C99):
"""
r open text file for reading
w truncate to zero length or create text file for writing
a append; open or create text file for writing at end-of-file
rb open binary file for reading
wb truncate to zero length or create binary file for writing
ab append; open or create binary file for writing at end-of-file
r+ open text file for update (reading and writing)
w+ truncate to zero length or create text file for update
a+ append; open or create text file for update, writing at end-
of-file
r+b or rb+ open binary file for update (reading and writing)
w+b or wb+ truncate to zero length or create binary file for
update
a+b or ab+ append; open or create binary file for update,
writing at end-of-file
"""
Implementations are free to support as many more as they
care to.
Guido may be in favor of restricting Python (in 2.4 or 2.5) to
the set of mode strings required by C99, plus those that
make sense with Python's U extension. I think he said
something to that effect in person once. But 'c' is in fact
useful on Windows, and code will break if it's outlawed.
--
Comment By: Skip Montanaro (montanaro)
Date: 2004-06-07 21:10
Message:
Logged In: YES
user_id=44345
Turned out not to be obvious at all (and not related to my
changes). Here's another patch which is cleaner I think.
Would someone take a look at this? My intent is to not
let invalid modes pass silently (as "wU" currently does).
Have I accounted for all the valid mode strings? It has
some semantic changes, so this is not a backport
candidate.
I'm not sure about how 't' is handled. It's only of use on
Windows as I understand it, but I don't see it sucked out
of the mode string on non-Windows platforms, so it must
be silently accepted on Unix and Mac. (Can someone
confirm this?)
--
Comment By: Skip Montanaro (montanaro)
Date: 2004-06-05 14:51
Message:
Logged In: YES
user_id=44345
Here's a first cut patch - test suite fails though - must be
something obvious...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967182&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-861340 ] UnboundLocalError in cgitb.py
Bugs item #861340, was opened at 2003-12-16 17:09
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&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: Out of Date
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Skip Montanaro (montanaro)
Summary: UnboundLocalError in cgitb.py
Initial Comment:
Here's the exception:
Exception
return cgitb.text((E, e, tb)).rstrip('\r\n')
File "/usr/lib/python2.3/cgitb.py", line 197, in text
vars = scanvars(reader, frame, locals)
File "/usr/lib/python2.3/cgitb.py", line 76, in scanvars
parent = value
UnboundLocalError: local variable 'value' referenced
before assignment
And here's the code:
if lasttoken == '.':
if parent is not __UNDEF__:
value = getattr(parent, token, __UNDEF__)
vars.append((prefix + token, prefix, value))
else:
where, value = lookup(token, frame, locals)
vars.append((token, where, value))
elif token == '.':
prefix += lasttoken + '.'
parent = value
If lasttoken is '.' and parent is __UNDEF__, value doesn't
get set. I'd offer a patch, but I really have no idea what this
code is doing and so don't know what to set value to.
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-05-19 22:26
Message:
Logged In: YES
user_id=44345
Looks like this was fixed at some point. The local variable value is
clearly initialized in scanvars() at this point.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-18 17:32
Message:
Logged In: YES
user_id=33168
Jeremy, that's still not enough to reproduce the bug. What
exception was thrown by the code below and from where? What
were the values of bugs, searchstr, and keywords? What are
the definitions for utils.pluralize() and utils.commaAndify()?
--
Comment By: Jeremy Fincher (jemfinch)
Date: 2003-12-18 17:02
Message:
Logged In: YES
user_id=99508
The code that caused the raised exception (which subsequently
triggered the exception in cgitb) was this:
outputstr = '%d %s match \'%s\' (%s):' % (len(bugs), \
utils.pluralize(len(bugs), 'bug'),
searchstr, utils.commaAndify(keywords, And='AND'))
That's actually from the diff where I changed it to be a bit more
idiomatic :) It wasn't my code, I promise!
--
Comment By: Jeremy Fincher (jemfinch)
Date: 2003-12-18 16:56
Message:
Logged In: YES
user_id=99508
To be honest, it's just something I ran into in my own test suite
when my exception-handling logging code caught an exception I
didn't expect to get raised. Since I have no idea what the code in
cgitb that's raising the exception is actually doing, I really don't
know how to begin to try and narrow it down to a test case.
--
Comment By: Skip Montanaro (montanaro)
Date: 2003-12-18 11:31
Message:
Logged In: YES
user_id=44345
I pulled scanvars() and lookup() out into a separate file and
instrumented things a little. From staring at the code I thought
that perhaps it didn't handle the case where the line starts with
a dot separating an object and its attribute. I can't provoke a
failure in that situation though. See attached lookup.py.
Jeremy, can you fiddle it to make it fail?
--
Comment By: Skip Montanaro (montanaro)
Date: 2003-12-18 10:13
Message:
Logged In: YES
user_id=44345
Sorry, I have no idea what it does either. I'll look into it a bit,
but don't expect a miracle. :-(
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-18 09:02
Message:
Logged In: YES
user_id=33168
Jeremy, can you attach a complete test case?
Skip, I realize you didn't write the scanvars code (Ping
did), but you did add text. So maybe you have an idea.
>From a brief scan, it looks like if value is initialized to
None, the code might work.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-944407 ] No documentation for urllib2 exception classes
Bugs item #944407, was opened at 2004-04-29 11:38 Message generated for change (Settings changed) made by fresh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944407&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No documentation for urllib2 exception classes Initial Comment: There's not even reference documentation for the exceptions used by urllib2. Documentation of what these are, how you're supposed to handle them and what attributes you're supposed to play with would be very handy. I guess I'll just have to try and glean something from the source :-S -- >Comment By: Chris Withers (fresh) Date: 2005-05-20 05:54 Message: Logged In: YES user_id=24723 True enough, I guess that some time in the last year this got updated ;-) -- Comment By: John J Lee (jjlee) Date: 2005-05-19 20:12 Message: Logged In: YES user_id=261020 This is not correct, these exceptions are documented. (from http://docs.python.org/lib/module-urllib2.html) The following exceptions are raised as appropriate: exception URLError The handlers raise this exception (or derived exceptions) when they run into a problem. It is a subclass of IOError. exception HTTPError A subclass of URLError, it can also function as a non-exceptional file-like return value (the same thing that urlopen() returns). This is useful when handling exotic HTTP errors, such as requests for authentication. exception GopherError A subclass of URLError, this is the error raised by the Gopher handler. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944407&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
