[Python-Dev] if __debug__: except Exception, e: pdb.set_trace()
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 being included as if they were at the same level as the 'if __debug__:' above them? I want to allow this: try: foo() if __debug__: except Exception, e: import pdb pdb.set_trace() So that when __debug__ is false, the except block doesn't even exist at all. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if __debug__: except Exception, e: pdb.set_trace()
"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 or entire blocks (except, > else, elif, etc.) with them being included as if they were at the same > level as the 'if __debug__:' above them? I would say very low. try/except/finally, if/elif/else, for/else, while/else, etc., pairings of statements historically have only been grouped together when they share indent levels. If one makes two statements that don't share indent levels paired in this way, then what is stopping us from doing the following monstronsity? if ...: ... if __debug__: elif ...: ... Remember, Special cases aren't special enough to break the rules. This would be a bad special case that doesn't generalize in a satisfactory manner. > I want to allow this: > > try: > foo() > if __debug__: > except Exception, e: > import pdb > pdb.set_trace() > > So that when __debug__ is false, the except block doesn't even exist at all. And if the except clause doesn't exist at all, then unless you are following it with the finally clause of a 2.5+ unified try/except/finally, it is a syntax error. Regardless, it would be easier to read to have the following... try: foo() except Exception, e: if __debug__: import pdb pdb.set_trace() else: raise - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom
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 concat, stringbench is ever-so-slightly faster overall. "172.82" > vs "174.85" for the "ascii" column, I guess that's in seconds. I'm just > happy it's not slower. (I only ran stringbench once; it seems to take > *forever*). > > I ran pybench three times for each build. The slowest concat overall > time was still 2.9% faster than the fastest release time. > "ConcatStrings" is a big winner, at around 150% faster; since the test > doesn't *do* anything with the concatenated values, it never renders the > concatenation objects, so it does a lot less work. > "CreateStringsWithConcat" is generally 18-19% faster, as expected. > After that, the timings are all over the place, but some tests were > consistently faster: "CompareInternedStrings" was 8-12% faster, > "DictWithFloatKeys" was 9-11% faster, "SmallLists" was 8-15% faster, > "CompareLongs" was 6-10% faster, and "PyMethodCalls" was 4-6% faster. > (These are all comparing the "average run-time" results, though the > "minimum run-time" results were similar.) When comparing results, please look at the minimum runtime. The average times are just given to indicate how much the mintime differs from the average of all runs. > I still couldn't tell you why my results are faster. I swear on my > mother's eyes I didn't touch anything major involved in > "DictWithFloatKeys", "SmallLists", or "CompareLongs". I didn't touch > the compiler settings, so that shouldn't be it. I acknowledge not only > that it could all be a mistake, and that I don't know enough about it to > speculate.// Depending on what you changed, it is possible that the layout of the code in memory better fits your CPU architecture. If however the speedups are not consistent across several runs of pybench, then it's likely that you have some background activity going on on the machine which causes a slowdown in the unmodified run you chose as basis for the comparison. Just to make sure: you are using pybench 2.0, right ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 09 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom
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 patched versions out there :) Oh, and since I have fixed the pcbuild8 thingy in the 2.5 branch, why don't you give the PGO version a whirl too? Even the non-PGO dll, with link-time code generation, should be faster than your vanilla PCBuild one. Read the Readme.txt for details. Cheers, Kristján > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of M.-A. Lemburg > Sent: 9. október 2006 09:30 > To: Larry Hastings > Cc: [email protected] > Subject: Re: [Python-Dev] PATCH submitted: Speed up + for > string concatenation, now as fast as "".join(x) idiom > > 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 concat, stringbench is ever-so-slightly faster > overall. "172.82" > > vs "174.85" for the "ascii" column, I guess that's in seconds. I'm > > just happy it's not slower. (I only ran stringbench once; > it seems to > > take *forever*). > > > > I ran pybench three times for each build. The slowest > concat overall > > time was still 2.9% faster than the fastest release time. > > "ConcatStrings" is a big winner, at around 150% faster; > since the test > > doesn't *do* anything with the concatenated values, it > never renders > > the concatenation objects, so it does a lot less work. > > "CreateStringsWithConcat" is generally 18-19% faster, as expected. > > After that, the timings are all over the place, but some tests were > > consistently faster: "CompareInternedStrings" was 8-12% faster, > > "DictWithFloatKeys" was 9-11% faster, "SmallLists" was > 8-15% faster, > > "CompareLongs" was 6-10% faster, and "PyMethodCalls" was > 4-6% faster. > > (These are all comparing the "average run-time" results, though the > > "minimum run-time" results were similar.) > > When comparing results, please look at the minimum runtime. > The average times are just given to indicate how much the > mintime differs from the average of all runs. > > > I still couldn't tell you why my results are faster. I swear on my > > mother's eyes I didn't touch anything major involved in > > "DictWithFloatKeys", "SmallLists", or "CompareLongs". I > didn't touch > > the compiler settings, so that shouldn't be it. I acknowledge not > > only that it could all be a mistake, and that I don't know enough > > about it to speculate.// > > Depending on what you changed, it is possible that the layout > of the code in memory better fits your CPU architecture. > > If however the speedups are not consistent across several > runs of pybench, then it's likely that you have some > background activity going on on the machine which causes a > slowdown in the unmodified run you chose as basis for the comparison. > > Just to make sure: you are using pybench 2.0, right ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Oct 09 2006) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > __ > __ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/kristjan%40c cpgames.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.5, 64 bit
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? Cheers, Kristján ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Security Advisory for unicode repr() bug?
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 handled by the PSRT at all? Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Iterating over marshal/pickle
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 EOFError:
break
This seems like a good use case for an generator:
def some_name(fobj):
while True:
try:
yield marshal.load(fobj) # or yield unpickler.load()
except EOFError:
raise StopIteration
1. Does this seem like a reasonable addition to the standard library?
2. Where should it go, and what should it be called?
>From an end-user point of view, this "feels" right:
import pickle
u = pickle.Unpickler(open('picklefile'))
for x in u:
print x
import marshal
for x in marshal.unmarshalled(open('marshalfile')):
print x
But I'm not hung up on the actual names or the use of sequence
semantics in the Unpickler case.
Incidentally, I know that pickle is preferred over marshal, but some
third-party tools (like the Perforce client) still use the marshal
library for serialization, so I've included it in the discussion
--
Tim Lesher <[EMAIL PROTECTED]>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterating over marshal/pickle
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 P4 integration, you probably don't want to use Python's marshal.load to deal with the P4 output either; the marshalling code has had a tendency to crash Python when it sees malformed or pre- maturely terminated output). > Incidentally, I know that pickle is preferred over marshal, but some > third-party tools (like the Perforce client) still use the marshal > library for serialization, so I've included it in the discussion Perforce is the only 3rd party component I'm aware of that uses a standard Python serialization format in this way. As the x windows people have observed, the only thing worse than generalizing from one example is generalizing from no examples at all.. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterating over marshal/pickle
-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 code every other > year > or so, so my answer is definitely no. FWIW, Mailman uses pickle files with multiple pickled objects in them, to implement its queue files. We first dump the Message object, followed by a dictionary of metadata. OTOH, I know there's only two objects in the pickle, so I don't have to iterate over it; I just load the message and then load the dictionary. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRSpyaHEjvBPtnXfVAQLqcgP/VqKqwZfReaQyRGP2DG61978CmbqLOvSY nsXP/AE88VvO+IHYajfNuJt/okmTIfHTl9Jcx77YzxZ9ErtpKWbmrX6zo7OkaZPv 5aYQ7zsYwJocL5u6nFqXAs+9zvUOXLvwhKFDc5K/rp4cb02QAYOgn5gpRirJNSAm ESMiMNRmdQ8= =3Ih4 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Security Advisory for unicode repr() bug?
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 I ask again whether this is handled by the PSRT at all? I agree that having an official Python security advisory would be good to see. I was also assuming automatically that fixed versions of Python 2.4 and Python 2.3 would be released. It's a serious issue for web-facing Python applications that handle unicode strings. Regards, Martijn ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5, 64 bit
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 interest in fixing this up? Yes; I had fixed many of them already for the Python 2.5 release (there were *way* more of these before I started). Notice that many of them are bogus. For example, if I do strlen on a buffer that is known to have MAXPATH bytes, the strlen result *can't* exceed an int. So care is necessary for each case: - if there is a conceivable case where it can overflow (i.e. if you could come up with a Python program that makes it overflow), fix the types appropriately - if it is certain through inspection that it can't overflow, add a cast (Py_SAFE_DOWNCAST, or, when it is really obvious, a plain cast), and a comment on why the cast is correct. Notice that Py_SAFE_DOWNCAST has an assertion in debug mode. Also notice that it evaluates it argument twice. - if it shouldn't overflow as long as extension modules play by the rules, it's your choice of either adding a runtime error, or just widening the representation. IIRC, the biggest chunk of "real" work left is SRE: this can realistically overflow when it operates on large strings. You have to really understand SRE before fixing it. For example, I believe that large strings might have impacts on compilation, too (e.g. if the regex itself is >2GiB, or some repetition count is >2**31). In these cases, it might be saner to guarantee an exception (and document the limitation) than to try expanding the SRE bytecode. Another set of remaining changes deals with limitations on byte code and reflection. For example, there is currently a limit on the number of local variables imposed by the Python bytecode. From this limit, it follows that certain casts are correct. One should document each limit first, and then refer to these limits when adding casts. Helping here would be definitely appreciated. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterating over marshal/pickle
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 definitely no. > > (if you're serious about P4 integration, you probably don't want to use > Python's marshal.load to deal with the P4 output either; the marshalling > code has had a tendency to crash Python when it sees malformed or pre- > maturely terminated output). > >> Incidentally, I know that pickle is preferred over marshal, but some >> third-party tools (like the Perforce client) still use the marshal >> library for serialization, so I've included it in the discussion > > Perforce is the only 3rd party component I'm aware of that uses a > standard Python serialization format in this way. > > As the x windows people have observed, the only thing worse than > generalizing from one example is generalizing from no examples at > all.. FWIW, we've been and are using this quite a lot for dumping database content to a backup file. It's a simple and terse format, preserves full data precision and doesn't cause problems when moving between platforms. That makes two use cases and I'm sure there are more ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 09 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.4 vs Windows vs bsddb
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: locally defined symbol _malloc imported in function __db_associateCallback _bsddb.obj : warning LNK4217: locally defined symbol _free imported in function __DB_consume _bsddb.obj : warning LNK4217: locally defined symbol _fclose imported in function _DB_verify _bsddb.obj : warning LNK4217: locally defined symbol _fopen imported in function _DB_verify _bsddb.obj : warning LNK4217: locally defined symbol _strncpy imported in function _init_pybsddb _bsddb.obj : error LNK2019: unresolved external symbol __imp__strncat referenced in function _makeDBError _bsddb.obj : error LNK2019: unresolved external symbol __imp___assert referenced in function _makeDBError ./_bsddb_d.pyd : fatal error LNK1120: 2 unresolved externals ... _bsddb - 3 error(s), 5 warning(s) Build: 15 succeeded, 1 failed, 0 skipped """ The warnings there are old news, but no idea when the errors started. The test suite doesn't care that bsddb is missing either, just ending with: 1 skip unexpected on win32: test_bsddb Same kind of things when building from my 2.4 checkout. No clues. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] BUG (urllib2) Authentication request header is broken on long usernames and passwords
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 this:
-->8-cut-8<
GET /some/url HTTP/1.1
Host: some.host
Accept-Encoding: identity
Authorization: Basic
cmVhbGx5bG9uZ3VzZXJuYW1lOmFuZXZlbmxvbmdlcnBhc3N3b3JkdGhhdGdvZXNvbmFuZG9uYW5k
b25hbmRvbmFuZG9u
User-agent: some-agent
-->8-cut-8<
This can be worked around by forcing the base64.MAXBINSIZE to
something huge, but really it should be something passed into
base64.encodestring().
# echo example of it wrapping...
# python -c 'import base64; print base64.encodestring("f"*58)'
# excho example of forcing it not to wrap...
# python -c 'import base64; base64.MAXBINSIZE=100; print
base64.encodestring("f"*58)'
Symptoms of this bug are receiving HTTP 400 responses from the
remote server, spurious authentication errors, or various parts of
the header "vanishing" (because of the double newline).
Thanks!
--
** Ridiculous Quotes **
"I want to say this about my state: When Strom Thurmond ran for
president, we voted for him. We're proud of it. And if the rest of
the country had followed our lead, we wouldn't have had all these
problems over all these years, either."
-- Senate Minority Leader Trent Lott (R-MS), praising Strom
Thurmond's segregationist presidential campaign [12/5/02]
The Doctor What: Second Baseman
http://docwhat.gerf.org/
docwhat *at* gerf *dot* org
KF6VNC
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BUG (urllib2) Authentication request header is broken on long usernames and passwords
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://www.pythoncraft.com/ "If you don't know what your program is supposed to do, you'd better not start writing it." --Dijkstra ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BUG (urllib2) Authentication request header is broken on long usernames and passwords
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 each. All line breaks or other characters
not found in Table 1 must be ignored by decoding software.
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.
--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 vs Windows vs bsddb
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; this just happened with the _ssl.pyd module before. I'm not sure how build.bat communicates an error, or whether devenv.com fails in some way when some build step fails. Revision 43156 may contribute here, which adds additional commands into build.bat after devenv.com is invoked. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 vs Windows vs bsddb
[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 "compile" step to fail; this just happened with the _ssl.pyd > module before. I'm guessing only on the release24-maint branch? > I'm not sure how build.bat communicates an error, or whether devenv.com > fails in some way when some build step fails. > > Revision 43156 may contribute here, which adds additional commands > into build.bat after devenv.com is invoked. More guessing: devenv gives a non-zero exit code when it fails, and a .bat script passes on the exit code of the last command it executes. True or false, after making changes based on those guesses, the 2.4 Windows buildbots now say they fail the compile step. It was my fault to begin with (boo! /bad/ Timmy), but should have been unique to the 24 branch (2.5 and trunk fetch Unicode test files all by themselves). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 vs Windows vs bsddb
[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 -0400 (Thu, 05 Oct 2006) | 12 lines [Backport r50783 | neal.norwitz. The bytes_left code is complicated, but looks correct on a casual inspection and hasn't been modified in the trunk. Does anyone want to review further?] Ensure we don't write beyond errText. I think I got this right, but it definitely could use some review to ensure I'm not off by one and there's no possible overflow/wrap-around of bytes_left. Reported by Klocwork #1. Fix a problem if there is a failure allocating self->db. Found with failmalloc. """ It introduces uses of assert() and strncat(), and the linker can't resolve them. I suppose that's because the Windows link step for the _bsddb subproject explicitly excludes msvcrt (in the release build) and msvcrtd (in the debug build), but I don't know why that's done. OTOH, we got a lot more errors (about duplicate code definitions) if the standard MS libraries aren't explicitly excluded, so that's no fix. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BUG (urllib2) Authentication request header is broken on long usernames and passwords
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 fixed in the same way (assuming your fix is
correct), since urllib also uses base64.{de,en}codestring().
John
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 vs Windows vs bsddb
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 broke the build (not so on my own installation for a strange reason), and the buildbot didn't complain, either. I was surprised to see a bug report on SF that it wouldn't build. > More guessing: devenv gives a non-zero exit code when it fails, and a > .bat script passes on the exit code of the last command it executes. That's my theory also. Thanks for fixing it, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
