Nadeem Vawda added the comment:
Fix committed. Thanks for the patches!
As Jesús and Terry have said, this won't be backported to 3.3/2.7, since
it is a new feature.
[oylenshpeegul]
| It's weird how different these three patches are! We're
| essentially doing the same thing: &q
Nadeem Vawda added the comment:
[terry.reedy]
| Arfrever's point about the order of characters makes me wonder why mode
| strings (as opposed to characters in the strings) are being checked.
| The following tests that exactly one of w, a, x appear in mode.
| if len({'w', '
Nadeem Vawda added the comment:
As far as I can tell, liblzma provides no way to serialize a compressor's
state, so the best we can do is raise a TypeError when attempting to
pickle the LZMACompressor (and likewise for LZMADecompressor).
Also, it's worth pointing out that the pro
Nadeem Vawda added the comment:
Yes, that's because the builtin map function doesn't handle each input
in a separate process, so it uses the same LZMACompressor object
everywhere. Whereas multiprocessing.Pool.map creates a new copy of the
compressor object for each input, which is
Nadeem Vawda added the comment:
It looks like there's also a separate problem in the multiprocessing
module. The following code hangs after hitting a TypeError trying to
pickle one of the TextIOWrapper objects:
import multiprocessing
def read(f): return f.read()
files = [open
Nadeem Vawda added the comment:
The part of this issue specific to LZMACompressor should now be fixed;
I've filed issue 19425 for the issue with Pool.map hanging.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: ope
New submission from Nadeem Vawda:
[Split off from issue 19395]
The following code hangs after hitting a TypeError trying to pickle one
of the TextIOWrapper objects:
import multiprocessing
def read(f): return f.read()
files = [open(path) for path in 3 * ['/dev/null']
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue19227>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
I'll have a patch for this in the next couple of days (and a similar one
for the lzma module, which has the same issue (even though it's not a
regression in that case)).
In the meanwhile, you can work around this by feeding the compressed
Nadeem Vawda added the comment:
It appears that this *does* affect 2.7 (though not 3.2, 3.3 or 3.4,
fortunately):
~/src/cpython/2.7☿ gdb --ex run --args ./python -c 'import bz2; obj =
bz2.BZ2File("/dev/null"); obj.__init__("")'
«... snip banner ...»
Nadeem Vawda added the comment:
To clarify, which version(s) does this affect? I have not been able to
reproduce against 3.4, and 2.7 does not included the lzma module in the
first place.
--
___
Python tracker
<http://bugs.python.org/issue19
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue20182>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue20184>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue20185>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
The patches for bz2 and lzma look good to me, aside from one nit for lzma.
--
___
Python tracker
<http://bugs.python.org/issue20
Nadeem Vawda added the comment:
No, I'm afraid I haven't had a chance to do any work on this issue since my last
message.
I would be happy to review a patch for this, but before you start writing one,
we should settle on how the API will look. I'll review the existing discussion
Nadeem Vawda added the comment:
The bz2 patch looks good to me, aside from a nit with the docstring for
BZ2Compressor.__init__.
The lzma patch produces a bunch of test failures for me. It looks like
the __init__ methods for LZMACompressor and LZMADecompressor aren't
accepting keyword
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue20358>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
I can reproduce this (also on Ubuntu 13.10 64-bit). Maybe there's a bug
in the version of curses distributed with the latest Ubuntu release? It
looks like our only Ubuntu buildbot is using 8.04 (almost 6 years old!).
Also note that you won't be able to
Nadeem Vawda added the comment:
The latest patch for zlib seems to be missing Modules/zlibmodule.clinic.c
> I suppose that zdict=b'' have same effect as not specifying zdict. Am I right?
Probably, but to be on the safe side I'd prefer that we preserve the behav
Nadeem Vawda added the comment:
The patch for zlib looks good to me. Thanks for working on this, Serhiy.
> We're not allowing changes in semantics for Argument Clinic conversion for
> 3.4. If it doesn't currently accept None, we can't add it right now, and
> we&#x
Nadeem Vawda added the comment:
After some consideration, I've come to agree with Serhiy that it would be better
to keep a private internal buffer, rather than having the user manage unconsumed
input data. I'm also in favor of having a flag to indicate whether the
decompressor needs
Nadeem Vawda added the comment:
As Serhiy said, multi-stream support was only added to the bz2 module in 3.3,
and there is no plan to backport functionality this to 2.7.
However, the bz2file package on PyPI [1] does support multi-stream inputs,
and you can use its BZ2File class as a drop-in
Nadeem Vawda added the comment:
> How does one create a multi-stream bzip2 file in the first place?
If you didn't do so deliberately, I would guess that you used a parallel
compression tool like pbzip2 or lbzip2 to create your bz2 file. These tools work
by splitting the input int
Nadeem Vawda added the comment:
This change fixes the problem (and doesn't break anything else that I can see):
--- a/Lib/test/test_ssl.py
+++ b/Lib/test/test_ssl.py
@@ -979,7 +979,7 @@
self.sslconn = self.server.context.wrap_socket(
self
Nadeem Vawda added the comment:
> You could add a comment explaining the issue.
Done.
This doesn't seem to affect 2.7. Marking as fixed in 3.2/3.3/3.4.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versi
Nadeem Vawda added the comment:
An oversight on my part, I think. I'll add tests for 3.x this weekend.
--
status: closed -> open
___
Python tracker
<http://bugs.python.org
Nadeem Vawda added the comment:
Hmm, so actually most of the bugs fixed in 2.7 and 3.2 weren't present
in 3.3 and 3.4, and those versions already had tests equivalent to the
tests I added for 2.7/3.2.
As for the changes that I did make to 3.3/3.4:
- two of the three cover cases that only
Nadeem Vawda added the comment:
Oh dear. I'll update the test suite over the weekend. In the meanwhile,
Christian, can you confirm which versions are affected? The file should only
have been included in 2.7 and 3.2.
--
assignee: -> nade
Nadeem Vawda added the comment:
OK, 2.7 is done.
Georg, what do we want to do for 3.2? I've attached a patch.
--
assignee: nadeem.vawda -> georg.brandl
keywords: +patch
Added file: http://bugs.python.org/file30049/bz2-viruswarning.diff
__
Nadeem Vawda added the comment:
Benjamin, please cherry-pick this for 2.7.4 as well (changesets b7bfedc8ee18
and 529c4defbfd7).
--
stage: needs patch -> commit review
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issu
Nadeem Vawda added the comment:
Have you tried running the benchmark against the default (3.4) branch?
There was some significant optimization work done in issue 16034, but
the changes were not backported to 3.3.
--
___
Python tracker
<h
Nadeem Vawda added the comment:
I agree that making lzma.open() wrap its return value in a BufferedReader
(or BufferedWriter, as appropriate) is the way to go. I'm currently
travelling and don't have my SSH key with me - Serhiy, can you make the
change?
I'll put together a docu
Nadeem Vawda added the comment:
> I agree that making lzma.open() wrap its return value in a BufferedReader
> (or BufferedWriter, as appropriate) is the way to go.
On second thoughts, there's no need to change the behavior for mode='wb'.
We can just return a BufferedRead
Nadeem Vawda added the comment:
No, that is the intended behavior for binary streams - they operate at
the level of individual byes. If you want to treat your input file as
Unicode-encoded text, you should open it in text mode. This will return a
TextIOWrapper which handles the decoding and line
501 - 535 of 535 matches
Mail list logo
