Mailman 3 August 2007 - Python-Dev

zipfile module can't handle large files
by Kevin Ar18 30 Aug '07

30 Aug '07

Create a zip file with a file inside consisting of several GB (say 2 or 5 GB). The zipfile module will fail, when attempting to extract the large file. The issue is near line 490 in zifile.py. It appears that read (a file operation) is unable to read such large amounts of data. I tried editing zipfile.py so that read would read things piece by piece but just got a memory error. Does anyone know how to fix this limitation in the zipfile module? _________________________________________________________________ See what you’re getting into…before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507

3 2

whitespace-normalized commit hook...
by Bill Janssen 30 Aug '07

30 Aug '07

> Transmitting file data .........subversion/libsvn_client/commit.c:832: (apr_err=165001) > svn: Commit failed (details follow): > /build/buildd/subversion-1.4.2dfsg1/subversion/libsvn_repos/hooks.c:135: (apr_err=165001) > svn: 'pre-commit' hook failed with error output: > file /python/trunk/Lib/ssl.py is not whitespace-normalized So, the pre-commit hook is blocking me; how do I trouble-shoot this? What's the client-side way to run this scan? Can I add it to the regression-test harness? Bill

2 1

Re: [Python-Dev] whitespace-normalized commit hook...
by Thomas Wouters 30 Aug '07

30 Aug '07

On 8/29/07, Bill Janssen <janssen(a)parc.com> wrote: > > > Transmitting file data .........subversion/libsvn_client/commit.c:832: > (apr_err=165001) > > svn: Commit failed (details follow): > > /build/buildd/subversion-1.4.2dfsg1/subversion/libsvn_repos/hooks.c:135: > (apr_err=165001) > > svn: 'pre-commit' hook failed with error output: > > file /python/trunk/Lib/ssl.py is not whitespace-normalized > > So, the pre-commit hook is blocking me; how do I trouble-shoot this? > > What's the client-side way to run this scan? Can I add it to the > regression-test harness? It basically calls Tools/scripts/reindent.py with --dry-run (although I notice the version we call from SVN is more forgiving towards tokenizer errors. I'm not sure we need that here.) Incorporating it in the normal test suit would be good, as I've been caught by the same problem several times :-) -- Thomas Wouters <thomas(a)python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

1 0

Re: [Python-Dev] Other SSL issues in the tracker have been marked
by Gregory P. Smith 29 Aug '07

29 Aug '07

apt-get install openssl will fix that on those systems. on windows you're unlikely to ever have an openssl binary present and available to execute. On 8/26/07, Bill Janssen <janssen(a)parc.com> wrote: > > Now it looks as if both the Debian and Ubuntu failures are failing > because they can't create a certificate, just like the Windows test. > I'll go out on a limb here and guess that it's because "openssl" isn't > on the path of the user running the tests. > > That would also account for the other stack traces, if the keyfile > or certfile didn't actually contain a key or a cert. > > Bill > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org >

3 2

PEP 238 - The // operator should truncate instead of floor
by dany 29 Aug '07

29 Aug '07

Hi all First, some background. I've recently tried to port a certain library that manipulates dates from C. Some of the core functions contain heavy integer math (very long formulae), and after implementing them I tested them to see the give the desired results. I got very odd results, which surprised me since I copied the formula letter to letter. I decided to investigate further, and after trying to evaluate several expressions in the python console, I realized it was the integer division's fault. For some reason, the integer division behaves unexpectedly for negative integers. Looking deeper in the python PEPs, I saw that division on integers is defined as: idiv(a, b) = floor(fdiv(a, b)). This non-quotient division leads to some odd results, e.g. Python seems to think -3/2+3/2 = -1. This is clearly, and correct me if I'm mistaken - wrong. Now, seeing as Python 3000 is getting closer, and backwards compatibility isn't an issue, I believe it would be a good idea to change the // operator (which will be used for integer division) to behave as quotient, i.e.: a // b = trunc(a / b) Dany

4 3

Triage of old tracker bugs: Any use?
by Sean Reifschneider 29 Aug '07

29 Aug '07

I've taken the week off and I'm trying to do something useful for Python in some of my time. I've basically been looking through the entries sorted by priority and least recent activity. Some items I've been able to do something with (like the "immediate" priority %formatting bug #1467929, and the "high" priority bz2 module bug #1597011). Others I've been just kind of prodding people to take some action on, just kind of getting them in front of people again. Keeping them "fresh" instead of just letting them stagnate... I kind of figure that something that's in "high" priority, that has been sitting there for 46 months, either needs to have some activity on it or should be pushed to a lower priority. I've also been tempted to try to triage some of the bugs without assigned priorities, guessing a priority, that sort of thing. Is doing this sort of triage or administration work useful? Any recommendations on what you'd like to have happen in this sort of task? Thanks, Sean -- Obtuse: Not pointed or acute. Exceeding 90 degrees but less than 180 degrees. OOOooh! Rounded at the free end. Dull... Hey! That's an insult! -- WKRP Sean Reifschneider, Member of Technical Staff <jafo(a)tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability

4 3

Re: [Python-Dev] Other SSL issues in the tracker have been marked
by Guido van Rossum 29 Aug '07

29 Aug '07

Hi Bill, I think it's time you get to do your own checkins. There's a protocol but I forget how to do it -- I think you mail your ssh key to Martin. --Guido On 8/28/07, Bill Janssen <janssen(a)parc.com> wrote: > So, the patch is attached to issue 1052. I sent it out to python-dev, > but it got blocked (too big). > > http://bugs.python.org/file8352/ssl-patch-5 > > This contains a number of things: > > 1) Improve the documentation of the SSL module, with a fuller > explanation of certificate usage, another reference, proper > formatting of this and that. > > 2) Fix Windows bug in ssl.py, and general bug in sslsocket.close(). > Remove some unused code from ssl.py. Allow accept() to be called on > sslsocket sockets. > > 3) Use try-except-else in import of ssl in socket.py. Deprecate use of > socket.ssl(). > > 4) Remove use of socket.ssl() in every library module, except for > test_socket_ssl.py and test_ssl.py. > > Bill > -- --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

test_calendar broken on trunk
by skip＠pobox.com 29 Aug '07

29 Aug '07

On the community trunk buildbots this checkin: 1. Changed by: walter.doerwald Changed at: Tue 28 Aug 2007 16:38:27 Branch: trunk Revision: 57620 Changed files: * trunk/Doc/library/calendar.rst * trunk/Lib/calendar.py Comments: Fix title endtag in HTMLCalender.formatyearpage(). Fix documentation for HTMLCalender.formatyearpage() (there's no themonth parameter). This fixes issue1046. broke test_calendar. Details here: http://www.python.org/dev/buildbot/community/all/ Skip

2 1

Re: [Python-Dev] Other SSL issues in the tracker have been marked
by Neal Norwitz 29 Aug '07

29 Aug '07

On 8/26/07, Bill Janssen <janssen(a)parc.com> wrote: > > This occurs on at least 3 of the buildbots (ubuntu and debian on ia64, > > ppc, and hppa). Here's one example: > > > > http://python.org/dev/buildbot/all/ia64%20Ubuntu%20trunk%20trunk/builds/832… > > If I'm reading this right, it's passing tests on "amd64 gentoo trunk", > "x86 gentoo trunk", "g4 osx.4 trunk" (no surprise there). > > And looking at the community buildbots, it works on "x86 Redhat 9", > "x86 Debian unstable", "amd64 Ubuntu gutsy", "G5 OS X", and so on. > I've tested it myself on FC 7 and it works. > > And looking at the "ppc Debian unstable" case, test_socket is also > failing there, so the test_ssl failure is not a big surprise. > > I'm not familiar with what's in Debian "trunk" or Ubuntu "trunk"; any > idea what version of OpenSSL they have in them? For ia64 http://python.org/dev/buildbot/all/ia64%20Ubuntu%20trunk%20trunk/builds/833… pybot@noisy:~$ openssl version OpenSSL 0.9.8b 04 May 2006 I have access to some of the machines but not all of them. All of these run inside a chroot which might be causing a problem. I remember some issues with getting socket stuff to work right on them. But that was over a year ago and I don't remember the details now. :-( svn/google probably knows if you want to trawl through checkins. I'm not sure that will help much though. On this machines I was able to successfully make a key. That's why I'm thinking it might be some strange socket issue. > But I think this exposes a more generic bug in test_ssl.py, which is > that the server thread doesn't die when one of these failures occurs. > It probably should. I'll make a patch -- but I don't have a system > that this fails on, how will I test it? Yeah, I know this is difficult. Hopefully someone with WIndows will step up to help. We can at least make the test more robust and verify the files exist and are non-zero in size. I will do that now. At least the it shouldn't cause the test to time out. n

2 3

Merging a branch, and new docs
by Facundo Batista 29 Aug '07

29 Aug '07

Hello everybody. Mark Dickinson helped a lot (*a lot*) with the decimal branch, and we're near to pass the brand new test cases from Cowlishaw. My original idea is to update all the documentation before merging the branch into the trunk, but now that they changed so much, I don't know what to do: - Update all the Doc dir in the branch with the new Doc dir in the trunk, fix the docs, and make the merge. - Merge the branch, and fix the docs directly in the trunk (I promise to fix them months before 2.6a0). Thanks for the advice! Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

1 0