Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(362)

Issue 2724043: py3k lzma patch

Can't Edit
Can't Publish+Mail
Start Review
Created:
8 years, 6 months ago by proyvind
Modified:
8 years, 6 months ago
Reviewers:
Martin v. Löwis
Base URL:
http://svn.python.org/view/*checkout*/python/branches/py3k/
Visibility:
Public.

Description

patch that adds the lzma module.

Patch Set 1 #

Total comments: 7
Unified diffs Side-by-side diffs Delta from patch set Stats (+4652 lines, --1 lines) Patch
Doc/library/lzma.rst View 1 chunk +451 lines, -0 lines 1 comment Download
Lib/test/test_lzma.py View 1 chunk +585 lines, -0 lines 0 comments Download
Lib/test/teststring.xz View 0 chunks +-1 lines, --1 lines 0 comments Download
Modules/lzmamodule.c View 1 chunk +3605 lines, -0 lines 6 comments Download
setup.py View 1 chunk +12 lines, -0 lines 0 comments Download

Messages

Total messages: 5
proyvind
8 years, 6 months ago (2010-10-31 15:00:01 UTC) #1
Martin v. Löwis
http://codereview.appspot.com/2724043/diff/1/Doc/library/lzma.rst File Doc/library/lzma.rst (right): http://codereview.appspot.com/2724043/diff/1/Doc/library/lzma.rst#newcode54 Doc/library/lzma.rst:54: .. attribute:: lzma.options.check The attribute is called check, not ...
8 years, 6 months ago (2010-10-31 16:33:38 UTC) #2
proyvind
On 2010/10/31 16:33:38, Martin v. Löwis wrote: > http://codereview.appspot.com/2724043/diff/1/Doc/library/lzma.rst > File Doc/library/lzma.rst (right): > > ...
8 years, 6 months ago (2010-10-31 20:46:13 UTC) #3
Martin v. Löwis
>> Modules/lzmamodule.c:264: lzma_FILE *fp; >> I suggest that struct lzma_FILE is inlined here - no ...
8 years, 6 months ago (2010-10-31 21:21:28 UTC) #4
proyvind
8 years, 6 months ago (2010-10-31 21:32:17 UTC) #5
On 2010/10/31 21:21:28, Martin v. Löwis wrote:
> >> Modules/lzmamodule.c:264: lzma_FILE *fp;
> >> I suggest that struct lzma_FILE is inlined here - no need to have a
> > separate
> >> memory block.
> > Not sure what you mean..? Moving the definition within LZMAFileObject
> > would seem rather tedious IMO, but I'm probably not fully grasping what
> > you mean..?
> 
> I think LZMAFileObject should go like this:
> 
> ...
>   char* f_bufptr;
>   unsigned char buf[1<<15];
>   lzma_stream strm;
>   FILE *fp;
>   int encoding;
>   int eof;
>   lzma_filter filters[LZMA_FILTERS_MAX + 1];
> 
> and then lzma_close/lzma_read/lzma_write should just expect
> an LZMAFileObject, instead of an lzma_FILE. lzma_open would not
> allocate lzma_file anymore, but be passed an LZMAFileObject as
> well.
> 
> Why would that be tedious?
Ah, never mind, I was thinking in a totally different way, makes sense now. :)
> 
> That leaves the issue aside that I think the module shouldn't be using
> stdio in the first place.
I guess I'll end up rewriting it in a totally different not using it at all
anyways.. :p
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b