[ python-Bugs-1367183 ] inspect.getdoc fails on objs that use property for __doc__
Bugs item #1367183, was opened at 2005-11-26 16:42 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&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: Drew Perttula (drewp) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getdoc fails on objs that use property for __doc__ Initial Comment: inspect.getdoc has these lines: if not isinstance(doc, types.StringTypes): return None which interfere with the case where __doc__ is some other thing that has a good __str__. I wanted to make a lazy __doc__ that did an expensive lookup of some external documentation only when it was str()'d, but since doc displayers often (correctly) use inspect.getdoc, they were getting None. I think the intention of the test in getdoc() is to avoid trying string operations on a __doc__ that is None. I think that a more lenient version would allow me to do my fancy docstrings but still solve the '__doc__ is None' problem. Please consider the following patch: if doc is None: return None doc = str(doc) -- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 06:35 Message: Logged In: YES user_id=1344176 It's not a good idea to use properties for __doc__: """ >>> class Foo(object): ...def _get(self): ...return 'the docstring' ...__doc__ = property(_get) ... >>> print Foo().__doc__ the docstring >>> print Foo.__doc__ >>> """ In this light, I don't view inspect.getdoc's lack of support for __doc__-as-property as a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1421513 ] IMPORT PROBLEM: Local submodule shadows global module
Bugs item #1421513, was opened at 2006-02-01 14:48 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=1421513&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: Jens Engel (jens_engel) Assigned to: Nobody/Anonymous (nobody) Summary: IMPORT PROBLEM: Local submodule shadows global module Initial Comment: PYTHON: 2.3, 2.4 PLATFORMS: Solaris, Linux, Cygwin, Win32 Local sister modules seem to hide global ones (of the standard Python library) when import occurs in a submodule. This statement even holds for indirect imports from the standard Python library. FILE STRUCTURE for EXAMPLES: - my/ +-- __init__.py +-- main.py +-- main2.py +-- symbol.py \-- types.py EXAMPLE 1: Local submodule shadows global one. # -- file:my.main.py # COMMAND-LINE: python my/main.py # MY INTENTION: Import standard module "types". import types #< FAILURE: Imports my.types if __name__ == "__main__": print types.StringTypes #< EXCEPTION: StringTypes are not known. # -- FILE-END EXAMPLE 2: Indirect import uses "my.symbol" instead. # -- file:my.main2.py # COMMAND-LINE: python my/main2.py # MY INTENTION: Import standard module "compiler". # NOTE: Module "compiler" imports module "symbol" import compiler #< FAILURE: Imports my.symbol instead if __name__ == "__main__": pass # -- FILE-END NOTE: Module import problems can be better checked with "python -v". I have not found a work-around that let me decide if I want to import the global module or the local one. The only solution seens to be to relocate the module where "__main__" is used to another place where no such import conflict occurs. If my analysis is correct, the "main" module provides another ROOT filesystem for Python libraries that is normally preferred over the PYTHONHOME filesystem. If this is true, module names at this level must be UNIQUE in a GLOBAL namespace (that is only partly under my control) which I consider BAD. NOTE: In C++ if have the "::" prefix to indicate that I want to use the global/default namespace (=module) and not a sub-namespace. I am not aware of such a idom in Python. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1421664 ] [win32] stderr atty encoding not set
Bugs item #1421664, was opened at 2006-02-01 20: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=1421664&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: Snaury (snaury)
Assigned to: Nobody/Anonymous (nobody)
Summary: [win32] stderr atty encoding not set
Initial Comment:
When starting python console application under windows,
output of unicode strings to console fails because of
ansi encoding. I found that in file
Python-2.4.2/Python/sysmodule, _PySys_Init functions,
setting encoding on stderr was forgotten:
#ifdef MS_WINDOWS
if(isatty(_fileno(stdin))){
sprintf(buf, "cp%d", GetConsoleCP());
if (!PyFile_SetEncoding(sysin, buf))
return NULL;
}
if(isatty(_fileno(stdout))) {
sprintf(buf, "cp%d", GetConsoleOutputCP());
if (!PyFile_SetEncoding(sysout, buf))
return NULL;
}
#endif
I think the following lines should be added:
if(isatty(_fileno(stderr))) {
sprintf(buf, "cp%d", GetConsoleOutputCP());
if (!PyFile_SetEncoding(syserr, buf))
return NULL;
}
Otherwise it's inconsistant, as if we set it to sysout,
why not on syserr? And, for example, this code will not
work properly:
#!/usr/bin/env python
# -*- encoding: mbcs -*-
import sys
reload(sys) # bring setdefaultencoding back!
sys.setdefaultencoding("mbcs")
sys.stderr.write(u"\n")
Instead of native text garbage will be printed (if you
change it to sys.stdout, proper text displayed), and
there is no way I know to properly determine and set
encoding just for stderr (file.encoding is read-only,
after all).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421664&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1421664 ] [win32] stderr atty encoding not set
Bugs item #1421664, was opened at 2006-02-01 20:25
Message generated for change (Comment added) made by snaury
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421664&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: Snaury (snaury)
Assigned to: Nobody/Anonymous (nobody)
Summary: [win32] stderr atty encoding not set
Initial Comment:
When starting python console application under windows,
output of unicode strings to console fails because of
ansi encoding. I found that in file
Python-2.4.2/Python/sysmodule, _PySys_Init functions,
setting encoding on stderr was forgotten:
#ifdef MS_WINDOWS
if(isatty(_fileno(stdin))){
sprintf(buf, "cp%d", GetConsoleCP());
if (!PyFile_SetEncoding(sysin, buf))
return NULL;
}
if(isatty(_fileno(stdout))) {
sprintf(buf, "cp%d", GetConsoleOutputCP());
if (!PyFile_SetEncoding(sysout, buf))
return NULL;
}
#endif
I think the following lines should be added:
if(isatty(_fileno(stderr))) {
sprintf(buf, "cp%d", GetConsoleOutputCP());
if (!PyFile_SetEncoding(syserr, buf))
return NULL;
}
Otherwise it's inconsistant, as if we set it to sysout,
why not on syserr? And, for example, this code will not
work properly:
#!/usr/bin/env python
# -*- encoding: mbcs -*-
import sys
reload(sys) # bring setdefaultencoding back!
sys.setdefaultencoding("mbcs")
sys.stderr.write(u"\n")
Instead of native text garbage will be printed (if you
change it to sys.stdout, proper text displayed), and
there is no way I know to properly determine and set
encoding just for stderr (file.encoding is read-only,
after all).
--
>Comment By: Snaury (snaury)
Date: 2006-02-01 20:29
Message:
Logged In: YES
user_id=1197042
Ooops, sorry, in the example it should be:
print >>sys.stderr, u""
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421664&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1421696 ] http response dictionary incomplete
Bugs item #1421696, was opened at 2006-02-01 12:56 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=1421696&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: http response dictionary incomplete Initial Comment: httplib and BaseHTTPServer each maintain their own copy of possible response codes. They don't agree. It looks like the one in httplib is a superset of the one in BaseHTTPServer.BaseHTTPRequestHandler.responses, and httplib is the logical place for it, but (1) They map in opposite directions. (2) The httplib version is just a bunch of names at the module toplevel, with no particular grouping that separates them from random classes, or makes them easy to import as a group. (3) The httplib names are explicitly not exported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421696&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-882297 ] socket's makefile file object doesn't work with timeouts.
Bugs item #882297, was opened at 2004-01-22 18:36
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&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: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket's makefile file object doesn't work with timeouts.
Initial Comment:
Ok, here's what I did:
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.bind(('', 9009))
>>> s.listen(5)
>>> s.accept()
Now, I opened a second Python interpreter in which I
typed this:
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(('localhost', 9009))
In the first interpreter I did this:
>>> s.accept()
(,
('127.0.0.1', 33059))
>>> s1 = _[0]
>>> s1.settimeout(3)
>>> fd = s1.makefile()
Then I tested that the timeout worked correctly. Still
in the first interpreter:
>>> fd.readline()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()
Now, while that was blocking, I did this in the second
interpreter:
>>> s.send('foo')
3
Which caused this in the first interpreter (as
expected, since I didn't send a newline):
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()
While that was blocking, I did this in the second
interpreter:
>>> s.send('bar\n')
4
Finally sending a newline. But lo and behold! In the
first interpreter I got this:
>>> fd.readline()
'bar\n'
Alas, my 'foo' has been lost!
Anyway, the documentation does explicitly state that
the socket should be in blocking mode, *implying* that
it does no buffering, but it doesn't say anything about
timeouts. Ideally, the file object would buffer enough
data until the readline could return meaningfully, but
failing that, the documentation should probably be
updated to mention that timeouts shouldn't be used with
readline on the returned file object.
--
Comment By: John J Lee (jjlee)
Date: 2006-02-01 19:38
Message:
Logged In: YES
user_id=261020
I believe this was fixed in socket.py in rev 32056, closing
bug 707074.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1421811 ] CVS (not SVN) mentioned in Python FAQ
Bugs item #1421811, was opened at 2006-02-01 23:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421811&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: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: CVS (not SVN) mentioned in Python FAQ Initial Comment: http://python.org/doc/faq/general.html 1.1.11 How do I get a beta test version of Python? All releases, including alphas, betas and release candidates, are announced on the comp.lang.python and comp.lang.python.announce newsgroups. All announcements also appear on the Python home page, at http://www.python.org/; an RSS feed of news is available. You can also access the development version of Python through CVS. See http://sourceforge.net/cvs/?group_id=5470 for details. If you're not familiar with CVS, documents such as http://linux.oreillynet.com/pub/a/linux/2002/01/03/cvs_intro.html provide an introduction. last paragraph should be about SVN, not CVS -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421811&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1421814 ] 2.4.1 mentioned in Python FAQ as most stable version
Bugs item #1421814, was opened at 2006-02-01 23:09 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=1421814&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: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 mentioned in Python FAQ as most stable version Initial Comment: http://python.org/doc/faq/general.html 1.2.1 How stable is Python? Very stable. ... The 2.4.1 release is the most stable version at this point in time. Is this info outdated? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421814&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1353433 ] Http redirection error in urllib2.py
Bugs item #1353433, was opened at 2005-11-10 20:25
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353433&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: Thomas Dehn (dehn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Http redirection error in urllib2.py
Initial Comment:
A url request returns a redirect that contains a space ' '
character. Python urllib2.py does not replace this
character with '%20' and fails.
Entering a line after line 507 of:
newurl=re.sub(' ','%20',newurl)
Corrects my problem.
--
Comment By: John J Lee (jjlee)
Date: 2006-02-01 20:28
Message:
Logged In: YES
user_id=261020
The problem is more general, so perhaps:
URLQUOTE_SAFE_URL_CHARS = "!*'();:@&=+$,/?%#[]~"
newurl = urllib.quote(url, URLQUOTE_SAFE_URL_CHARS)
Caveat: I still haven't read RFCs 3986/3987...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353433&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-626543 ] urllib2 doesn't do HTTP-EQUIV & Refresh
Bugs item #626543, was opened at 2002-10-21 21:57 Message generated for change (Settings changed) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626543&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: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't do HTTP-EQUIV & Refresh Initial Comment: I just added support for HTML's META HTTP-EQUIV and zero-time Refresh HTTP headers to my 'ClientCookie' package (which exports essentially a clone of the urllib2 interface that knows about cookies, making use of urllib2 in the implementation). I didn't make a patch for urllib2 itself but it would be easy to do so. I don't plan to do this immediately, but will eventually (assuming Jeremy thinks it's advisible) -- I just wanted to register this fact to prevent duplication of effort. [BTW, this version of ClientCookie isn't on my web page yet -- my motherboard just died.] I'm sure you know this already, but: HTTP-EQUIV is just a way of putting headers in the HEAD section of an HTML document; Refresh is a Netscape 1.1 header that indicates that a browser should redirect after a specified time. Refresh headers with zero time act like redirections. The net result of the code I just wrote is that if you urlopen a URL that points to an HTML document like this: ; you're automatically redirected to "http://acme.com/new_url.htm";. Same thing happens if the Refresh is in the HTTP headers, because all the HTTP-EQUIV headers are treated like real HTTP headers. Refresh with non-zero delay time is ignored (the urlopen returns the document body unchanged and does not redirect, but does still add the Refresh header to the HTTP headers). A few issues: 0) AFAIK, the Refresh header is not specified in any RFC, but only here: http://wp.netscape.com/assist/net_sites/pushpull.html (HTTP-EQUIV seems to be in the HTML 4.0 standard, maybe earlier ones too) 1) Infinite loops should be detected, as for HTTP 30x? Presumably yes. 2) Should add HTTP-EQUIV headers to response object, or just treat them like headers internally? Perhaps it should be possible to get both behaviours? 3) Bug in my implementation: is greedy with reading body data from httplib's file object. John -- >Comment By: John J Lee (jjlee) Date: 2006-02-01 20:31 Message: Logged In: YES user_id=261020 Closing since I no longer intend to contribute this. (I don't want to get involved with HTML parsing in the stdlib!) -- Comment By: John J Lee (jjlee) Date: 2003-10-29 23:27 Message: Logged In: YES user_id=261020 Just an update: - this could now be implemented as a handler (and already is, in my ClientCookie package) using RFE 759792, rather than having to be mixed in with HTTPHandler - the issues I listed in my initial comment, and the backwards-compatibility issue raised by MvL are now resolved - it needs reimplementing using HTMLParser (currently uses htmllib) if it's to go in the standard library; I plan to do this in time for 2.4 -- Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 14:30 Message: Logged In: YES user_id=21627 I would try to subclass HTTPHandler, and then provide a build_opener wrapper that installs this handler instead of the normal http handler (the latter is optional, since the user could just do build_opener(HTTPRefreshHandler)). -- Comment By: John J Lee (jjlee) Date: 2002-10-24 00:20 Message: Logged In: YES user_id=261020 What do you think the solution to the backwards- compatibility problem is? Leave urllib2 as-is? Add a switch to turn it on? Something else? At the moment, I just deal with it in AbstractHTTPHandler. It would be nice to treat it like the other redirections, by writing a RefreshHandler -- this would solve the backwards- compatibility issue. However, OpenerDirector.error always calls http_error_xxx ATM (where xxx is the HTTP error code), so without changing that, I don't think a RefreshHandler is really possible. I suppose the sensible solution is just to make a new HTTPHandler and HTTPSHandler? Can you think of any way in which supporting HTTP-EQUIV would mess up backwards compatibility, assuming the body is unchanged but the headers do have the HTTP-EQUIV headers added? John -- Comment By: Martin v. Löwis (loewis) Dat
[ 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: 2006-02-01 20:34
Message:
Logged In: YES
user_id=261020
Can somebody close this?
--
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-1123695 ] attempting to use urllib2 on some URLs fails starting on 2.4
Bugs item #1123695, was opened at 2005-02-16 06:06
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123695&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: Stephan Sokolow (ssokolow)
Assigned to: Nobody/Anonymous (nobody)
Summary: attempting to use urllib2 on some URLs fails starting on 2.4
Initial Comment:
The following will work correctly on Python 2.3.3 but fails
on Python 2.4
Python 2.4 (#1, Dec 4 2004, 01:33:42)
[GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import urllib2
>>>
urllib2.urlopen('http://www.fanfiction.net/s/636805/10/').read()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/socket.py", line 285, in read
data = self._sock.recv(recv_size)
File "/usr/local/lib/python2.4/httplib.py", line 456, in read
return self._read_chunked(amt)
File "/usr/local/lib/python2.4/httplib.py", line 495, in
_read_chunked
chunk_left = int(line, 16)
ValueError: invalid literal for int():
--
Comment By: John J Lee (jjlee)
Date: 2006-02-01 20:38
Message:
Logged In: YES
user_id=261020
I can't reproduce this.
1. On what OS did you observe the failure?
2. Anybody have another example that does still trigger the bug?
--
Comment By: Wummel (calvin)
Date: 2005-02-16 16:38
Message:
Logged In: YES
user_id=9205
This bug is in httplib.py, and I already submitted patch
900744. I wonder why on Python 2.3 it seems to work though,
it should fail the same way since this bug is also present
in Python 2.3. But it might be some change in urllib2 that
triggers this in Python 2.4 and not in Python 2.3.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123695&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1421839 ] Inconsistency in Programming FAQ
Bugs item #1421839, was opened at 2006-02-01 23:41 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=1421839&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: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency in Programming FAQ Initial Comment: http://python.org/doc/faq/programming.html 1.6.8 How do I create static class data and static class methods? ... Static methods are possible when you're using new-style classes: class C: def static(arg1, arg2, arg3): # No 'self' parameter! ... static = staticmethod(static) - Shouldn't it look like class C(object)? - it would be nice to mention decorators here -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421839&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1123695 ] attempting to use urllib2 on some URLs fails starting on 2.4
Bugs item #1123695, was opened at 2005-02-16 07:06
Message generated for change (Comment added) made by calvin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123695&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: Stephan Sokolow (ssokolow)
Assigned to: Nobody/Anonymous (nobody)
Summary: attempting to use urllib2 on some URLs fails starting on 2.4
Initial Comment:
The following will work correctly on Python 2.3.3 but fails
on Python 2.4
Python 2.4 (#1, Dec 4 2004, 01:33:42)
[GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import urllib2
>>>
urllib2.urlopen('http://www.fanfiction.net/s/636805/10/').read()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/socket.py", line 285, in read
data = self._sock.recv(recv_size)
File "/usr/local/lib/python2.4/httplib.py", line 456, in read
return self._read_chunked(amt)
File "/usr/local/lib/python2.4/httplib.py", line 495, in
_read_chunked
chunk_left = int(line, 16)
ValueError: invalid literal for int():
--
Comment By: Wummel (calvin)
Date: 2006-02-01 23:18
Message:
Logged In: YES
user_id=9205
I added a testcase mockup attachment at patch #900744:
https://sourceforge.net/support/tracker.php?aid=900744
To reproduce with urllib2, start server.py and then execute:
import urllib2
urllib2.urlopen("http://localhost:8000/";).read()
--
Comment By: John J Lee (jjlee)
Date: 2006-02-01 21:38
Message:
Logged In: YES
user_id=261020
I can't reproduce this.
1. On what OS did you observe the failure?
2. Anybody have another example that does still trigger the bug?
--
Comment By: Wummel (calvin)
Date: 2005-02-16 17:38
Message:
Logged In: YES
user_id=9205
This bug is in httplib.py, and I already submitted patch
900744. I wonder why on Python 2.3 it seems to work though,
it should fail the same way since this bug is also present
in Python 2.3. But it might be some change in urllib2 that
triggers this in Python 2.4 and not in Python 2.3.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123695&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 03:49
Message generated for change (Settings changed) made by abbatini
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: Closed
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: 2006-02-01 21:34
Message:
Logged In: YES
user_id=261020
Can somebody close this?
--
Comment By: John J Lee (jjlee)
Date: 2005-05-19 21: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 03: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-1396622 ] TimedRotatingFileHandler midnight rollover time increases
Bugs item #1396622, was opened at 01/04/06 00:25 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&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: Accepted Priority: 5 Submitted By: Andrew Waters (awaters) Assigned to: Vinay Sajip (vsajip) Summary: TimedRotatingFileHandler midnight rollover time increases Initial Comment: When calculating the next rollover time the calculation uses the current time plus the interval. Unless the log file is written exactly at midnight the rollover time becomes the current time + 1 day. So for example, if the log is written at 2:00am then the next rollover time will be 2:00am the following day rather than midnight. -- >Comment By: SourceForge Robot (sf-robot) Date: 02/01/06 16:54 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Vinay Sajip (vsajip) Date: 01/16/06 01:18 Message: Logged In: YES user_id=308438 Fixed the rollover time increase problem (checked into SVN trunk and release24-maint branch). However, DST adjustment has not been done yet. -- Comment By: Josiah Carlson (josiahcarlson) Date: 01/13/06 19:46 Message: Logged In: YES user_id=341410 For this handler, one should also be aware of the fact that when DST changes, the time.timezone doesn't change, so calculation of when midnight actually is (if one does that), may be off by an hour until the daemon restarts. -- Comment By: Neal Norwitz (nnorwitz) Date: 01/04/06 21:46 Message: Logged In: YES user_id=33168 Vinay, any comments? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1396622 ] TimedRotatingFileHandler midnight rollover time increases
Bugs item #1396622, was opened at 2006-01-04 08:25 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&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: Accepted Priority: 5 Submitted By: Andrew Waters (awaters) Assigned to: Vinay Sajip (vsajip) Summary: TimedRotatingFileHandler midnight rollover time increases Initial Comment: When calculating the next rollover time the calculation uses the current time plus the interval. Unless the log file is written exactly at midnight the rollover time becomes the current time + 1 day. So for example, if the log is written at 2:00am then the next rollover time will be 2:00am the following day rather than midnight. -- >Comment By: Michael Hudson (mwh) Date: 2006-02-02 00:59 Message: Logged In: YES user_id=6656 Woah, that's a new one. When did that get set up? -- Comment By: SourceForge Robot (sf-robot) Date: 2006-02-02 00:54 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Vinay Sajip (vsajip) Date: 2006-01-16 09:18 Message: Logged In: YES user_id=308438 Fixed the rollover time increase problem (checked into SVN trunk and release24-maint branch). However, DST adjustment has not been done yet. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-01-14 03:46 Message: Logged In: YES user_id=341410 For this handler, one should also be aware of the fact that when DST changes, the time.timezone doesn't change, so calculation of when midnight actually is (if one does that), may be off by an hour until the daemon restarts. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-05 05:46 Message: Logged In: YES user_id=33168 Vinay, any comments? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1422094 ] email.MIME*.as_string removes duplicate spaces
Bugs item #1422094, was opened at 2006-02-02 13: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=1422094&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: hads (hads) Assigned to: Nobody/Anonymous (nobody) Summary: email.MIME*.as_string removes duplicate spaces Initial Comment: In the following example all of the multiple spaces in the subject will be compressed into one space each. from email.MIMEMultipart import MIMEMultipart outer = MIMEMultipart() outer['Subject'] = "Subjects longer than 68 characters withmultiple spaces get converted toone space." print outer.as_string() Will print: Content-Type: multipart/mixed; boundary="===0820565010==" MIME-Version: 1.0 Subject: Subjects longer than 68 characters with multiple spaces get converted to one space. --===0820565010== --===0820565010==-- -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1422094&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
