Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nvawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11051
___
___
Python-bugs-list
Nadeem Vawda nadeem.va...@gmail.com added the comment:
OK, I've rewritten the whole bz2 module (patch attached), and I think it is now
ready for review. The BZ2File implementation is a cleaned-up version of the one
from my previous patch, with some further additions. I've factored out
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Looks good to me. My earlier patch was more defensive because I wasn't sure
whether any of the other tests might be using cgi.log(), but it seems that this
isn't the case.
--
___
Python tracker
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nvawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6715
___
___
Python-bugs-list
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nvawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11018
___
___
Python-bugs-list
Nadeem Vawda nadeem.va...@gmail.com added the comment:
* The read*() methods are implemented very inefficiently. Since they
have to deal with the bytes objects returned by
BZ2Decompressor.decompress(), a large read results in lots of
allocations that weren't necessary in the C implementation
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Here is an update patch, which corrects a typo in the previous patch, and adds
a test to test_zlib.
The test uses a memory-mapped sparse file, so it gets skipped on systems
without mmap. The alternative would be to allocate a 4+GB buffer
Nadeem Vawda nadeem.va...@gmail.com added the comment:
BTW,what is the best way to check for case insensitive file-system?
The test here merely checks if sys.platform returns mac, darwin or win32.
I would suggest not checking at all. If the system is case-sensitive, the test
will pass, so
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Interesting! If you are motivated, a further approach would be to expose
the compressor and decompressor objects from the C extension, and write
the file object in Python (as in Lib/gzip.py).
I had initially considered doing something
Nadeem Vawda nadeem.va...@gmail.com added the comment:
* I had initially considered doing something *like* that
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5863
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Here is a quick-and-dirty reimplementation of BZ2File in Python, on top of the
existing C implementation of BZ2Compressor and BZ2Decompressor.
There are a couple of issues with this code that need to be fixed:
* BZ2Decompressor doesn't
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Here is a patch that rewrites BZ2File to implement the requested feature, and
adds some tests using BytesIO objects.
Some notes:
* iteration and the read*() method now use the same buffering machinery, so
they can be mixed freely
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Yes, see bz2module-v1.diff.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5863
Nadeem Vawda nadeem.va...@gmail.com added the comment:
I have been working on a patch for this issue. I've implemented everything
except for readline(), readlines() and the iterator protocol.
In the existing implementation, the reading methods seem to interact weirdly -
iternext() uses
Nadeem Vawda nadeem.va...@gmail.com added the comment:
I have been unable to reproduce this on either 3.2rc1 or 2.6. I used a Zip
archive containing a single file with the data ba\n (CRC 0xDDEAA107).
--
nosy: +nvawda
___
Python tracker rep
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Good idea; they look like more work to fix than the warnings so far. Aside from
those two, it looks like test_cgi is all that's left. Just to clarify, did you
manage to reproduce the test_cgi warning
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Sorry, scratch that - I misunderstood the semantics of SocketIO.close(). I
hadn't realized that the underlying socket is supposed to stay open until it
itself is also explicitly closed (as well as all SocketIO objects referring
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nvawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4681
___
___
Python-bugs-list
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Looking at the warnings from test_urllib2net, it seems that they all originate
in the FTP tests:
* OtherNetworkTests.test_ftp()
* TimeoutTest.test_ftp_basic()
* TimeoutTest.test_ftp_default_timeout()
Most of these leaks seem to stem from
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Fix attached for test_imaplib. Most of the warnings were simply due to
reap_server() not closing the server object correctly. The remaining warning
was due a genuine leak in imaplib.IMAP4.__init__() - if an exception is raised
after
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Awesome. That just leaves test_urllibnet, test_urllib2net, and test_cgi. I'm
hoping to post patches for the first two tomorrow.
About test_cgi, I've fiddled around with it a bit more. The leak manifests
itself with any set of tests
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Have you tried my patch (resourcewarning-fixes-3.diff)? It fixes the warning
for me without breaking anything.
I was just worried that the warning was something triggered by my specific
system configuration when you said that you couldn't
Nadeem Vawda nadeem.va...@gmail.com added the comment:
r87710 introduces a ResourceWarning in test_threading. Fix attached.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10512
Changes by Nadeem Vawda nadeem.va...@gmail.com:
Added file: http://bugs.python.org/file20255/test_threading.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10512
Nadeem Vawda nadeem.va...@gmail.com added the comment:
r87710 introduces an AttributeError in test_thread's TestForkInThread test
case. If os.fork() is called from a thread created by the _thread module,
threading._after_fork() will get a _DummyThread (with no _block attribute) as
the current
Nadeem Vawda nadeem.va...@gmail.com added the comment:
According to POSIX [1], if a multi-threaded program calls fork(), the child
process may only use async-signal-safe system calls between fork() and exec*().
readdir() is not required to be async-safe [2], so reading /proc/self/fds
Nadeem Vawda nadeem.va...@gmail.com added the comment:
r87736 introduces another DeprecationError; this time in test_time (line 150;
s/assertEquals/assertEqual/).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10512
Nadeem Vawda nadeem.va...@gmail.com added the comment:
The fix for test_normalization was committed as r87441. As for test_cgi, I
still seem to get the leak (also on Linux; Ubuntu 10.10 64-bit). I'll poke
around with it some more tomorrow.
In addition to the ResourceWarnings, some of tests
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nvawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5863
___
___
Python-bugs-list
Nadeem Vawda nadeem.va...@gmail.com added the comment:
test_cgi causes a strange filehandle leak that only causes a warning when
regrtest terminates, and for some reason doesn't show up if you run just
test_cgi by itself. I've attached a patch that closes the filehandle.
--
nosy
New submission from Nadeem Vawda nadeem.va...@gmail.com:
When running make test on Python3, test_socket reports a number of
ResourceWarnings due to unclosed sockets. Attached is a patch that changes the
relevant tests so that they close all the created sockets.
test_multiprocessing
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Attached is a patch that fixes the warnings in test_xmlrpc, along with some
other file- and socket-related warnings in test_normalization, test_timeout and
test_tk that only show up when regrtest is run with -uall.
The warning
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nvawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1508475
___
___
Python-bugs-list
New submission from Nadeem Vawda nadeem.va...@gmail.com:
zlib.crc32() and zlib.adler32() in Modules/zlibmodule.c don't handle buffers of
=4GB correctly. The length of a Py_buffer is of type Py_ssize_t, while the C
zlib functions take length as an unsigned integer. This means that on a 64-bit
Nadeem Vawda added the comment:
Thanks for pointing that out; I've uploaded a second patch that changes
async_chat.__init__() to use 'sock' instead of 'conn'.
This change shouldn't affect anything either, since the argument is
simply passed to asyncore.dispatcher.__init__().
Added file: http
New submission from Nadeem Vawda:
The __init__() function for asynchat.async_chat doesn't allow the caller
to specify a channel map. I thought it would make sense to add an
optional 'map' parameter, for consistency with asyncore.dispatcher. If
the parameter is not specified
501 - 536 of 536 matches
Mail list logo
