Nadeem Vawda added the comment:
The same failure has appeared on the Debian bigmem buildbot:
http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/152/steps/test/logs/stdio
--
versions: +Python 3.3
___
Python tracker
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14154>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue14113>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Nadeem Vawda :
--
nosy: +eric.araujo, nadeem.vawda
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue14183>
___
___
Python-
Nadeem Vawda added the comment:
>>
>> -install.install_dists = lambda x, y=None: None
>> +install.install_dists = lambda x, y = None: None
>> PEP 8: Never put spaces in a function (or lambda) signature.
>
> I cannot find that exactly in pep8.
&g
Nadeem Vawda added the comment:
I had intended to wait until the code had been tested on all of the
buildbots before closing it. However, it's taking a while to get xz-utils
installed on the last few bots, so it doesn't make sense to keep the
issue open for this.
--
Changes by Nadeem Vawda :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue5689>
___
___
Python-bugs-list mailing list
Unsubscri
Nadeem Vawda added the comment:
Is this a single failure that you encountered, or have you been able to
reproduce it on subsequent runs? I haven't seen a failure in
test_concurrent_futures in 10-15 runs of "make test" (also on Ubuntu
11.10 64-bit).
--
nosy: +nad
Nadeem Vawda added the comment:
> I happended several times.
Hmm. If you hit another failure, can you post the random seed and any
other interesting info that might help figure this out?
The test_dbm failures look like issue 14120. You might want to follow up
there.
--
n
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14229>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
This looks similar to a sporadic failure on the debian bigmem buildbot:
http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/168/steps/test/logs/stdio
ERROR: test_expanduser (test.test_posixpath.PosixPathTest
Nadeem Vawda added the comment:
Jesús, did you have any particular idea about exactly where these new
features would be useful? Or was your idea that someone needs to read
through the code and check whether the features can be used at all?
Also, it should be noted that the scope of this issue
Changes by Nadeem Vawda :
--
nosy: +alanmcintyre, nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14366>
___
___
Python-bugs-list mailing list
Unsub
Nadeem Vawda added the comment:
[Adding Alan McIntyre, who is listed as zipfile's maintainer.]
I haven't yet had a chance to properly familiarize myself with the
zipfile module, but I did notice an issue in the changes to ZipExtFile's
read() method. The existing code uses the b
Nadeem Vawda added the comment:
I plan on doing a review of the patch, but it might be a week or two
before I have time to do it.
Regarding changes to lzma; exactly what is being proposed? If it's just
additional functions for encoding and decoding of filter specs, then I'm
fine with
Nadeem Vawda added the comment:
> You made a mess. The existing code uses ``buf += data``, but I allowed myself
> to replace it with the ``b"".join()`` idiom. The bzip2 codec has to deal with
> large pieces of data, now this may be important. In read1 still used ``buf +=
&
Nadeem Vawda added the comment:
Patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue13902>
___
___
Python-bugs-list mailing list
Unsub
Nadeem Vawda added the comment:
I have been able to reproduce it; see attached script. It happens for
inputs of 2GB (decompressed), but not for ones of 1GB.
It seems that bz2module.c doesn't guard against 32-bit overflows when
handling the size of the decompressed data. This affects bot
Nadeem Vawda added the comment:
(the contents of the input file don't matter; I just pulled out a
bunch of zeros from /dev/zero and compressed them with bzip2.)
--
___
Python tracker
<http://bugs.python.org/is
Changes by Nadeem Vawda :
--
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue14398>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
This should be fixed for 2.7.3. I'll have a patch ready in the next day
or two.
--
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org
Nadeem Vawda added the comment:
No, it's been around since at least 2.6. I wasn't really sure what the
protocol was for bugs found during the RC process. It'd be nice to get
a fix for this into 2.7.3 (and 3.2.3), but it's not urgent.
--
priority: relea
Nadeem Vawda added the comment:
That's fine by me, then. Sorry for the confusion.
--
___
Python tracker
<http://bugs.python.org/issue14398>
___
___
Pytho
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14548>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14684>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
I've posted a review on Rietveld.
--
___
Python tracker
<http://bugs.python.org/issue14684>
___
___
Python-bugs-list m
New submission from Nadeem Vawda :
Patch attached. Reviews welcome.
--
components: Extension Modules
files: lzma-properties.diff
keywords: patch
messages: 160051
nosy: nadeem.vawda
priority: normal
severity: normal
stage: patch review
status: open
title: Add {encode,decode
Nadeem Vawda added the comment:
I've put together a patch for the lzma module adding functions for
encoding and decoding filter properties (see issue 14736). It's a bit
bulky, though, so I'd like to get a review before committing it.
--
___
Nadeem Vawda added the comment:
> The functionality looks a bit cryptic to me. What is the use case?
Serializing filter specifiers for custom file formats. The particular
case that prompted adding the code is zipfile (issue 14366).
I've added a note to the docs and docstrings explain
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14583>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Committed as changeset 9118ef2b651a.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
I've committed my patch as changeset 9118ef2b651a, adding functions
encode_filter_properties and decode_filter_properties to the lzma module.
--
___
Python tracker
<http://bugs.python.org/is
Nadeem Vawda added the comment:
Changeset 9118ef2b651a was broken, but the bug should have been fixed by
changeset 10ccbb90a8e9. Which revision have you been using?
> But there are no tests for these functions.
There *are* tests for these functions, and they were failing on some of
Nadeem Vawda added the comment:
> "popitem()
> Remove and return an arbitrary (key, value) pair from the dictionary. Raises
> KeyError if the dict is empty. Use next(iter(d)) to return an arbitrary pair
> without removing it."
Actually, next(iter(d)) on a dict returns
Nadeem Vawda added the comment:
The code should be changed to use the buffer API (instead of accepting
only bytes objects). Other than that, I think it's ready for integration.
--
___
Python tracker
<http://bugs.python.org/is
Nadeem Vawda added the comment:
There is already such a function, gzip.decompress() - it was added in 3.2.
--
nosy: +nadeem.vawda
resolution: -> invalid
stage: -> committed/rejected
status: open -> pending
___
Python track
Nadeem Vawda added the comment:
> To restate my position: the need is for an immutable string of bytes, [...]
I disagree that we should require the dictionary to be immutable - if the
caller wishes to use a mutable buffer here, it is their responsibility to
ensure that it is not modified un
Nadeem Vawda added the comment:
I plan to commit it (along with the buffer API changes) tomorrow.
--
___
Python tracker
<http://bugs.python.org/issue14
Nadeem Vawda added the comment:
Committed. Once again, thanks for the patch!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
> Just saw this on the checkins list; where are the other options documented?
They aren't, AFAIK. I've been planning on adding them when I've got time
(based on the zlib manual at http://zlib.net/manual.html), but with the
upcoming feature fr
Nadeem Vawda added the comment:
Patch looks fine to me.
Antoine, can you commit this? I'm currently away from the computer that
has my SSH key on it.
--
___
Python tracker
<http://bugs.python.org/is
Nadeem Vawda added the comment:
I already fixed this without knowing about this issue; see 55202ca694d7.
storchaka:
> Why not use io.TextWrapper? I think it is the right answer for this issue.
The proposed patch (and the code I committed) *do* use TextIOWrapper.
Unless you mean that call
Nadeem Vawda added the comment:
Merging nosy list from duplicate issue 15155.
--
nosy: +giampaolo.rodola, neologix, pitrou
___
Python tracker
<http://bugs.python.org/issue13
Nadeem Vawda added the comment:
+1 for the general idea of deprecating and eventually removing the "U"
modes.
But I agree with David, that it doesn't make sense to have separate steps
for 3.5 and 3.6/4.0. If you make the code raise an exception when "U" is
used, how is
Changes by Nadeem Vawda :
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
I can't seem to reproduce this with an up-to-date checkout from Mercurial:
>>> import bz2
>>> g = bz2.open('access-log-0108.bz2','rt')
>>> next(g)
'140.180.132.213 - - [24/Feb/2008:00:08:59
Nadeem Vawda added the comment:
The cause of this problem is that BZ2File.read1() sometimes returns b"", even
though
the file is not at EOF. This happens when the underlying BZ2Decompressor cannot
produce
any decompressed data from just the block passed to it in _fill_buffer(); in
Nadeem Vawda added the comment:
OK, BZ2File should now be fixed. It looks like LZMAFile and GzipFile may
be susceptible to the same problem; I'll push fixes for them shortly.
--
___
Python tracker
<http://bugs.python.org/is
Nadeem Vawda added the comment:
Done.
Thanks for the bug report, David.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
Before these fixes, it looks like all three classes' peek() methods were
susceptible
to the same problem as read1().
The fixes for BZ2File.read1() and LZMAFile.read1() should have fixed peek() as
well;
both methods are implemented in terms of _fill_b
Nadeem Vawda added the comment:
No, if _read() is called once the file is already at EOF, it raises an
EOFError (http://hg.python.org/cpython/file/8c07ff7f882f/Lib/gzip.py#l433),
which will then break out of the loop.
--
___
Python tracker
<h
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue15654>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Thanks for the patch. Unfortunately I don't have much free time at the
moment, so it might be a few weeks before I get a chance to review it.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Nadeem Vawda :
--
superseder: -> test_curses skipped on buildbots
___
Python tracker
<http://bugs.python.org/issue15664>
___
___
Python-bugs-lis
Nadeem Vawda added the comment:
> Nadeem: is the failure you show in msg141798 with a version of test_curses
> that uses pty.openpty?
Yes, I tried the following change:
--- a/Lib/test/test_curses.py
+++ b/Lib/test/test_curses.py
@@ -328,11 +328,12 @@
curses.r
Changes by Nadeem Vawda :
--
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue12669>
___
___
Python-bugs-list mailing list
Unsubscri
Nadeem Vawda added the comment:
As far as I can tell, there is no way to find this out reliably without
decompressing the entire file. With gzip, the file trailer contains the
uncompressed size modulo 2^32, but this seems less than useful. It appears that
the other two formats do not store
Nadeem Vawda added the comment:
Thanks for the bug report, Victor, and thank you Serhiy for the patch!
Serhiy, would you be OK with me also including this patch in the bz2file
package?
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +P
Nadeem Vawda added the comment:
> Yes, of course.
Awesome. I plan to do a new release for this in the next couple of days.
> We can even speed up 1.5 times the reading of small chunks, if we inline
> _check_can_read() and _read_block().
Interesting idea, but I don't think i
Nadeem Vawda added the comment:
> Recursive inline _check_can_read() will be enough. Now this check calls 4
> Python functions (_check_can_read(), readable(), _check_non_closed(),
> closed). Recursive inlining only readable() in _check_can_read() is achieved
> significant but le
Nadeem Vawda added the comment:
Ah, nice - I didn't think of that optimization. Neater and faster.
I've committed this patch [e6d872b61c57], along with a minor bugfix
[7252f9f95fe6], and another optimization for readline()/readlines()
[6d7bf512e0c3]. [merge with default: a19f47d
Nadeem Vawda added the comment:
I've released v0.95 of bz2file, which incorporates all the optimizations
discussed here. The performance should be similar to 2.x's bz2 in most cases.
It is still a lot slower when calling read(10) or read(1), but I hope no-one is
doing that anyw
Changes by Nadeem Vawda :
--
resolution: -> works for me
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
No sign of these failures any more; looks like that fixed it.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Nadeem Vawda :
--
resolution: -> rejected
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
Are we still planning on removing URLopener and FancyURLopener in 3.4? The
documentation for 3.3 does not list these classes as deprecated.
--
___
Python tracker
<http://bugs.python.org/issue10
Nadeem Vawda added the comment:
Hmm, OK. URLopener and FancyURLopener do each issue a DeprecationWarning when
used, though. If they are not actually deprecated, perhaps we should remove the
warnings for the moment?
--
___
Python tracker
<h
Changes by Nadeem Vawda :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
The data corruption issue is now fixed in the 2.7 branch.
In 3.x, using a mode containing 'U' results in an exception rather than silent
data corruption. Additionally, gzip.open() has supported text modes
("rt"/"wt"/"at&
Nadeem Vawda added the comment:
I'm working on it now. Will push in the next 15 minutes or so.
--
___
Python tracker
<http://bugs.python.org/issue14398>
___
___
Nadeem Vawda added the comment:
All fixed, along with some other similar but harder-to-trigger bugs.
Thanks for the bug report, Laurent!
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Pytho
Changes by Nadeem Vawda :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Nadeem Vawda:
>From issue 5210:
amaury.forgeotdarc wrote:
> Hm, I tried a modified version of your first test, and I found another
> problem with the current zlib library;
> starting with the input:
> x = x1 + x2 + HAMLET_SCENE# both compressed and un
Nadeem Vawda added the comment:
This bug (zlib not providing a way to detect end-of-stream) has already
been fixed - see issue 12646.
I've opened issue 16350 for the unused_data problem.
--
resolution: -> out of date
stage: test needed -> committed/rejected
status: ope
Nadeem Vawda added the comment:
Interesting idea, but I'm not sure it would be worth the effort. It would
make the code and API more complicated, so it wouldn't really help users,
and would be an added maintenance burden.
--
___
Python trac
Nadeem Vawda added the comment:
Thanks for the patch, Nikolaus. I'm afraid I haven't had a chance to look
over it yet; this past week has been a bit crazy for me. I'll definitely
get back to you with a review in the next week, though.
--
___
Nadeem Vawda added the comment:
I've posted a review at http://bugs.python.org/review/15955/. (For some reason,
it looks like Rietveld didn't send out email notifications. But maybe it never
sends a notification to the sender? Hmm.)
--
Nadeem Vawda added the comment:
Sorry, I just haven't had any free time lately, and may still not be able
to give this the attention it deserves for another couple of weeks.
Serhiy, would you be interested in reviewing Nikolaus' patch?
--
Nadeem Vawda added the comment:
Fixed. Thanks for the patch!
> This hacking is not needed, if first argument of PyBytes_FromStringAndSize()
> is NULL, the contents of the bytes object are uninitialized.
Oh, cool. I didn't know about that.
> What should unconsumed_tail be equa
New submission from Nadeem Vawda:
When calling zlib.Decompress.decompress() with a max_length argument,
if the input data is not full consumed, the next_in pointer in the
z_stream struct are left pointing into the data object, but the
decompressor does not hold a reference to this object. This
Nadeem Vawda added the comment:
> flush() does not update unconsumed_tail and unused_data.
>
> >>> import zlib
> >>> x = zlib.compress(b'abcdefghijklmnopqrstuvwxyz') + b'0123456789'
> >>> dco = zlib.decompressobj()
> >>> d
Nadeem Vawda added the comment:
I agree that being able to limit output size is useful and desirable, but
I'm not keen on copying the max_length/unconsumed_tail approach used by
zlib's decompressor class. It feels awkward to use, and it complicates
the implementation of the existing
Nadeem Vawda added the comment:
I suspect that it will be slower than the decompress_into() approach, but
as you say, we need to do benchmarks to see for sure.
--
___
Python tracker
<http://bugs.python.org/issue15
Nadeem Vawda added the comment:
> These were not idle questions. I wrote the patch, and I had to know
> what behavior is correct.
Ah, sorry. I assumed you were going to submit a separate patch to fix the
unconsumed_tail issues.
> Here's the patch. It fixes potent
Nadeem Vawda added the comment:
Looks good to me. Go ahead.
You needn't add or change any tests for this, but you should run the
existing tests before committing, just to be safe.
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.py
Nadeem Vawda added the comment:
New patch committed. Once again, thanks for all your work on this issue!
--
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Nadeem Vawda added the comment:
Ah, that's much nicer than either of my ideas. Patch committed. Thanks!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyth
Nadeem Vawda added the comment:
Committed. Thanks for the patch!
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
type: -> enhancement
___
Python tracker
<http://bugs.python
Nadeem Vawda added the comment:
I've tried reimplementing LZMAFile in terms of the decompress_into()
method, and it has ended up not being any faster than the existing
implementation. (It is _slightly_ faster for readinto() with a large
buffer size, but all other cases it was either of
Nadeem Vawda added the comment:
>> # Using zlib's interface
>> while not d.eof:
>> compressed = d.unconsumed_tail or f.read(8192)
>> if not compressed:
>> raise ValueError('End-of-stream marker not found')
>
Nadeem Vawda added the comment:
Fixed. Thanks for the bug report and the patches!
--
assignee: -> nadeem.vawda
keywords: +3.3regression -patch
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Py
Changes by Nadeem Vawda :
--
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> seriously? urllib still doesn't support persistent connections?
___
Python tracker
<http://bugs.p
Nadeem Vawda added the comment:
I've reviewed the patch and posted some comments on Rietveld.
> I doubt about backward compatibility. It's obvious that struct.error and
> TypeError are unintentional, and EOFError is purposed for this case. However
> users can catch undocu
Nadeem Vawda added the comment:
> What if unconsumed_tail is not empty but less than needed to decompress at
> least one byte? We need read more data until unconsumed_tail grow enought to
> be decompressed.
This is possible in zlib, but not in bz2. According to the manual [1], it is
Nadeem Vawda added the comment:
The updated patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue1159051>
___
___
Python-bugs-list mailin
Changes by Nadeem Vawda :
--
assignee: -> nadeem.vawda
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7
___
Python tracker
<http://bugs.python
Nadeem Vawda added the comment:
You're right; it breaks backspacing over multibyte characters. I should
have tested it more carefully before committing. I'll revert the changes.
--
resolution: fixed ->
stage: committed/rejected -> needs patch
status
Nadeem Vawda added the comment:
I think the new behavior should be controlled by a constructor flag, maybe
named "defer_errors". I don't like the idea of adding the flag to read(),
since that makes us diverge from the standard file interface. Making a
distinction between size&
Changes by Nadeem Vawda :
--
assignee: -> nadeem.vawda
nosy: +nadeem.vawda
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Changes by Nadeem Vawda :
--
assignee: -> nadeem.vawda
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
401 - 500 of 535 matches
Mail list logo
