[issue1580738] httplib hangs reading too much data

Facundo Batista added the comment: Mark is ok, zero length responses are ok. But that has nothing to do with self.length. self.lenght reaching zero means that everything that needed to be read is already read. If the read() method is called without an argument, it reads everything until it reach

[issue1580738] httplib hangs reading too much data

Marcos Dione added the comment: with facundo we were tracking this bug down. mhammond is right about that read() should allow 0 size responses, but the bug is that the response is "not closed". HTTPResponse.read() says: if amt is None: # unbounded read if self.l

[issue1274] doctest fails to run file based tests with 8bit paths

Changes by Brett Cannon: -- keywords: +patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue1275] bsddb closing a DB object before all DBCursors using it are closed crashes

New submission from Gregory P. Smith: If a bsddb.db.DB object is closed before any DBCursor objects referencing it are closed, python will crash when the cursors are closed or deleted. Workaround: never close a database with open cursors. this is annoying in unittest code where a tearDown metho

[issue1233] bsddb.dbshelve.DbShelf.append doesn't work

Gregory P. Smith added the comment: Fixed in python trunk r58434, release25-maint r58435, py3k r58438 -- resolution: -> fixed status: open -> closed versions: +Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> _

[issue1274] doctest fails to run file based tests with 8bit paths

New submission from Mike Taylor: In our builds the included patch fixes this issue. Patch by Brian Kirsch, tested at OSAF on Python 2.5.1 -- nosy: +bear __ Tracker <[EMAIL PROTECTED]> __

[issue1274] doctest fails to run file based tests with 8bit paths

Changes by Mike Taylor: -- components: Tests severity: major status: open title: doctest fails to run file based tests with 8bit paths type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> __

[issue1251] ssl module doesn't support non-blocking handshakes

Chris Stawarz added the comment: > The loop in _ssl.c/do_handshake will never return WANT_READ or > WANT_WRITE, so the loop in the test case, for instance, is > unnecessary. I don't know why you think that, but it's easy enough to show that this statement is incorrect. I've attached two scr

[issue1251] ssl module doesn't support non-blocking handshakes

Bill Janssen added the comment: Chris, Looking at this a bit harder, I don't see that it accomplishes much. The loop in _ssl.c/do_handshake will never return WANT_READ or WANT_WRITE, so the loop in the test case, for instance, is unnecessary. The original code handled the non-blocking case

[issue1233] bsddb.dbshelve.DbShelf.append doesn't work

Gregory P. Smith added the comment: heh yep that does look like a bug. Laughing at that one goes well with this comment currently in test_dbshelve.py: # TODO: Add test cases for a DBShelf in a RECNO DB. i'll fix it. :) __ Tracker <[EMAIL PROTECTED]>

[issue1271] Raw string parsing fails with backslash as last character

Georg Brandl added the comment: There's more to allowing \ at the end of a raw string: if you do that, the raw string will end at the first quote character which is the same as the opening one, so you can't put such a quote character into a raw string anymore. At the moment, you can, by escaping

[issue1273] email module example email-unpack.py error

New submission from Ed Vinyard: In the email module example, email-unpack.py (http://docs.python.org/lib/email-unpack.txt), line 56 throws an AttributeError. It is currently ext = mimetypes.guess_extension(part.get_type()) I think this line should be ext = mimetypes.guess_extension(pa

[issue1268] array unittest problems with UCS4 build

Christian Heimes added the comment: svn annotate shows that you implemented the 'w' typecode in revision 57181. What do you think about my patch and my proposal? -- nosy: +teoliphant __ Tracker <[EMAIL PROTECTED]> __

[issue1272] Decode __file__ and co_filename to unicode using fs default

Changes by Martin v. Löwis: -- keywords: +patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue1272] Decode __file__ and co_filename to unicode using fs default

New submission from Christian Heimes: I'm sending the patch in for review. -- components: Interpreter Core files: py3k_file_fsenc2.patch messages: 56374 nosy: tiran severity: normal status: open title: Decode __file__ and co_filename to unicode using fs default versions: Python 3.0

[issue1271] Raw string parsing fails with backslash as last character

Tim Gordon added the comment: So basically raw strings are useless if you need to end a string with a backslash, as there is no way to quote the backslash to make it not do this... This surely can't be too hard to "fix" if one considers it a problem (which I do), and just because even the doc

[issue1271] Raw string parsing fails with backslash as last character

Facundo Batista added the comment: As stated in the docs... http://docs.python.org/dev/reference/lexical_analysis.html#string-literals r"\" is not a valid string literal (even a raw string cannot end in an odd number of backslashes). Specifically, a raw string cannot end in a single b

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

Andre M. Descombes added the comment: Thanks Martin, I think you are right, perhaps someone on the python-list will have seen and solved the problem before. Andre __ Tracker <[EMAIL PROTECTED]> _

[issue1271] Raw string parsing fails with backslash as last character

New submission from Tim Gordon: If you have a raw string with a backslash as the last character, the parser thinks the following quote, actually used to mark the end of the string, is being quoted by the backslash. For example, r'\' should be the string with one backslash, but... >>> print r

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

Martin v. Löwis added the comment: I personally don't think this problem can be resolved by discussion. Instead, you have to use a debugger, debug your application, Python, and Windows, to find out the true cause of the problem. Only then discussion can be fruitful. If you cannot do these steps

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

Andre M. Descombes added the comment: Ok, so where would you recommend I move this discussion to? Andre On 10/12/07, Martin v. Löwis <[EMAIL PROTECTED]> wrote: > > > Martin v. Löwis added the comment: > > > I set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag on python and I still get > the > > memory

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

Martin v. Löwis added the comment: > I set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag on python and I still get the > memoryerror exceptions. When they start happening there is still more than > 1GB of available memory! Just in case it isn't clear: I still don't see an indication of a bug in Python

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

Andre M. Descombes added the comment: I set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag on python and I still get the memoryerror exceptions. When they start happening there is still more than 1GB of available memory! __ Tracker <[EMAIL PROTECTED]>

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

Andre M. Descombes added the comment: Apparently, XP is more lax when it comes to checking this flag on the programs it runs then Windows 2003 Server. I am currently doing a test where I have manually added the flag to python to see if this makes the problem go away. I will post my results as soo

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

Martin v. Löwis added the comment: No, Python does not have IMAGE_FILE_LARGE_ADDRESS_AWARE set; that's not a bug, though. In any case, the lack of this flag cannot explain why your application works on Windows XP and not on Windows 2003. __ Tracker <[EMAIL PROTEC

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

Andre M. Descombes added the comment: Martin, it is really a bug, as I have tried on a machine with Windows 2003 server and 4GBs of ram and it still doesn't run, and it does run on xp with only 1GB of ram. Does python.exe have then IMAGE_FILE_LARGE_ADDRESS_AWARE bit set, that could explain the b

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

Changes by Martin v. Löwis: -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

Martin v. Löwis added the comment: Please understand that the purpose of this bug tracker is to track bug reports and patches to Python, not a means of getting help in using Python. If you think you have found a bug, please submit a bug report that allows us to reproduce the bug. If you merely ne

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

New submission from Andre M. Descombes: Hi everybody, I am using Python 2.5.1. I am creating a rather large dictionnary, with more than 8 million entries, memory usage should be about 1.5GB. If I run the program on Windows XP all runs fine, if I run the program on Windows Server 2003 I start get

[issue1216] Python2.5.1 fails to compile under VC.NET2002 ( 7.0 )

Changes by Martin v. Löwis: -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list

[issue1216] Python2.5.1 fails to compile under VC.NET2002 ( 7.0 )

Martin v. Löwis added the comment: Thanks for the report. This is now fixed in r58430 and r584301 __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list

[issue1216] Python2.5.1 fails to compile under VC.NET2002 ( 7.0 )

Martin v. Löwis added the comment: The actual change that broke that was r41672, which added the ULL suffix. r46064 fixed it for VC6 and embedded VC. Raising the minimum _MSC_VER to above 1300 is fine (VC 7.1 is 1310). I personally can't test with VS 2002 anymore, so I have to trust that it doe

[issue1269] Exception in pstats print_callers()

New submission from Andrew Stromnov: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pstats >>> ps = pstats.Stats("profile.log") >>> ps.add("profile.log") >>> ps.print_callers(

[issue1268] array unittest problems with UCS4 build

Changes by Martin v. Löwis: -- keywords: +patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p