[ python-Bugs-1389051 ] imaplib causes excessive fragmentation for large documents
Bugs item #1389051, was opened at 2005-12-23 19:11 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib causes excessive fragmentation for large documents Initial Comment: When fetching large documents via SSL, the imaplib attempts to read it all in one chunk, but the SSL socket layer only returns ~16k at a time. The result is that Python will end up allocating, say, a 15 megabyte block, shrink it to a few kilobytes, occasionally allocate a medium-sized block (to hold the list of chunks), and repeat this again and again and again. Not all malloc implementations can reuse the (15 megabytes minus a few kilobyte) block when allocating the next 15 megabyte block. In a worst case scenario, you'll need some 13 gigabytes of virtual memory to read a 15 megabyte message... A simple solution is to change data = self.sslobj.read(size-read) to data = self.sslobj.read(min(size-read, 16384)) For more on this, see this thread: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/3737500bac287575/d715bf614a86e786 -- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-25 11:57 Message: Logged In: YES user_id=38376 As noted in that thread, the same problem applies to non- SSL accesses. The problematic line is: data = self._sock.recv(recv_size) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1389809 ] Fxn call in _elementtree.c has incorrect signedness
Bugs item #1389809, was opened at 2005-12-25 00:35 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389809&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Fredrik Lundh (effbot) Summary: Fxn call in _elementtree.c has incorrect signedness Initial Comment: Line 2149 in Modules/_elementtree.c calls PyUnicode_Decode() with an array of ``unsigned char`` while the definition of the function in Objects/unicodeobject.c has the argument as ``const char *``. Here is the relevant output from the build: /Users/drifty/Code/Trees/svn/python/trunk/Modules/_elementtree.c: In function 'expat_unknown_encoding_handler': /Users/drifty/Code/Trees/svn/python/trunk/Modules/_elementtree.c:2149: warning: pointer targets in passing argument 1 of 'PyUnicodeUCS2_Decode' differ in signedness -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389809&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1386675 ] _winreg specifies EnvironmentError instead of WindowsError
Bugs item #1386675, was opened at 2005-12-21 02:41 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: _winreg specifies EnvironmentError instead of WindowsError Initial Comment: The _winreg documentation says that EnvironmentError will be raised (throughout the docs, for various reasons), when, in every case, WindowsError is actually raised. A simple replace of WindowsError for EnvironmentError would fix this. (Let me know if you really need a patch). -- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-25 12:44 Message: Logged In: YES user_id=38376 however, note that >>> issubclass(WindowsError, EnvironmentError) True on windows, and >>> issubclass(WindowsError, EnvironmentError) Traceback (most recent call last): File "", line 1, in NameError: name 'WindowsError' is not defined on non-windows platforms, so it might be done this way on purpose. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1390086 ] ScrolledText hungs up in some conditions
Bugs item #1390086, was opened at 2005-12-25 18:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390086&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: dani_filth (dani_filth) Assigned to: Nobody/Anonymous (nobody) Summary: ScrolledText hungs up in some conditions Initial Comment: The next code causes Python to hung in some conditions : #-- from ScrolledText import * root=Tk() ScrolledText(root, bg='white').pack(fill=BOTH, expand=YES) root.mainloop() #-- Run the script. Pass focus to the text field. Then enter one Tab and type several letters. After that with having pushed Ctrl-key press several times UP button. Script hungs with 100% CPU-usage. P.S. My config : WinXP sp2, python 2.4.2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390086&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1390197 ] tempfile misses usecase which requirs renaming
Feature Requests item #1390197, was opened at 2005-12-25 20:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1390197&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dennis Allison (dallison) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile misses usecase which requirs renaming Initial Comment: tempfile provides a very convenient API but it seems to miss one important use case. For example, suppose the program is stream editing the file. Typically one reads the source file, edits the data, and writes it to a temporary file. Upon successful completion of the edit, the program renames the temporary to be the original source file, which is atomic in most operating systems, There does not appear to be any neat way to do this with the current API without the program throwing an exception because of the deletion wrapper. Perhaps a "rename" method needs to be added to manage the delete seamlessly. I am not especially fond of that solution as it adds new functionality to file descriptors. . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1390197&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1386675 ] _winreg specifies EnvironmentError instead of WindowsError
Bugs item #1386675, was opened at 2005-12-21 14:41 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: _winreg specifies EnvironmentError instead of WindowsError Initial Comment: The _winreg documentation says that EnvironmentError will be raised (throughout the docs, for various reasons), when, in every case, WindowsError is actually raised. A simple replace of WindowsError for EnvironmentError would fix this. (Let me know if you really need a patch). -- >Comment By: Tony Meyer (anadelonbrin) Date: 2005-12-26 15:36 Message: Logged In: YES user_id=552329 I don't see what purpose there is in having the documentation say that EnvironmentError is raised, when a subclass is. _winreg is still marked as a temporary module to be replaced, so it's hard to believe it's some sort of future-proofing. One could say that Exception is raised, since EnvironmentError is a subclass of Exception, but explicit is better than implicit, right? (import _winreg fails on non-Windows platforms, so I don't see how it could be for cross-platform reasons, either). -- Comment By: Fredrik Lundh (effbot) Date: 2005-12-26 00:44 Message: Logged In: YES user_id=38376 however, note that >>> issubclass(WindowsError, EnvironmentError) True on windows, and >>> issubclass(WindowsError, EnvironmentError) Traceback (most recent call last): File "", line 1, in NameError: name 'WindowsError' is not defined on non-windows platforms, so it might be done this way on purpose. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1390321 ] README mention --without-cxx
Bugs item #1390321, was opened at 2005-12-25 20:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390321&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Aahz (aahz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: README mention --without-cxx Initial Comment: This just verified against HEAD: ./configure fails on Linux without g++ installed unless --without-cxx given. README should mention this. Error is checking for C++ compiler default output file name... configure: error: C++ compiler cannot create executables Inside config.log it says: gcc: installation problem, cannot exec 'cc1plus': No such file or directory (There's been some discussion about not requiring C++ installation by default -- until that's settled, we should at least update the README.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390321&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
