[issue8637] Add PYDOCPAGER envvar to specify pager for pydoc
Justin Bronder added the comment: On Thu, Feb 3, 2011 at 7:39 PM, Éric Araujo wrote: .. > Justin: what exactly is a pager that does not support man pages? vimpager is the one I'm using. For man pages there's vimmanpager. -- ___ Python tracker <http://bugs.python.org/issue8637> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8637] Add PYDOCPAGER envvar to specify pager for pydoc
Justin Bronder added the comment: > Éric Araujo added the comment: > > Excuse me if I was unclear: I wasn’t asking for program names but for a > definition of “don’t support” or description of problematic behavior. In headers with vimpager ^H is not rendered(?) correctly. For instance, 'pydoc os' shows: --- Help on module os: N^HNA^HAM^HME^HE F^HFI^HIL^HLE^HE /usr/lib/python2.6/os.py --- And so on. -- ___ Python tracker <http://bugs.python.org/issue8637> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8637] [PATCH] pydoc should respect MANPAGER over PAGER.
New submission from Justin Bronder : Similar to man(1), pydoc should respect the environment variable MANPAGER over PAGER. The current behavior causes issues when using a PAGER that does not support man pages. Patch based off of trunk, r80871 -- components: Library (Lib) files: python-2.7-pydoc-manpager.patch keywords: patch messages: 105151 nosy: jsbronder priority: normal severity: normal status: open title: [PATCH] pydoc should respect MANPAGER over PAGER. type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file17238/python-2.7-pydoc-manpager.patch ___ Python tracker <http://bugs.python.org/issue8637> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8637] pydoc should respect MANPAGER over PAGER.
Justin Bronder added the comment: I chose MANPAGER as the command line pydoc utility already clones some of the man functionality, but I'm fine with PYDOCPAGER or anything else that allows me to use pydoc without having to change PAGER first. -- ___ Python tracker <http://bugs.python.org/issue8637> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8833] tarfile: broken hardlink handling and testcase.
New submission from Justin Bronder : When adding hardlinks to an archive, tarfile does not set the size of each additional link to zero as specified by the tar format [1]. In addition, the current test case hardlinks is also broken. Instead of testing that the size of a hardlink to a non-empty file is 0, it tests that the size to a empty file is zero, which cannot fail. A patch against current svn trunk is attached and was tested with 'python -m test.regrtest -v test_tarfile' 1. http://www.gnu.org/software/tar/manual/tar.html#SEC170 -- components: Library (Lib) files: python-2.7-tarfile-hardlinks.patch keywords: patch messages: 106612 nosy: jsbronder priority: normal severity: normal status: open title: tarfile: broken hardlink handling and testcase. type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file17474/python-2.7-tarfile-hardlinks.patch ___ Python tracker <http://bugs.python.org/issue8833> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9065] tarfile: default root:root ownership is incorrect.
New submission from Justin Bronder :
According to the tar spec [1], uname/gname should only be filled
when they have successfully been resolved from the uid/gid. The
tarfile module incorrectly defaults to root:root in this case.
A patch against svn trunk r82183 is included. All tarfile unit
tests still pass with this patch. I did not include a new unit
test as chown() is required.
Example using tarfile:
$ ls -l tarfile_user
-rw-r--r-- 1 65533 jbronder 0 2010-06-23 17:44 tarfile_user
$ python -c "import tarfile;a = tarfile.open('bleh.tar',
'w:');a.add('tarfile_user');a.list()"
-rw-r--r-- root/jbronder 0 2010-06-23 17:44:55 tarfile_user
Example using GNU tarball:
$ tar -cf bleh.tar tarfile_user
$ python -c "import tarfile;a = tarfile.open('bleh.tar').list()"
-rw-r--r-- 65533/jbronder 0 2010-06-23 17:44:55 tarfile_user
1. http://www.gnu.org/software/tar/manual/tar.html#SEC170
--
files: python-2.7-tarfile-uid-gid.patch
keywords: patch
messages: 108493
nosy: jsbronder
priority: normal
severity: normal
status: open
title: tarfile: default root:root ownership is incorrect.
versions: Python 2.5, Python 2.7
Added file: http://bugs.python.org/file17756/python-2.7-tarfile-uid-gid.patch
___
Python tracker
<http://bugs.python.org/issue9065>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9065] tarfile: default root:root ownership is incorrect.
Changes by Justin Bronder : -- components: +Library (Lib) versions: +Python 2.6 ___ Python tracker <http://bugs.python.org/issue9065> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24645] logging.handlers.QueueHandler should not lock when handling a record
New submission from Justin Bronder: The Queue backing the QueueHandler is already sufficiently locking for thread-safety. This isn't a huge issue, but the QueueHandler is a very nice built-in which could be used to work around a deadlock I've encountered several times. In brief, functions which can cause other threads to log being called from either __repr__() or __str__(). -- components: Library (Lib) files: queue-handler-no-lock.patch keywords: patch messages: 246812 nosy: jsbronder priority: normal severity: normal status: open title: logging.handlers.QueueHandler should not lock when handling a record versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39935/queue-handler-no-lock.patch ___ Python tracker <http://bugs.python.org/issue24645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24645] logging.handlers.QueueHandler should not lock when handling a record
Justin Bronder added the comment:
On 16/07/15 20:03 +, R. David Murray wrote:
>
> R. David Murray added the comment:
>
> Can you expand on the deadlock? Are you saying that the "extra" locking is
> causing the deadlock?
>
> --
> nosy: +r.david.murray, vinay.sajip
> versions: -Python 3.2, Python 3.3
>
> ___
> Python tracker
> <http://bugs.python.org/issue24645>
> ___
Sure, here is the simplest example of the deadlock I could come up with. Using
__repr__() in the way presented is pretty stupid in this case but it does make
sense if you have objects which are backed by a database where communication is
handled in a separate thread.
What happens is this:
1. The main thread calls into the logger, handle() grabs the I/O lock.
2. String expansion of the Blah instance begins, this makes a request to the
second thread.
3. The second thread wants to log prior to responding, it gets stuck waiting
for
the I/O lock in handle()
import logging
import logging.handlers
import queue
import types
import threading
fmt = logging.Formatter('LOG: %(message)s')
stream = logging.StreamHandler()
stream.setFormatter(fmt)
log_queue = queue.Queue(-1)
queue_handler = logging.handlers.QueueHandler(log_queue)
queue_listener = logging.handlers.QueueListener(log_queue, stream)
queue_listener.start()
def handle(self, record):
rv = self.filter(record)
if rv:
self.emit(record)
return rv
# Uncomment to remove deadlock
#queue_handler.handle = types.MethodType(handle, queue_handler)
logger = logging.getLogger()
logger.addHandler(queue_handler)
logger.setLevel(logging.DEBUG)
class Blah(object):
def __init__(self):
self._in = queue.Queue()
self._out = queue.Queue()
def pub():
self._in.get(block=True)
logging.info('Got a request')
self._out.put('hi')
self._pub_thread = threading.Thread(target=pub)
self._pub_thread.start()
def __repr__(self):
self._in.put('gimme data')
return self._out.get()
def __del__(self):
self._pub_thread.join()
b = Blah()
logger.info('About to log')
logger.info('blah = %s', b)
queue_listener.stop()
--
___
Python tracker
<http://bugs.python.org/issue24645>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24645] logging.handlers.QueueHandler should not lock when handling a record
Justin Bronder added the comment: On 16/07/15 23:21 +, Vinay Sajip wrote: > > Vinay Sajip added the comment: > > I'm not sure I want to make a special case just to support what seems like a > somewhat pathological use case (no offence intended). > > If you need this, there's no reason you couldn't subclass QueueHandler and > override handle(), is there? Hey, no offense taken, it wasn't even my code that tripped on this, I just got the pleasure of debugging it! Anyways, it's up to you all if you want to include this, as you mentioned, it's easy enough to work around and I've already done so. However, the reason I submitted the patch is because I believe using the I/O lock is redundant as the Queue is handling the necessary synchronization already. -- ___ Python tracker <http://bugs.python.org/issue24645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
