[ python-Bugs-1314572 ] Trailing slash redirection for SimpleHTTPServer
Bugs item #1314572, was opened at 2005-10-05 23:49
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1314572&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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Josiah Carlson (josiahcarlson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Trailing slash redirection for SimpleHTTPServer
Initial Comment:
As known by every serious web server developer, the
lack of a trailing slash on direcories can cause some
serious web page loading issues. Take the following
examples...
Let us imagine that: 'http://www.foo.com/foo' points to
a directory containing 'index.html'. A web server
could return the contents of 'index.html', but then any
relative urls would be relative to the / path of the
web server.
A better web server would instead redirect the user to
'http://www.foo.com/foo/'. SimpleHTTPServer does not
do any such redirection, and the documentation for
forcing a client to redirect is difficult to find on
the internet. In the comments I will post a
replacement
SimpleHTTPServer.SimpleHTTPRequestHandler.send_head
method which does automatic trailing slash redirection.
--
>Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-10-06 00:00
Message:
Logged In: YES
user_id=341410
I've attached a file which contains the method, which should
save everyone from having to deal with SF's line wrapping.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-10-05 23:58
Message:
Logged In: YES
user_id=341410
def send_head(self):
"""Common code for GET and HEAD commands.
This sends the response code and MIME headers.
Return value is either a file object (which has to
be copied
to the outputfile by the caller unless the command
was HEAD,
and must be closed by the caller under all
circumstances), or
None, in which case the caller has nothing further
to do.
"""
path = self.translate_path(self.path)
f = None
if os.path.isdir(path):
# Redirect path urls which lack a trailing slash
if not self.path.endswith('/'):
self.send_response(302)
self.send_header("Content-type", "text/html")
self.send_header("Content-Location",
self.path + '/')
self.end_headers()
return StringIO(''%self.path)
for index in "index.html", "index.htm":
index = os.path.join(path, index)
if os.path.exists(index):
path = index
break
else:
return self.list_directory(path)
ctype = self.guess_type(path)
try:
# Always read in binary mode. Opening files in
text mode may cause
# newline translations, making the actual size
of the content
# transmitted *less* than the content-length!
f = open(path, 'rb')
except IOError:
self.send_error(404, "File not found")
return None
self.send_response(200)
self.send_header("Content-type", ctype)
self.send_header("Content-Length",
str(os.fstat(f.fileno())[6]))
self.end_headers()
return f
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1314572&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193099 ] Embedded python thread crashes
Bugs item #1193099, was opened at 2005-04-30 12:03
Message generated for change (Comment added) made by ugodiggi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193099&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
Submitted By: ugodiggi (ugodiggi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Embedded python thread crashes
Initial Comment:
The following code crashes about 1/3 of the times.
My platform is Python 2.4.1 on WXP (I tried the release
version from the msi and the debug version built by me).
I can reproduce the same behavior on another wxp
system, under python 2.4.
The crash happens (in the python thread) while the main
thread is in Py_Finalize.
I traced the crash to _Py_ForgetReference(op) in
object.c at line 1847, where I have op->_ob_prev == NULL.
The open file seems to be the issue, since if I remove
all the references to the file I cannot get the program
to crash.
Cheers and ciao
Ugo
// TestPyThreads.cpp
//
#include // Sleep
#include "Python.h"
int main()
{
PyEval_InitThreads();
Py_Initialize();
PyGILState_STATE main_restore_state =
PyGILState_UNLOCKED;
PyGILState_Release(main_restore_state);
// start the thread
{
PyGILState_STATE state =
PyGILState_Ensure();
int trash = PyRun_SimpleString(
"import thread\n"
"import time\n"
"def foo():\n"
" f =
open('pippo.out', 'w', 0)\n"
" i = 0;\n"
" while 1:\n"
"f.write('%d\n'%i)\n"
"time.sleep(0.01)\n"
"i += 1\n"
"t =
thread.start_new_thread(foo, ())\n"
);
PyGILState_Release(state);
}
// wait 300 ms
Sleep(300);
PyGILState_Ensure();
Py_Finalize();
return 0;
}
--
>Comment By: ugodiggi (ugodiggi)
Date: 2005-10-06 00:29
Message:
Logged In: YES
user_id=1269908
Something changed on the computer I'm testing on, and the
crash happens way less often (say 1/10 of the times in debug
mode, and very rarely in Release mode).
The compiler is MSVC7.1 on WXP, using Python 241
This is the stack of the main thread
7ffe0304()
ntdll.dll!77f5b5d4()
kernel32.dll!77e7a683()
msvcr71d.dll!_close_lk(int fh=0x0003) Line 115 +
0x4aC
msvcr71d.dll!_close(int fh=0x0003) Line 60 + 0x9
C
msvcr71d.dll!_fclose_lk(_iobuf * str=0x1027c898) Line
127 + 0xc C
msvcr71d.dll!fclose(_iobuf * stream=0x1027c898) Line
58 + 0x9C
> python24_d.dll!file_dealloc(PyFileObject *
f=0x00919ec8) Line 308 + 0xd C
python24_d.dll!_Py_Dealloc(_object * op=0x00919ec8)
Line 1870 + 0x7 C
python24_d.dll!frame_dealloc(_frame * f=0x00972960)
Line 394 + 0x67 C
python24_d.dll!_Py_Dealloc(_object * op=0x00972960)
Line 1870 + 0x7 C
python24_d.dll!PyThreadState_Clear(_ts *
tstate=0x00892c88) Line 200 + 0x6c C
python24_d.dll!PyInterpreterState_Clear(_is *
interp=0x00894f48) Line 93 + 0x9 C
python24_d.dll!Py_Finalize() Line 401 + 0x9C
TestPyThreads.exe!main() Line 33 + 0x8 C++
TestPyThreads.exe!mainCRTStartup() Line 259 + 0x19
C
kernel32.dll!77e8141a()
and this is the stack of the other thread (_threadstart)
(the crash is here, where "if (frame->f_exc_type != NULL) "
gets called with frame == NULL)
> python24_d.dll!reset_exc_info(_ts * tstate=0x00892c88)
Line 2861 + 0x3 C
python24_d.dll!PyEval_EvalFrame(_frame *
f=0x00972960) Line 2490 + 0x9 C
python24_d.dll!PyEval_EvalCodeEx(PyCodeObject *
co=0x00943ad0, _object * globals=0x008e3230, _object *
locals=0x, _object * * args=0x008c104c, int
argcount=0x, _object * * kws=0x, int
kwcount=0x, _object * * defs=0x, int
defcount=0x, _object * closure=0x) Line
2730 + 0x9 C
python24_d.dll!function_call(_object * func=0x009431f0,
_object * arg=0x008c1038, _object * kw=0x) Line
553 + 0x40 C
python24_d.dll!PyObject_Call(_object *
func=0x009431f0, _object * arg=0x008c1038, _object *
kw=0x) Line 1751 + 0xf C
python24_d.dll!PyEval_CallObjectWithKeywords(_object
* func=0x009431f0, _object * arg=0x008c1038, _ob
[ python-Bugs-1314519 ] logging run into deadlock in some error handling situation
Bugs item #1314519, was opened at 2005-10-06 05:56
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1314519&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: Accepted
Priority: 5
Submitted By: Wai Yip Tung (tungwaiyip)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging run into deadlock in some error handling situation
Initial Comment:
I've a daemon that pipe stdout and stderr into logging
in order to capture everything it does. It works fine.
However if there is an error throw inside logging, the
error is sent to stderr that got redirect into logging
again. Its seems some lock is not reentrant and it
causes deadlock.
>>> import logging,sys
>>> # a quick and dirty log file object
... class LogFileObj(object):
... def __init__(self,log):
... self.log = log
... def write(self,str):
... self.log.warn(str)
...
>>> # create a logger for stderr
... log = logging.getLogger()
>>>
>>> # for the purpose of showing this bug, output to a
StreamHandler based on stdout
... handler = logging.StreamHandler(sys.stdout)
>>> handler.setFormatter(logging.Formatter('%(asctime)s
%(message)s'))
>>> log.addHandler(handler)
>>>
>>> # redirect stderr to a logger
... sys.stderr = LogFileObj(log)
>>>
>>> # it works!
... print >>sys.stderr, 'hello world'
2005-10-05 22:52:32,391 hello world
2005-10-05 22:52:32,391
>>>
>>> # now put sys.stderr aside
... # use the logger as usual
... log.warn('hello world')
2005-10-05 22:52:32,401 hello world
>>>
>>> # this one has an error in the number of arguments
... log.warn('hello world %s', 1, 2)
When the last statement is ran, it goes into a deadlock.
It seems this can be workaround by using
threading.RLock instead of thread's lock.
>>> # workaround the deadlock by using RLock
... import threading
>>> handler.lock = threading.RLock()
>>> log.warn('hello world %s', 1, 2)
2005-10-05 22:47:46,390 Traceback (most recent call last):
2005-10-05 22:47:46,400 File
"C:\Python24\lib\logging\__init__.py", line 706, in emit
2005-10-05 22:47:46,400 msg = self.format(record)
2005-10-05 22:47:46,400 File
"C:\Python24\lib\logging\__init__.py", line 592, in format
2005-10-05 22:47:46,400 return fmt.format(record)
2005-10-05 22:47:46,400 File
"C:\Python24\lib\logging\__init__.py", line 382, in format
2005-10-05 22:47:46,400 record.message =
record.getMessage()
2005-10-05 22:47:46,400 File
"C:\Python24\lib\logging\__init__.py", line 253, in
getMessage
2005-10-05 22:47:46,400 msg = msg % self.args
2005-10-05 22:47:46,400 TypeError: not all arguments
converted during string formatting
I'm not too familiar with the implementation of
logging. Please keep me posted whether this is a
legitimate workaround.
--
>Comment By: Vinay Sajip (vsajip)
Date: 2005-10-06 07:53
Message:
Logged In: YES
user_id=308438
Yes, the problem is there and the proposed solution seems
fine. Also note that if you set logging.raiseExceptions to
0, then exceptions during emitting are silently ignored
rather than raised.
I will change thread.allocate_lock() -> threading.RLock()
and check into CVS soon, then mark this as closed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1314519&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1314519 ] logging run into deadlock in some error handling situation
Bugs item #1314519, was opened at 2005-10-06 05:56
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1314519&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Vinay Sajip (vsajip)
Summary: logging run into deadlock in some error handling situation
Initial Comment:
I've a daemon that pipe stdout and stderr into logging
in order to capture everything it does. It works fine.
However if there is an error throw inside logging, the
error is sent to stderr that got redirect into logging
again. Its seems some lock is not reentrant and it
causes deadlock.
>>> import logging,sys
>>> # a quick and dirty log file object
... class LogFileObj(object):
... def __init__(self,log):
... self.log = log
... def write(self,str):
... self.log.warn(str)
...
>>> # create a logger for stderr
... log = logging.getLogger()
>>>
>>> # for the purpose of showing this bug, output to a
StreamHandler based on stdout
... handler = logging.StreamHandler(sys.stdout)
>>> handler.setFormatter(logging.Formatter('%(asctime)s
%(message)s'))
>>> log.addHandler(handler)
>>>
>>> # redirect stderr to a logger
... sys.stderr = LogFileObj(log)
>>>
>>> # it works!
... print >>sys.stderr, 'hello world'
2005-10-05 22:52:32,391 hello world
2005-10-05 22:52:32,391
>>>
>>> # now put sys.stderr aside
... # use the logger as usual
... log.warn('hello world')
2005-10-05 22:52:32,401 hello world
>>>
>>> # this one has an error in the number of arguments
... log.warn('hello world %s', 1, 2)
When the last statement is ran, it goes into a deadlock.
It seems this can be workaround by using
threading.RLock instead of thread's lock.
>>> # workaround the deadlock by using RLock
... import threading
>>> handler.lock = threading.RLock()
>>> log.warn('hello world %s', 1, 2)
2005-10-05 22:47:46,390 Traceback (most recent call last):
2005-10-05 22:47:46,400 File
"C:\Python24\lib\logging\__init__.py", line 706, in emit
2005-10-05 22:47:46,400 msg = self.format(record)
2005-10-05 22:47:46,400 File
"C:\Python24\lib\logging\__init__.py", line 592, in format
2005-10-05 22:47:46,400 return fmt.format(record)
2005-10-05 22:47:46,400 File
"C:\Python24\lib\logging\__init__.py", line 382, in format
2005-10-05 22:47:46,400 record.message =
record.getMessage()
2005-10-05 22:47:46,400 File
"C:\Python24\lib\logging\__init__.py", line 253, in
getMessage
2005-10-05 22:47:46,400 msg = msg % self.args
2005-10-05 22:47:46,400 TypeError: not all arguments
converted during string formatting
I'm not too familiar with the implementation of
logging. Please keep me posted whether this is a
legitimate workaround.
--
>Comment By: Vinay Sajip (vsajip)
Date: 2005-10-06 08:37
Message:
Logged In: YES
user_id=308438
I've just looked into it, and the change has already been
made in CVS (Version 1.27, dated 31/03/2005). The change
should be in Python 2.4.2 final.
Marking as closed.
--
Comment By: Vinay Sajip (vsajip)
Date: 2005-10-06 07:53
Message:
Logged In: YES
user_id=308438
Yes, the problem is there and the proposed solution seems
fine. Also note that if you set logging.raiseExceptions to
0, then exceptions during emitting are silently ignored
rather than raised.
I will change thread.allocate_lock() -> threading.RLock()
and check into CVS soon, then mark this as closed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1314519&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1314107 ] Issue in unicode args in logging
Bugs item #1314107, was opened at 2005-10-05 18:11 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1314107&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: Unicode Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Vinay Sajip (vsajip) Summary: Issue in unicode args in logging Initial Comment: logging has an issue in handling unicode object arguments. >>> import logging >>> >>> class Obj: ... def __init__(self,name): ... self.name = name ... def __str__(self): ... return self.name ... >>> # a non-ascii string ... >>> obj = Obj(u'\u00f6') >>> >>> # this will cause error ... >>> print '%s' % obj Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 0: ordinal not in range(128) >>> >>> # this will promote to unicode (and the console also happen to be able to display it) ... >>> print u'%s' % obj ö >>> >>> # this works fine ... # (other than logging makes its own decision to encode in utf8) ... >>> logging.error(u'%s' % obj) ERROR:root:├╢ >>> >>> # THIS IS AN UNEXPECTED PROBLEM!!! ... >>> logging.error(u'%s', obj) Traceback (most recent call last): File "C:\Python24\lib\logging\__init__.py", line 706, in emit msg = self.format(record) File "C:\Python24\lib\logging\__init__.py", line 592, in format return fmt.format(record) File "C:\Python24\lib\logging\__init__.py", line 382, in format record.message = record.getMessage() File "C:\Python24\lib\logging\__init__.py", line 253, in getMessage msg = msg % self.args UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 0: ordinal not in range(128) >>> >>> # workaround the str() conversion in getMessage() ... >>> logging.error(u'%s-\u00f6', obj) ERROR:root:├╢-├╢ The issue seems to be in LogRecord.getMessage(). It attempts to convert msg to byte string: msg = str(self.msg) I am not sure why ti want to do the conversion. The last example workaround this by making sure msg is not convertible to byte string. -- >Comment By: Vinay Sajip (vsajip) Date: 2005-10-06 08:44 Message: Logged In: YES user_id=308438 Misc. changes were backported into Python 2.4.2, please check that you have this version. The problem is not with msg = str(self.msg) but rather with msg = msg % args To ensure good Unicode support, ensure your messages are either Unicode strings or objects whose __str__() method returns a Unicode string. Then, msg = msg % args should result in a Unicode object. You can pass this to a FileHandler opened with an encoding argument, or a StreamHandler whose stream has been opened using codecs.open(). Ensure your default encoding is set correctly using sitecustomize.py. The encoding additions were made in Revision 1.26 of logging/__init__.py, dated 13/03/2005. Marking as closed. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-06 04:00 Message: Logged In: YES user_id=33168 Vinay, any suggestions? -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 20:47 Message: Logged In: YES user_id=38388 Unassinging the bug. I don't know anything about the logging module. Hint: perhaps the logging module should grow an .encoding attribute which then allows converting Unicode to some encoding used in the log file ?! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1314107&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1302267 ] A command history for the idle interactive shell
Bugs item #1302267, was opened at 2005-09-23 19:05 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302267&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: IDLE Group: Feature Request >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Björn Lindqvist (sonderblade) Assigned to: Kurt B. Kaiser (kbk) Summary: A command history for the idle interactive shell Initial Comment: 1. Start IDLE. 2. In the IDLE shell that pops up, write a line of Python code and press enter. 3. Pretend you made a spelling mistake in step two. So you press up and try to fix it but you can't because the cursor is moved and the IDLE shell doesn't work at all like the normal CPython shell. In fact, there is no easy way at all to get back to the last line of input for correcting spelling mistakes. I think there should be one. Maybe ALT+Up could do what Up does in the CPython shell? -- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-10-06 11:19 Message: Logged In: YES user_id=149084 IDLE is a full screen editor, unlike the CPython interactive interpreter. So arrow up/down are reserved for cursor motion. However, IDLE has a special facility to recall command history. See Help / IDLE Help - Tip Section - Python Shell Window - Command History. There are several ways to recall the command history. If you like you can rebind to Alt-Up Arrow etc. using Options / Configure IDLE / Keys. Default is Alt-p. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302267&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-827963 ] Registry key CurrentVersion not set
Bugs item #827963, was opened at 2003-10-22 04:54 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827963&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None >Priority: 6 Submitted By: Jimm Domingo (jimm_domingo) >Assigned to: Martin v. Löwis (loewis) Summary: Registry key CurrentVersion not set Initial Comment: According to the documentation for Python's use of the Windows registry, the version number of most recently installed version is in the key HKEY_LOCAL_MACHINE\Software\Python\PythonCore\CurrentVersion. But this key does not exist on my system. My configuration: Python 2.2.3 (#42, May 30 2003, 18:12:08) on Windows XP Professional, Version 2002, SP1. FWIW, I downloaded most recent revision (1.133.4.4) of the Wise installation script (python20.wse) from CVS. I then opened it with an evaluation copy of Wise Installation System. I've never used that product, but it appears that the above key isn't assigned a value. -- Comment By: Thomas Heller (theller) Date: 2003-12-10 16:49 Message: Logged In: YES user_id=11105 I'm unassigning this, since I neither maintain the python.org web pages nor would I want to. I would suggest to either remove these pages completely, or mark them as hopefully outdated. -- Comment By: Jimm Domingo (jimm_domingo) Date: 2003-12-05 22:16 Message: Logged In: YES user_id=860120 The document "Python Registry" is at http://www.python.org/windows/python/registry.html The page "Python support for Windows" (http://www.python.org/windows/) has a link to that document, but it is classified as an old link. Seems to confirm your thinking that the documentation no longer describes the way things are done. -- Comment By: Thomas Heller (theller) Date: 2003-12-05 21:52 Message: Logged In: YES user_id=11105 I think this is a documentation bug. Can you point me to where it is documented? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827963&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-813986 ] robotparser interactively prompts for username and password
Bugs item #813986, was opened at 2003-09-28 15:06 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813986&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: 6 Submitted By: Erik Demaine (edemaine) >Assigned to: Martin v. Löwis (loewis) Summary: robotparser interactively prompts for username and password Initial Comment: This is a rare occurrence, but if a /robots.txt file is password-protected on an http server, robotparser interactively prompts (via raw_input) for a username and password, because that is urllib's default behavior. One example of such a URL, at least at the time of this writing, is http://www.cosc.canterbury.ac.nz/robots.txt Given that robotparser and robots.txt is all about *robots* (not interactive users), I don't think this interactive behavior is terribly appropriate. Attached is a simple patch to robotparser.py to fix this behavior, forcing urllib to return the 401 error that it ought to. Another issue is whether a 401 (Authorization Required) URL means that everything should be allowed or everything should be disallowed. I'm not sure what's "right". Reading the spec, it says 'This file must be accessible via HTTP on the local URL "/robots.txt"' which I would read to mean it should be accessible without username/password. On the other hand, the current robotparser.py code says "if self.errcode == 401 or self.errcode == 403: self.disallow_all = 1" which has the opposite effect. I'll leave deciding which is most appropriate to the powers that be. -- Comment By: Wummel (calvin) Date: 2003-09-29 15:24 Message: Logged In: YES user_id=9205 http://www.robotstxt.org/wc/norobots-rfc.html specifies the 401 and 403 return code consequences as restricting the whole site (ie disallow_all = 1). For the password input, the patch looks good to me. On the long term, robotparser.py should switch to urllib2.py anyway, and it should handle Transfer-Encoding: gzip. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813986&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246405 ] Segmentation fault when importing expat from xml.parser
Bugs item #1246405, was opened at 2005-07-28 01:07 Message generated for change (Comment added) made by jean-pierre24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470,raise Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jean-Pierre (jean-pierre24) Assigned to: Nobody/Anonymous (nobody) Summary: Segmentation fault when importing expat from xml.parser Initial Comment: Hello, I have a strange segmentation fault when importing expat from xml.parsers in the following program (I removed all that is un-necessary to reproduce the bug, which is why the code may look odd). I've also posted this bug on wxPython bug lists because I'm not sure if it's related to Python or wxPython, but anyway the backtrace told me that the segmentation fault occurs when importing expat. import wx import wx.html class MainFrame(wx.Frame): def __init__(self, prnt): wx.Frame.__init__(self, parent=prnt) wx.html.HtmlWindow(wx.Window(self, -1), -1) print "debug 1" from xml.parsers import expat print "debug 2" class BoaApp(wx.App): def OnInit(self): wx.InitAllImageHandlers() MainFrame(None) return True app = BoaApp() The segmentation fault occurs between 'debug 1' and 'debug 2'. If I try to remove anything else, it doesn't happen. I have confirmed the bug on SunOS 5.8, on linux Red Hat Enterprise Server 3 and linux Advanced Server 3. I'm working with Python 2.4.1 and wxPython 2.6.1.0 Here is in attached file, the backtrace from gdb. Feel free to ask me any additional information... -- >Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-06 22:23 Message: Logged In: YES user_id=1247525 Yes I can try with different version of wx, but it will take time. Anyway for today here is in attachment the valgrind output on linux x86. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-05 05:34 Message: Logged In: YES user_id=33168 I don't have the problem with Python 2.3.4 and wx 2.5.5.1. Are you able to try different versions of wxPython? I notice that wx 2.6.2 is available. Are you able to run under valgrind or purify? If you run under valgrind, be sure to specify --suppressions=Misc/valgrind-python.supp The file is in the Python distribution. You can download it through SourceForge ViewCVS. -- Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-05 00:05 Message: Logged In: YES user_id=1247525 Link is : http://sourceforge.net/tracker/index.php?func=detail&aid=1246397&group_id=9863&atid=109863 Unfortunately, absolutely nothing has happened since I reported the bug. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-04 07:10 Message: Logged In: YES user_id=33168 Can you provide a link to the wx bug report? Has anything happend with it? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470,raise ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1314107 ] Issue in unicode args in logging
Bugs item #1314107, was opened at 2005-10-05 11:11 Message generated for change (Settings changed) made by tungwaiyip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1314107&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: Unicode Group: Python 2.4 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Vinay Sajip (vsajip) Summary: Issue in unicode args in logging Initial Comment: logging has an issue in handling unicode object arguments. >>> import logging >>> >>> class Obj: ... def __init__(self,name): ... self.name = name ... def __str__(self): ... return self.name ... >>> # a non-ascii string ... >>> obj = Obj(u'\u00f6') >>> >>> # this will cause error ... >>> print '%s' % obj Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 0: ordinal not in range(128) >>> >>> # this will promote to unicode (and the console also happen to be able to display it) ... >>> print u'%s' % obj ö >>> >>> # this works fine ... # (other than logging makes its own decision to encode in utf8) ... >>> logging.error(u'%s' % obj) ERROR:root:├╢ >>> >>> # THIS IS AN UNEXPECTED PROBLEM!!! ... >>> logging.error(u'%s', obj) Traceback (most recent call last): File "C:\Python24\lib\logging\__init__.py", line 706, in emit msg = self.format(record) File "C:\Python24\lib\logging\__init__.py", line 592, in format return fmt.format(record) File "C:\Python24\lib\logging\__init__.py", line 382, in format record.message = record.getMessage() File "C:\Python24\lib\logging\__init__.py", line 253, in getMessage msg = msg % self.args UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 0: ordinal not in range(128) >>> >>> # workaround the str() conversion in getMessage() ... >>> logging.error(u'%s-\u00f6', obj) ERROR:root:├╢-├╢ The issue seems to be in LogRecord.getMessage(). It attempts to convert msg to byte string: msg = str(self.msg) I am not sure why ti want to do the conversion. The last example workaround this by making sure msg is not convertible to byte string. -- >Comment By: Wai Yip Tung (tungwaiyip) Date: 2005-10-06 16:16 Message: Logged In: YES user_id=561546 >>To ensure good Unicode support, ensure your messages are either Unicode strings or objects whose __str__() method returns a Unicode string. Then, >>msg = msg % args That's what I am doing already. Let me explain the subtle problem again. 1. print '%s' % obj - error 2. logging.error(u'%s' % obj) - ok 3. logging.error(u'%s', obj) - error 4. logging.error(u'%s-\u00f6', obj) -ok I can understand how 1 fails. But I expect 2,3 and 4 to work similarly. Especially contrast 3 with 4. 4 work when 3 doesn't because when str() is applied to u'%s-\u00f6' it fails and it fallbacks to the original unicode string, which is the correct way in my opinion. Whereas in 3, the u'%s' get demoted to byte string '%s' so it fails like 1. -- Comment By: Vinay Sajip (vsajip) Date: 2005-10-06 01:44 Message: Logged In: YES user_id=308438 Misc. changes were backported into Python 2.4.2, please check that you have this version. The problem is not with msg = str(self.msg) but rather with msg = msg % args To ensure good Unicode support, ensure your messages are either Unicode strings or objects whose __str__() method returns a Unicode string. Then, msg = msg % args should result in a Unicode object. You can pass this to a FileHandler opened with an encoding argument, or a StreamHandler whose stream has been opened using codecs.open(). Ensure your default encoding is set correctly using sitecustomize.py. The encoding additions were made in Revision 1.26 of logging/__init__.py, dated 13/03/2005. Marking as closed. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-05 21:00 Message: Logged In: YES user_id=33168 Vinay, any suggestions? -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-05 13:47 Message: Logged In: YES user_id=38388 Unassinging the bug. I don't know anything about the logging module. Hint: perhaps the logging module should grow an .encoding attribute which then allows converting Unicode to some encoding used in the log file ?! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1314107&group_id=5470 ___ Python-bugs-list mailing list Uns
