[ python-Bugs-1612729 ] webchecker/urllib chokes on 404 pages
Bugs item #1612729, was opened at 2006-12-10 19:35
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612729&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: Demos and Tools
Group: Python 2.5
>Status: Closed
>Resolution: Duplicate
Priority: 7
Private: No
Submitted By: Fredrik Lundh (effbot)
Assigned to: Nobody/Anonymous (nobody)
Summary: webchecker/urllib chokes on 404 pages
Initial Comment:
platform: standard Python 2.5 on Windows XP.
webchecker chokes on reponse code 404, which is a bit unfortunate...
the error occurs deep down in urllib, but a plain urllib request to the same
page don't result in the same errors, so it's probably related to how
webchecker is using the library.
here's an example:
C:\Python25\Tools\webchecker> python webchecker.py http://www.python.org/foo
webchecker version 50851
Round 1 (1 total, 1 to do, 0 done, 0 bad)
No need to save checkpoint
Traceback (most recent call last):
File "webchecker.py", line 892, in
main()
File "webchecker.py", line 222, in main
c.run()
File "webchecker.py", line 349, in run
self.dopage(url)
File "webchecker.py", line 404, in dopage
page = self.getpage(url_pair)
File "webchecker.py", line 509, in getpage
text, nurl = self.readhtml(url_pair)
File "webchecker.py", line 523, in readhtml
f, url = self.openhtml(url_pair)
File "webchecker.py", line 531, in openhtml
f = self.openpage(url_pair)
File "webchecker.py", line 543, in openpage
return self.urlopener.open(url)
File "c:\python25\lib\urllib.py", line 190, in open
return getattr(self, name)(url)
File "c:\python25\lib\urllib.py", line 334, in open_http
return self.http_error(url, fp, errcode, errmsg, headers)
File "c:\python25\lib\urllib.py", line 351, in http_error
return self.http_error_default(url, fp, errcode, errmsg, headers)
File "c:\python25\lib\urllib.py", line 357, in http_error_default
raise IOError, ('http error', errcode, errmsg, headers)
TypeError: EnvironmentError expected at most 3 arguments, got 4
running the same test under Python 2.4 works fine:
C:\python24\Tools\webchecker>python webchecker.py http://www.python.org/foo
webchecker version 36560
Round 1 (1 total, 1 to do, 0 done, 0 bad)
Error ('http error', 404, 'Not Found')
HREF http://www.python.org/foo
from
Final Report (1 total, 0 to do, 1 done, 1 bad)
Error Report:
Error in
HREF http://www.python.org/foo
msg ('http error', 404, 'Not Found')
Saving checkpoint to @webchecker.pickle ...
Done.
Use ``webchecker.py -R'' to restart.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-12-11 10:25
Message:
Logged In: YES
user_id=849994
Originator: NO
This is a known issue (another exception object rewrite relic) and has
been fixed as response to bug #1566800.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612729&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1613059 ] lambda tuple parameter bus error
Bugs item #1613059, was opened at 2006-12-11 21:52 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=1613059&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bruce Cropley (cropley_b) Assigned to: Nobody/Anonymous (nobody) Summary: lambda tuple parameter bus error Initial Comment: Python 2.5c1 (r25c1:51305, Aug 17 2006, 10:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> lambda ((a,b)): 1 [... popped up windows crash reporting dialog] Same with: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin >>> lambda ((a,b)): 1 Bus error However it works with 2.4.1 and 2.3.5 on OSX and on 2.3.3 and 2.4 on Windows, e.g.: PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32. Portions Copyright 1994-2001 Mark Hammond ([EMAIL PROTECTED]) - see 'Help/About PythonWin' for further copyright information. >>> lambda ((a,b)): 1 at 0x00AC48B0> >>> f = lambda ((a,b)): 1 >>> assert f((1,2)) == 1 >>> The workaround is to remove the unnecessary parentheses around the lambda's tuple of parameters: >>> f = lambda (a,b): 1 Thanks! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613059&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1613059 ] lambda tuple parameter bus error
Bugs item #1613059, was opened at 2006-12-11 10:52 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613059&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.5 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Bruce Cropley (cropley_b) Assigned to: Nobody/Anonymous (nobody) Summary: lambda tuple parameter bus error Initial Comment: Python 2.5c1 (r25c1:51305, Aug 17 2006, 10:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> lambda ((a,b)): 1 [... popped up windows crash reporting dialog] Same with: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin >>> lambda ((a,b)): 1 Bus error However it works with 2.4.1 and 2.3.5 on OSX and on 2.3.3 and 2.4 on Windows, e.g.: PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32. Portions Copyright 1994-2001 Mark Hammond ([EMAIL PROTECTED]) - see 'Help/About PythonWin' for further copyright information. >>> lambda ((a,b)): 1 at 0x00AC48B0> >>> f = lambda ((a,b)): 1 >>> assert f((1,2)) == 1 >>> The workaround is to remove the unnecessary parentheses around the lambda's tuple of parameters: >>> f = lambda (a,b): 1 Thanks! -- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-11 11:34 Message: Logged In: YES user_id=849994 Originator: NO This has already been fixed in SVN, the fix will be part of 2.5.1. Thanks for reporting anyway! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613059&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1613130 ] str.split creates new string even if pattern not found
Bugs item #1613130, was opened at 2006-12-11 14:03
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=1613130&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Nobody/Anonymous (nobody)
Summary: str.split creates new string even if pattern not found
Initial Comment:
Hello,
Several string methods avoid allocating a new string when the operation result
is trivially the same as one of the parameters (e.g. replacing a non-existing
substring). However, split() does not exhibit this optimization, it always
constructs a new string even if no splitting occurs:
$ python
Python 2.5 (r25:51908, Oct 6 2006, 15:22:41)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s = "abcde" * 2
>>> id(s)
3084139400L
>>> id(str(s))
3084139400L
>>> id("" + s)
3084139400L
>>> id(s.strip())
3084139400L
>>> id(s.replace("g", "h"))
3084139400L
>>> [id(x) for x in s.partition("h")]
[3084139400L, 3084271768L, 3084271768L]
>>> [id(x) for x in s.split("h")]
[3084139360L]
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613130&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503765 ] logger.config problems with comma separated lists
Bugs item #1503765, was opened at 2006-06-09 23:04 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: cuppatea (cuppatea) Assigned to: Vinay Sajip (vsajip) Summary: logger.config problems with comma separated lists Initial Comment: Hello, I have noticed a problem when trying to use the config files. If my config file contains a comma separated list, eg: [logger_root] level=DEBUG handlers= h1, h2 Then the logger throws up an error when reading in the config file as the space is included as part of the handler name. I've included a fix for this in the attached config.py file. Please feel free to use it. Hope this helps, adil -- >Comment By: Vinay Sajip (vsajip) Date: 2006-12-11 14:42 Message: Logged In: YES user_id=308438 Originator: NO Applied a modified version of this patch to SVN - trunk and release24-maint. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 06:20 Message: Logged In: YES user_id=849994 Attaching a real patch and assigning to Vinay. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1605110 ] logging %(module)s reporting wrong modules
Bugs item #1605110, was opened at 2006-11-29 09:29
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&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: Pending
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Pieter Zieschang (mad-marty)
Assigned to: Vinay Sajip (vsajip)
Summary: logging %(module)s reporting wrong modules
Initial Comment:
I recently upgraded from python 2.4.2 to 2.4.4
and the logging seems to be working wrong now.
I have a formatter which uses the %(module)s and %(filename)s and the point to
the wrong file/module.
I have some plugins in .py files, which mainly have one class derived from
threading.Thread.
Those classes logging calls will now log as
2006-11-29 10:17:50 - threading.py - threading - INFO - ...
instead of
2006-11-29 10:17:50 - myplugin.py - myplugin - INFO - ...
--
>Comment By: Vinay Sajip (vsajip)
Date: 2006-12-11 15:05
Message:
Logged In: YES
user_id=308438
Originator: NO
I'm not sure this should be treated as a logging bug - after all, psyco is
not part of standard Python and logging is only tested as a part of
standard Python. Possibly this should be logged under psyco rather than
Python logging. Meanwhile, if time permits I will take a look at this.
--
Comment By: Pieter Zieschang (mad-marty)
Date: 2006-12-02 01:09
Message:
Logged In: YES
user_id=1269426
Originator: YES
Hi,
after some investigation, I think I found the source.
Just add 'import psyco; psyco.full()' to test.py aufer imports and you get
the same problem with your example.
It seems, logging is not compatible with the way psyco creates proxy
functions.
Could be that sys._getframe returns something different. - just a guess
But it works with the old logging.
Is there any other information you may want ?
--
Comment By: Vinay Sajip (vsajip)
Date: 2006-11-30 09:18
Message:
Logged In: YES
user_id=308438
Originator: NO
I need more information. For example (N.B. lines may wrap, please adjust
if copy/pasting the code below):
#-- test.py
import module
import logging
logging.basicConfig(level=logging.DEBUG,
format="%(relativeCreated)-6d %(module)s %(filename)s
%(lineno)d - %(message)s")
logging.getLogger("test").debug("Test starting, about to start
thread...")
threads = module.start()
for t in threads:
t.join()
logging.getLogger("test").debug("All done.")
#-- test.py ends
#-- module.py
import logging
import threading
import random
import time
class MyThread(threading.Thread):
def run(self):
loops = 5
while True:
logging.getLogger("module").debug("Running in thread: %s",
threading.currentThread().getName())
time.sleep(random.random())
loops -= 1
if loops < 0:
break
class MyOtherThread(threading.Thread):
def run(self):
loops = 5
while True:
logging.getLogger("module").debug("Running in thread: %s",
threading.currentThread().getName())
time.sleep(random.random())
loops -= 1
if loops < 0:
break
def start():
t1 = MyThread(name="Thread One")
t2 = MyOtherThread(name="Thread Two")
t1.start()
t2.start()
return t1, t2
#-- module.py ends
When I run test, I get the following output:
15 test test.py 7 - Test starting, about to start thread...
15 module module.py 11 - Running in thread: Thread One
15 module module.py 22 - Running in thread: Thread Two
327module module.py 11 - Running in thread: Thread One
343module module.py 22 - Running in thread: Thread Two
655module module.py 11 - Running in thread: Thread One
780module module.py 22 - Running in thread: Thread Two
1000 module module.py 11 - Running in thread: Thread One
1546 module module.py 22 - Running in thread: Thread Two
1890 module module.py 11 - Running in thread: Thread One
2046 module module.py 11 - Running in thread: Thread One
2218 module module.py 22 - Running in thread: Thread Two
2562 module module.py 22 - Running in thread: Thread Two
3187 test test.py 11 - All done.
This is the expected output. Python version used:
ActivePython 2.4.3 Build 12 (ActiveState Software Inc.) based on
Python 2.4.3 (#69, Apr 11 2006, 15:32:42) [MSC v.1310 32 bit (Intel)] on
win32
--
Comment By: Pieter Zieschang (mad-marty)
Date: 2006-11-29 12:02
Message:
Logged In: YES
user_id
[ python-Feature Requests-1612190 ] Py_DEBUG
Feature Requests item #1612190, was opened at 2006-12-09 16:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612190&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: None Priority: 5 Private: No Submitted By: nitro (nitrogenycs) Assigned to: Nobody/Anonymous (nobody) Summary: Py_DEBUG Initial Comment: Hello, I am writing an extension module (Win32, VC8). Of course I need to #include . Now, when _DEBUG is defined in my application Py_DEBUG gets defined as well (in pyconfig.h). I don't want this to happen as I have to link to the python debug library that way. However, I don't want to debug python, I only want to debug my own application. So the automatic definition of Py_DEBUG doesn't seem right. A solution that would be backwards compatible could look like: #ifdef _DEBUG && !defined(Py_NO_DEBUG) # define Py_DEBUG #endif Could something like this be included in python? Note that #undef _DEBUG #include #define _DEBUG does not work as VC8 complains in this case, because some header files had the _DEBUG preprocessor symbol and some didn't. That trick used to work in VC 6 and 7.x. I've seen a lot of people fighting this problem. Another problem that also arises from pyconfig.h is this code: # ifdef _DEBUG # pragma comment(lib,"python24_d.lib") # else I don't think it's clean that python tells my program what to link to. I am the one who should (and wants to) do this via a linker switch. I know that some people probably would regard the code above as a feature, but it's the opposite imo. A backwards compatible change could look like: #ifdef MS_COREDLL # ifndef Py_BUILD_CORE /* not building the core - must be an ext */ # if defined(_MSC_VER) && !defined(Py_NO_AUTOMATIC_MSVC_LINK) /* So MSVC users need not specify the .lib file in their Makefile (other compilers are generally taken care of by distutils.) */ # ifdef _DEBUG # pragma comment(lib,"python24_d.lib") # else # pragma comment(lib,"python24.lib") # endif /* _DEBUG */ # endif /* _MSC_VER */ # endif /* Py_BUILD_CORE */ #endif /* MS_COREDLL */ Thanks, -Matthias -- >Comment By: Martin v. Löwis (loewis) Date: 2006-12-11 20:09 Message: Logged In: YES user_id=21627 Originator: NO You should just not define _DEBUG then. You don't need to define _DEBUG to perform debugging; instead, _DEBUG requests that the debug version of the MS CRT is linked to your application. As mixing different CRTs (e.g. debug and non-debug) in a single application can cause crashes, you *must* use a python2x.dll that is linked with the debug CRT; this will be python2x_d.dll. So no, something like this should not be added to Python. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612190&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1613479 ] pydoc info for a package doesn't list all package contents
Bugs item #1613479, was opened at 2006-12-11 12:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613479&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nishkar Grover (ngrover) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc info for a package doesn't list all package contents Initial Comment: When using pydoc to query a package, a "PACKAGE CONTENTS" list is provided to show the modules and packages that are in that package. That list will be incomplete if we are querying a package that has been split across multiple directories. Suppose you have the following: /first/path/foo/__init__.py /first/path/foo/one.py /second/path/foo/__init__.py /second/path/foo/two.py and sys.path includes /first/path/ and /second/path/. If both of the foo/__init__.py files are empty, then "import foo" will only allow you to import modules from one of those two foo/ directories (whichever is found first in sys.path). However, if we add the following to both foo/__init__.py files, then we can import foo.one and foo.two because "foo" is considered to be a single package split across two directories: from pkgutil import extend_path __path__ = extend_path(__path__, __name__) Please see http://www.python.org/doc/2.4.2/lib/module-pkgutil.html for some related information. On line 1052 of pydoc.py, we have the following: for file in os.listdir(object.__path__[0]): and in that loop we only read the contents of the FIRST directory in the package's __path__. That should be updated to read the contents of ALL directories in the package's __path__. The following change will do that: % diff -w pydoc.py pydoc.py.orig 1052,1054c1052,1053 < for objectDir in object.__path__: < for file in os.listdir(objectDir): < path = os.path.join(objectDir, file) --- > for file in os.listdir(object.__path__[0]): > path = os.path.join(object.__path__[0], file) I've attached that updated pydoc.py file to this submission. Please consider that as a replacement for the existing pydoc.py module that's currently being distributed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613479&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1613573 ] xmlrpclib ServerProxy uses old httplib interface
Bugs item #1613573, was opened at 2006-12-12 12:17 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=1613573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matt Brown (mattgbrown) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib ServerProxy uses old httplib interface Initial Comment: The ServerProxy class of the xmlrpclib module uses the old style HTTP / HTTPS classes of the httplib module rather than the newer HTTPConnection and HTTPConnection classes. The practical result of this is that xmlrpc connections are not able to make use of HTTP/1.1 functionality. Please update the xmlrpclib module to use the newer API provided by httplib so that the advanced functionality of HTTP/1.1 is available. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613573&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1613651 ] recv_into not documented
Bugs item #1613651, was opened at 2006-12-11 18:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613651&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: recv_into not documented Initial Comment: The recv_into socket method does not appear to be documented in the Library Reference. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613651&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
