[issue17431] email.parser module has no attribute BytesFeedParser
New submission from Forest Wilkinson: The docs claim that email.parser.BytesFeedParser exists, but it doesn't. Looks like email.feedparser.FeedParser is imported into the email.parser module, but someone forgot to do the same for BytesFeedParser. -- components: email messages: 184247 nosy: barry, forest, r.david.murray priority: normal severity: normal status: open title: email.parser module has no attribute BytesFeedParser versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3831] Multiprocessing: Expose underlying pipe in queues
Changes by Forest Wilkinson pyth...@tibit.com: -- nosy: +forest ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3143] Make the left sidebar in the doc collapsible
Forest Wilkinson for...@users.sourceforge.net added the comment: I just noticed Ezio's change to the title of this bug. Does the proposed fix address the original bug title (docs waste a lot of horizontal space on left nav bar) for third-party packages that use docutils to generate their docs? Or, does it only avoid the problem in the official python documentation? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3143 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3143] development docs waste a lot of horizontal space on left nav bar
Forest Wilkinson for...@users.sourceforge.net added the comment: It is relative to the resolution of the user's browser window. Don't make the mistake of assuming that everyone keeps their browser maximized. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3143 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5397] PEP 372: OrderedDict
Forest Wilkinson for...@users.sourceforge.net added the comment: I was just reading the PEP, and caught this bit: Does OrderedDict.popitem() return a particular key/value pair? Yes. It pops-off the most recently inserted new key and its corresponding value. Okay, but I'd also like a convenient and fast way to find the oldest key, which I think I'd need for an LRU cache. I didn't notice one in the patch. Perhaps I simply missed something. Shouldn't popitem() allow the caller to choose which end from which to pop? -- nosy: +forest ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5397 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5397] PEP 372: OrderedDict
Forest Wilkinson for...@users.sourceforge.net added the comment: Shouldn't popitem() allow the caller to choose which end from which to pop? Thinking it through a bit more, and LRU cache would actually need to access the oldest item without necessarily removing it. Besides, popitem() should probably retain the signature of dict.popitem(). I think I'll take this matter to python-dev. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5397 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5397] PEP 372: OrderedDict
Forest Wilkinson for...@users.sourceforge.net added the comment: Agreed here. Thanks, gents. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5397 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1641] asyncore delayed calls feature
Forest Wilkinson for...@users.sourceforge.net added the comment: I'm looking forward to having this functionality in asyncore. It would help me remove some unwanted hackery from my own code. Giampaolo, I'm concerned that your patch uses a global 'tasks' list which cannot be overriden. Shouldn't loop() accept an optional task list argument, as it already does with the socket map? That would keep with the spirit of asyncore and make things easier for those of us who use multiple event loops in multiple threads. Josiah, is your updated sched module the one described in this blog post? Is there an issue in the bug tracker about it? http://chouyu-31.livejournal.com/316112.html ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1194378] sendmsg() and recvmsg() for C socket module
Changes by Forest Wilkinson for...@users.sourceforge.net: -- nosy: +forest ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1194378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4690] asyncore calls handle_write() on closed sockets when use_poll=True
New submission from Forest Wilkinson for...@users.sourceforge.net:
With use_poll=True on linux, asyncore calls handle_write() after the
socket has been closed.
More specifically, it looks like asyncore dispatches handle_read() and
handle_close() events between the writable() test and the corresponding
handle_write() call. If handle_close() calls close(), as asyncore's
default implementation does, the subsequent handle_write() will fail and
generate an EBADF (bad file descriptor) exception. If handle_error()
also calls close(), as asyncore's default implementation does, this will
mean close() gets called twice on the same socket.
I am attaching example code which demonstrates the problem on Linux
2.6.24 using python 2.5.2, 2.5.3rc1, and 2.6. In one window, run
pollwritefail.py. In another window, establish a TCP connection to port
12345 and immediately close it without reading or writing. This can be
done from within the python interactive interpreter like this:
import socket
s=socket.socket( socket.AF_INET, socket.SOCK_STREAM); s.connect(
('localhost', 12345)); s.close()
The output from pollwritefail.py will look like this:
writable() - asyncore asked if we have data to write
handle_read() - asyncore asked us to read
handle_close() - asyncore said the remote host closed connection
close() - we are closing our end of the connection
handle_write() - asyncore asked us to write
handle_error() - asyncore exception: (9, 'Bad file descriptor')
close() - we are closing our end of the connection
IMHO, two things need fixing here:
1. When writable() returns True, the next handler asyncore calls should
be handle_write(). Calling other handlers in between risks invalidating
the writable() return value.
2. After close(), asyncore should not call handle_write(), even if
writable() would return true.
--
components: Library (Lib)
files: pollwritefail.py
messages: 78003
nosy: forest
severity: normal
status: open
title: asyncore calls handle_write() on closed sockets when use_poll=True
type: behavior
versions: Python 2.5, Python 2.5.3, Python 2.6
Added file: http://bugs.python.org/file12390/pollwritefail.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4690
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2944] asyncore doesn't handle connection refused correctly
Changes by Forest Wilkinson for...@users.sourceforge.net: -- nosy: +forest ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2944 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1856] shutdown (exit) can hang or segfault with daemon threads running
Changes by Forest Wilkinson for...@users.sourceforge.net: -- nosy: +forest ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1856 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1720705] thread + import = crashes?
Changes by Forest Wilkinson for...@users.sourceforge.net: -- nosy: +forest ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1720705 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533164] Installed but not listed *.pyo break bdist_rpm
Changes by Forest Wilkinson [EMAIL PROTECTED]: -- nosy: +forest ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1533164 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
Changes by Forest Wilkinson [EMAIL PROTECTED]: -- nosy: +forest ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2550 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3904] asynchat async_chat __init__() arguments changed in python 2.6
New submission from Forest Wilkinson [EMAIL PROTECTED]: In python 2.6rc2, the async_chat.__init__() parameters have changed. The first arg was called 'conn' in python 2.5, and it is now called 'sock'. This change breaks code that worked with previous python 2.x versions, if that code followed the example in the official docs: class http_request_handler(asynchat.async_chat): def __init__(self, conn, addr, sessions, log): asynchat.async_chat.__init__(self, conn=conn) The change also breaks the 2.6 docs, as they have not been updated to reflect the newly renamed parameter. http://docs.python.org/dev/library/asynchat.html#id1 The change appears to come from Nadeem Vawda as part of issue1519. (See msg57989.) I expect that existing python code could be modified to work around the problem by using positional args instead of keyword args. However, I didn't expect to have to update my working code to accommodate such a change in the python 2.x code line. I agree that 'sock' is a better name for the parameter, especially since it matches the same in asyncore.dispatcher, but should the change really happen before python 3.0? If so, let's at least update the docs. -- components: Library (Lib) messages: 73405 nosy: forest, nvawda severity: normal status: open title: asynchat async_chat __init__() arguments changed in python 2.6 versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3904 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement
Forest Wilkinson [EMAIL PROTECTED] added the comment: Simon: I wish I could offer guidance here, but I'm afraid that I too am reading some of these openssl man pages for the first time. I agree that writing to a temporary file would be bad. Accepting file-like objects from python code would be nice, but isn't really necessary. Simple strings would suffice. It's easy enough for application code to read the strings from the appropriate files. Of course, the ssl module (or an underlying library) would need a way to determine the data format within the strings. Unfortunately, I didn't notice an equivalent of SSL_CTX_use_PrivateKey_file() that accepts a file's contents instead of its path. SSL_CTX_use_RSAPrivateKey() looks like the next best thing. much of the mechanism of a Certificate object is already there; perhaps adding an opaque Key object wouldn't be too bad. That's encouraging. From the openssl docs I've read so far, it looks like certificates and keys have several formats and use patterns. That seems to me like another argument in favor of supporting separate Certificate and Key objects, even if they're only minimally implemented to begin with. In other words, I don't imagine the presence of Certificate and Key objects would muck up the ssl module's api. In order to keep compatibility with socket.ssl, perhaps any new certificate and key objects should be accepted as alternatives to the existing certfile and keyfile args, but the latter should still be allowed? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3823] ssl.wrap_socket() is incompatible with unprivileged servers, due to keyfile requirement
New submission from Forest Wilkinson [EMAIL PROTECTED]: SSLSocket() and ssl.wrap_socket() accept private keys only as paths to their location on the file system. This means that a server can only support SSL if it has read access to its private key file at the time when client connections arrive, which is a problem for servers that bind to their socket and drop privileges as soon as they start up. In other words, the new ssl module's API prevents its use in servers that follow best practices that are prevalent in the unix world. If SSLSocket() and ssl.wrap_socket() were updated to accept private keys as strings (or open file-like objects or some such), the problem would go away. Moreover, it would allow a program to keep private keys cached in memory, which might slightly improve performance over reading them from the file system on every new connection. -- components: Library (Lib) messages: 72891 nosy: forest severity: normal status: open title: ssl.wrap_socket() is incompatible with unprivileged servers, due to keyfile requirement type: security versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement
Changes by Forest Wilkinson [EMAIL PROTECTED]: -- title: ssl.wrap_socket() is incompatible with unprivileged servers, due to keyfile requirement - ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement
Changes by Forest Wilkinson [EMAIL PROTECTED]: -- nosy: +janssen ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement
Forest Wilkinson [EMAIL PROTECTED] added the comment: This problem also exists in the add-on ssl module for python 2.6: http://pypi.python.org/pypi/ssl/ ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3143] development docs waste a lot of horizontal space on left nav bar
New submission from Forest Wilkinson [EMAIL PROTECTED]: I was just browsing the development docs, and noticed that the new left-side navigation bar wastes a lot of horizontal space on the web page. It fills nearly a third of my browser window (at its usual size) with useless blank space, at the expense of the pertinent information. This makes it harder to get much use out of a docs window placed next to my editor window, since I am now forced to switch active windows and/or scroll around the docs window in order to read the section I'm working with. In a few cases, it leaves space for so few words per line that even the visible part of the docs actually become harder to read (especially with text justification). For comparison, here are screen shots from the old and new documentation: http://hestiafire.org/forest/img/doc25.png http://hestiafire.org/forest/img/doc26.png Is this side bar going to be present in the final release of the python 2.6 docs? I hope not. It's a significant loss in readability, IMHO. -- assignee: georg.brandl components: Documentation messages: 68412 nosy: forest, georg.brandl severity: normal status: open title: development docs waste a lot of horizontal space on left nav bar versions: Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3143 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] performance problem in socket._fileobject.read
Changes by Forest Wilkinson [EMAIL PROTECTED]: -- nosy: +forest __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1641] asyncore delayed calls feature
Changes by Forest Wilkinson [EMAIL PROTECTED]: -- nosy: +forest __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1641 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
