Re: [Python-Dev] 2.4 vs Windows vs bsddb

2006-10-09 Thread Martin v. Löwis
Tim Peters schrieb: > [Martin v. Löwis] >> It's been a while that a failure to build some extension modules doesn't >> cause the "compile" step to fail; this just happened with the _ssl.pyd >> module before. > > I'm guessing only on the release24-maint branch? Yes. I backported some change which

Re: [Python-Dev] BUG (urllib2) Authentication request header is broken on long usernames and passwords

2006-10-09 Thread John J Lee
On Mon, 9 Oct 2006, Scott Dial wrote: [...] > In retrospect, perhaps "{de|en}codestring" was a poor name choice. > urllib2 should be calling b64encode directly. > > I have submitted a patch to the tracker: [ 1574068 ] urllib2 - Fix line > breaks in authorization headers. urllib should also be fixe

Re: [Python-Dev] 2.4 vs Windows vs bsddb

2006-10-09 Thread Tim Peters
[Tim] > I just noticed that the bsddb portion of Python fails to compile on > the 2.4 Windows buildbots, but for some reason the buildbot machinery > doesn't notice the failure: But it does now. This is the revision that broke the Windows build: """ r52170 | andrew.kuchling | 2006-10-05 14:49:36

Re: [Python-Dev] 2.4 vs Windows vs bsddb

2006-10-09 Thread Tim Peters
[Tim Peters] >> I just noticed that the bsddb portion of Python fails to compile on >> the 2.4 Windows buildbots, but for some reason the buildbot machinery >> doesn't notice the failure: [Martin v. Löwis] > It's been a while that a failure to build some extension modules doesn't > cause the "comp

Re: [Python-Dev] 2.4 vs Windows vs bsddb

2006-10-09 Thread Martin v. Löwis
Tim Peters schrieb: > I just noticed that the bsddb portion of Python fails to compile on > the 2.4 Windows buildbots, but for some reason the buildbot machinery > doesn't notice the failure: It's been a while that a failure to build some extension modules doesn't cause the "compile" step to fail;

Re: [Python-Dev] BUG (urllib2) Authentication request header is broken on long usernames and passwords

2006-10-09 Thread Scott Dial
The Doctor What wrote: > The problem is that base64.encodestring() adds newlines to wrap the > encoded characters at the 76th column. > The encodestring is following RFC 1521 which speficies: The output stream (encoded bytes) must be represented in lines of no more than 76 characters eac

Re: [Python-Dev] BUG (urllib2) Authentication request header is broken on long usernames and passwords

2006-10-09 Thread Aahz
On Mon, Oct 09, 2006, The Doctor What wrote: > > I found a bug in urllib2's handling of basic HTTP authentication. Please submit your bug to SourceForge, then (optional) post the bug number back here. See http://www.python.org/dev/faq/#bugs -- Aahz ([EMAIL PROTECTED]) <*> http:

[Python-Dev] BUG (urllib2) Authentication request header is broken on long usernames and passwords

2006-10-09 Thread The Doctor What
I found a bug in urllib2's handling of basic HTTP authentication. urllib2 uses the base64.encodestring() method to encode the username:password. The problem is that base64.encodestring() adds newlines to wrap the encoded characters at the 76th column. This produces bogus request headers like thi

[Python-Dev] 2.4 vs Windows vs bsddb

2006-10-09 Thread Tim Peters
I just noticed that the bsddb portion of Python fails to compile on the 2.4 Windows buildbots, but for some reason the buildbot machinery doesn't notice the failure: """ Compiling... _bsddb.c Linking... Creating library .\./_bsddb_d.lib and object .\./_bsddb_d.exp _bsddb.obj : warning LNK4217:

Re: [Python-Dev] Iterating over marshal/pickle

2006-10-09 Thread M.-A. Lemburg
Fredrik Lundh wrote: > Tim Lesher wrote: > >> 1. Does this seem like a reasonable addition to the standard library? > > I cannot remember ever doing this, or seeing anyone except Perforce > doing this, and it'll only save you a few lines of code every other year > or so, so my answer is definit

Re: [Python-Dev] 2.5, 64 bit

2006-10-09 Thread Martin v. Löwis
Kristján V. Jónsson schrieb: > the VisualStudio8 64 bit build of 2.5 doesn't compile clean. We have a > number of warnings of truncation from 64 bit to 32: > Often it is a question of doing an explicit cast, but sometimes we are > using "int" for results from strlen and such. > > Is there any in

Re: [Python-Dev] Security Advisory for unicode repr() bug?

2006-10-09 Thread Martijn Faassen
Georg Brandl wrote: > Georg Brandl wrote: >> [ Bug http://python.org/sf/1541585 ] >> >> This seems to be handled like a security issue by linux distributors, >> it's also a news item on security related pages. >> >> Should a security advisory be written and official patches be >> provided? > > May

Re: [Python-Dev] Iterating over marshal/pickle

2006-10-09 Thread Barry Warsaw
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 9, 2006, at 11:28 AM, Fredrik Lundh wrote: >> 1. Does this seem like a reasonable addition to the standard library? > > I cannot remember ever doing this, or seeing anyone except Perforce > doing this, and it'll only save you a few lines of cod

Re: [Python-Dev] Iterating over marshal/pickle

2006-10-09 Thread Fredrik Lundh
Tim Lesher wrote: > 1. Does this seem like a reasonable addition to the standard library? I cannot remember ever doing this, or seeing anyone except Perforce doing this, and it'll only save you a few lines of code every other year or so, so my answer is definitely no. (if you're serious about

[Python-Dev] Iterating over marshal/pickle

2006-10-09 Thread Tim Lesher
Both marshal and pickle allow multiple objects to be serialized to the same file-like object. The pattern for deserializing an unknown number of serialized objects looks like this: objs = [] while True: try: objs.append(marshal.load(fobj)) # or objs.append(unpickler.load()) except EOFErro

Re: [Python-Dev] Security Advisory for unicode repr() bug?

2006-10-09 Thread Georg Brandl
Georg Brandl wrote: > [ Bug http://python.org/sf/1541585 ] > > This seems to be handled like a security issue by linux distributors, > it's also a news item on security related pages. > > Should a security advisory be written and official patches be > provided? May I ask again whether this is ha

[Python-Dev] 2.5, 64 bit

2006-10-09 Thread Kristján V . Jónsson
the VisualStudio8 64 bit build of 2.5 doesn't compile clean.  We have a number of warnings of truncation from 64 bit to 32: Often it is a question of doing an explicit cast, but sometimes we are using "int" for results from strlen and such.   Is there any interest in fixing this up?   Cheer

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom

2006-10-09 Thread Kristján V . Jónsson
This patch looks really nice to use here at CCP. Our code is full of string contcatenations so I will probably try to apply the patch soon and see what it gives us in a real life app. The floating point integer cache was also a big win. Soon, standard python won't be able to keep up with the

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom

2006-10-09 Thread M.-A. Lemburg
Larry Hastings wrote: > Fredrik Lundh wrote: >> [EMAIL PROTECTED] wrote: >> >>> MAL's pybench would probably be better for this presuming it does some >>> addition with string operands. >>> >> or stringbench. >> > > I ran 'em, and they are strangely consistent with pystone. > > With co

Re: [Python-Dev] if __debug__: except Exception, e: pdb.set_trace()

2006-10-09 Thread Josiah Carlson
"Calvin Spealman" <[EMAIL PROTECTED]> wrote: > > I know I can not do this, but what are the chances on changing the > rules so that we can? Basically, since the if __debug__: lines are > processed before runtime, would it be possible to allow them to be > used to control the inclusion or omission

[Python-Dev] if __debug__: except Exception, e: pdb.set_trace()

2006-10-09 Thread Calvin Spealman
I know I can not do this, but what are the chances on changing the rules so that we can? Basically, since the if __debug__: lines are processed before runtime, would it be possible to allow them to be used to control the inclusion or omission or entire blocks (except, else, elif, etc.) with them be