[issue12483] CThunkObject_dealloc should call PyObject_GC_UnTrack?
New submission from Ryan Kelly : According to the docs here: http://docs.python.org/c-api/gcsupport.html Any object that uses PyObject_GC_Track in its constructor must call PyObject_GC_UnTrack in its deallocator. The CThunkObject in _ctypes does the former but not the later. Attached patch adds a call to PyObject_GC_UnTrack. This doesn't fix any particular bug I was seeing, I just happened to be going through the _ctypes sources (you know, for fun...) and noticed this discrepancy. -- components: ctypes files: ctypes_gcuntrack.patch keywords: patch messages: 139724 nosy: rfk priority: normal severity: normal status: open title: CThunkObject_dealloc should call PyObject_GC_UnTrack? versions: Python 3.3 Added file: http://bugs.python.org/file22560/ctypes_gcuntrack.patch ___ Python tracker <http://bugs.python.org/issue12483> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Ryan Kelly : -- nosy: +rfk ___ Python tracker <http://bugs.python.org/issue11682> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis
Changes by Ryan Kelly : -- nosy: +rfk ___ Python tracker <http://bugs.python.org/issue11816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9957] SpooledTemporayFile.truncate should take size parameter
New submission from Ryan Kelly : Both file.truncate() and StringIO.truncate() accept an optional "size" parameter to truncate the file to a specific size. SpooledTemporaryFile should accept a similar parameter and pass it on. The only tricky part is that truncate can potentially increase the size of a file, so it needs to check the max size and rollover if appropriate. Patch is against py3k branch; should work on trunk modulo the use of b"xxx" in the tests. -- components: Library (Lib) files: spooledtemporaryfile_truncate.patch keywords: patch messages: 117436 nosy: rfk priority: normal severity: normal status: open title: SpooledTemporayFile.truncate should take size parameter type: behavior Added file: http://bugs.python.org/file19027/spooledtemporaryfile_truncate.patch ___ Python tracker <http://bugs.python.org/issue9957> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9957] SpooledTemporayFile.truncate should take size parameter
Ryan Kelly added the comment: I went looking for places to update the documentation but the description of SpooledTemporaryFile doesn't go into any detail of its methods, so I haven't added anything. New patch fixes some whitespace issues. I'd like to argue that this is a bug, since SpooledTemporaryFile is documented as "operates exactly as TemporaryFile() does", and TemporaryFile.truncate accepts a "size" parameter. -- Added file: http://bugs.python.org/file19032/spooledtemporaryfile_truncate.patch ___ Python tracker <http://bugs.python.org/issue9957> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9957] SpooledTemporayFile.truncate should take size parameter
Changes by Ryan Kelly : Removed file: http://bugs.python.org/file19027/spooledtemporaryfile_truncate.patch ___ Python tracker <http://bugs.python.org/issue9957> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5091] Segfault in PyObject_Malloc(), address out of bounds
Ryan Kelly added the comment: Not sure if it's caused by the same thing, but I just got a segfault on the same line in my own program. Running python 2.7.1. I will try to dig out some more useful info but it's been a long time since I chased a segfault... -- nosy: +rfk status: pending -> open ___ Python tracker <http://bugs.python.org/issue5091> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5091] Segfault in PyObject_Malloc(), address out of bounds
Ryan Kelly added the comment: Please remind me how to obtain an appropriate coredump (as I said, it's been a *long* time...) Doing "print bp" shows an out-of-bounds address as for the original submitter. -- ___ Python tracker <http://bugs.python.org/issue5091> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5091] Segfault in PyObject_Malloc(), address out of bounds
Ryan Kelly added the comment: attaching core dump from a freshly-compiled python 2.7.1 at with "-O0 -g" in CFLAGS. The code that is segfaulting is using pycrypto and sqlite3, so it may be that a bug in one of these is trampling on something. No idea how to investigate any further. -- Added file: http://bugs.python.org/file21004/core.27778.bz2 ___ Python tracker <http://bugs.python.org/issue5091> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5091] Segfault in PyObject_Malloc(), address out of bounds
Ryan Kelly added the comment: Thanks for the help, I have tracked this down to a bug in PyCrypto. It was increfing an object once but decrefing it twice. Sorry for the noise. -- ___ Python tracker <http://bugs.python.org/issue5091> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11448] docs for HTTPConnection.set_tunnel are ambiguous
New submission from Ryan Kelly : The docs for HTTPConnection.set_tunnel(host,port) are ambiguous. They simply say "Set the host and the port for HTTP Connect Tunnelling". But should I specify the address of the server *through* which I want to tunnel, or the address of the *endpoint* of the tunnel? Turns out it's the latter, but I just wasted an hour "debugging" thinking it was the former :-( Attached is a simple doc patch to try to clarify this issue. -- assignee: docs@python components: Documentation files: set_tunnel_doc.diff keywords: patch messages: 130396 nosy: docs@python, rfk priority: normal severity: normal status: open title: docs for HTTPConnection.set_tunnel are ambiguous versions: Python 3.3 Added file: http://bugs.python.org/file21056/set_tunnel_doc.diff ___ Python tracker <http://bugs.python.org/issue11448> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11448] docs for HTTPConnection.set_tunnel are ambiguous
Ryan Kelly added the comment:
Sorry, "endpoint" is just a noun that seemed to fit for me, I've no idea if
there is a standard term for this. Perhaps "origin server" if you follow the
terminology from the RFC?
By way of example, suppose I'm running a proxy on localhost:3128 and I want to
tunnel through it to connect to www.example.com:443.
>From the train of thought that "I need to tunnel through localhost:3128 to
>connect to www.example.com:443" my instinct was to write code like this:
c = HTTPSConnection("www.example.com",443)
c.set_tunnel("localhost",3128)
c.send('...etc...')
This doesn't work; it tries to tunnel through www.example.com to get to
localhost. The correct way around is:
c = HTTPSConnection("localhost",3128)
c.set_tunnel("www.example.com",443)
c.send('...etc...')
Another way to put it: the arguments to set_tunnel are the host/port to tunnel
*to*, not the host/port to tunnel *through*.
I was only able to work this out by looking through to code for urllib2. It's
not clear from the docs. Then again, sounds like my doc patch didn't make
things any clearer :-)
--
___
Python tracker
<http://bugs.python.org/issue11448>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10399] AST Optimization: inlining of function calls
Changes by Ryan Kelly : -- nosy: +rfk ___ Python tracker <http://bugs.python.org/issue10399> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4875] find_library can return directories instead of files
New submission from Ryan Kelly : On win32, ctypes.util.find_library uses os.path.exists() to check for potential library files. This means it is quite happy to return a directory instead of a file, if one happens to exist with the appropriate name somewhere in the search path. Can this please be changed to use os.path.isfile() instead of os.path.exists()? -- assignee: theller components: ctypes messages: 79385 nosy: rfk, theller severity: normal status: open title: find_library can return directories instead of files type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue4875> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14995] PyLong_FromString documentation should state that the string must be null-terminated
New submission from Ryan Kelly :
PyLong_FromString will raise a ValueError if the given string doesn't contain a
null byte after the digits. For example, this will result in a ValueError
char *pend;
PyLong_FromString("1234 extra", &pend, 10)
While this will successfully read the number and set the pointer to the extra
data:
char *pend;
PyLong_FromString("1234\0extra", &pend, 10)
The requirement for a null-terminated string of digits is not clear from the
docs. Suggested re-wording attached.
--
assignee: docs@python
components: Documentation
files: PyLong_FromString-doc.patch
keywords: patch
messages: 162242
nosy: docs@python, rfk
priority: normal
severity: normal
status: open
title: PyLong_FromString documentation should state that the string must be
null-terminated
Added file: http://bugs.python.org/file25812/PyLong_FromString-doc.patch
___
Python tracker
<http://bugs.python.org/issue14995>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6915] os.listdir inconsistenly releases the GIL on win32
New submission from Ryan Kelly : The win32 implementation of os.listdir() releases the GIL around calls to FindNextFile, but not around calls to FindFirstFile. Attached is a simple patch to consistently release the GIL around any such calls. -- components: None files: listdir_gil.patch keywords: patch messages: 92643 nosy: rfk severity: normal status: open title: os.listdir inconsistenly releases the GIL on win32 type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file14892/listdir_gil.patch ___ Python tracker <http://bugs.python.org/issue6915> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8400] zipimporter find_module fullname mis-documented
Ryan Kelly added the comment: Was also just bitten by this, trying to muck with PEP-302-style import hooks. Note that the documented behaviour of zipimporter is also the behaviour required by PEP 302, i.e. full dotted module name. -- nosy: +rfk ___ Python tracker <http://bugs.python.org/issue8400> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5950] Make zimport work with zipfile containing comments
Changes by Ryan Kelly : -- nosy: +rfk ___ Python tracker <http://bugs.python.org/issue5950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5950] Make zimport work with zipfile containing comments
Ryan Kelly added the comment: Attached is my attempt at a patch for this functionality, along with some simple tests. This basically mirrors what's done in zipfile.py, searching backwards through the file until it finds the end-of-central-directory marker. It tries to be memory conscious by reading in small chunks. Patch is against trunk; I've also tested it against 2.7 and it seems to work. Any chance of it being backported into 2.7? Also wanted to mention a real-world usecase for this functionality. I want to digitally sign a frozen python program with appended zipfile, which involves appending the signature to the EXE. Simple to do if only zipimport would support appended comments. -- keywords: +patch Added file: http://bugs.python.org/file17943/zipimport_with_comments.patch ___ Python tracker <http://bugs.python.org/issue5950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5950] Make zimport work with zipfile containing comments
Ryan Kelly added the comment: Whoops, forgot to remove the line from the docs about comments not being supported. Updated the patch accordingly. -- Added file: http://bugs.python.org/file17944/zipimport_with_comments.patch ___ Python tracker <http://bugs.python.org/issue5950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5950] Make zimport work with zipfile containing comments
Changes by Ryan Kelly : Removed file: http://bugs.python.org/file17943/zipimport_with_comments.patch ___ Python tracker <http://bugs.python.org/issue5950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9238] zipfile incorrectly documented as not supporting archive comments
New submission from Ryan Kelly : The zipfile module is prominently documented as "This module does not currently handle...ZIP files which have appended comments". But as far as I can tell, it handles them fine - there's even a "comment" property on the ZipFile object that you can set to modify the comment. I attach a simple doc patch that removes the apparently out-of-date information. -- assignee: d...@python components: Documentation files: zipfile_comment_doc.patch keywords: patch messages: 110147 nosy: d...@python, rfk priority: normal severity: normal status: open title: zipfile incorrectly documented as not supporting archive comments versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file17973/zipfile_comment_doc.patch ___ Python tracker <http://bugs.python.org/issue9238> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9239] zipfile: truncating comment can corrupt the zipfile
New submission from Ryan Kelly : If you open a ZipFile in append mode and modify the comment to be shorter than what was originally there, the file will become corrupted. Truncated data from the original comment is left "dangling" at the end of the zipfile. A much more trivial bug discovered while writing tests for this: setting the "comment" attribute doesn't mark the zipfile as modified, so the change won't be written out unless you also modify one of the archive files. The attached patch fixes (and adds tests for) these issues. -- components: Library (Lib) files: zipfile_appendmode_comment.patch keywords: patch messages: 110149 nosy: rfk priority: normal severity: normal status: open title: zipfile: truncating comment can corrupt the zipfile type: performance versions: Python 3.2 Added file: http://bugs.python.org/file17974/zipfile_appendmode_comment.patch ___ Python tracker <http://bugs.python.org/issue9239> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5950] Make zipimport work with zipfile containing comments
Ryan Kelly added the comment: I can't imagine anyone depending on this lack-of-feature, but there's no arguing with the technicality of it. One more small incentive to make the jump to Python 3 then. Anyway, I've revisited the patch to clean up the logic and control flow, and added another test to ensure that it works even when the EOCD record crosses a chunk boundary. Also checked that it works on win32, which fortunately it did without modification. -- Added file: http://bugs.python.org/file17975/zipimport_with_comments.patch ___ Python tracker <http://bugs.python.org/issue5950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5950] Make zipimport work with zipfile containing comments
Changes by Ryan Kelly : Removed file: http://bugs.python.org/file17944/zipimport_with_comments.patch ___ Python tracker <http://bugs.python.org/issue5950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9316] typos in zipimport docstrings
New submission from Ryan Kelly : zipimporter methods is_package, get_code and get_source have in the their docstring "Raise ZipImportError is the module couldn't be found". The attached patch fixes the typo to "if the module couldn't be found". -- files: zipimport_docstring_typo.patch keywords: patch messages: 110983 nosy: rfk priority: normal severity: normal status: open title: typos in zipimport docstrings Added file: http://bugs.python.org/file18095/zipimport_docstring_typo.patch ___ Python tracker <http://bugs.python.org/issue9316> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
