[ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work
Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&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: Tkinter Group: Python 2.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. Löwis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-19 09:15 Message: Logged In: YES user_id=21627 Originator: NO Closing as "won't fix". There are no plans to implement --disable-sunaudiodev --disable-tk options to configure. -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-06 18:51 Message: Logged In: YES user_id=21627 The component isn't vital. It shouldn't be relevant for building sunaudiodev whether an audio device is present in the system, as this device isn't necessary for *building* Python. Instead, presence of /usr/include/sys/audioio.h is necessary. I'm puzzled that this file isn't there (it is part of the core development environment, AFAIK); the build process assumes that the header is present if the system name is "sunos5". -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-06 10:23 Message: Logged In: YES user_id=1597584 i would appreciate if the build completes without errors. i won't care if it attemts to build, but it should figure out that the sunaudiodev is not there. to my knowledge servers do not need that component. and python should not need it too then. do you see any reason why these components are vital for python? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-04 00:25 Message: Logged In: YES user_id=21627 It doesn't build the modules, as it doesn't succeed when attempting to. Why do you want it not to attempt? -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-03 12:56 Message: Logged In: YES user_id=1597584 what do you suggest then to convince the build not to build it? -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-02 06:40 Message: Logged In: YES user_id=21627 Re: enable/disable: What makes you think "sunaudiodev" and "tk" are valid values for "FEATURE"? configure --help lists the valid values for FEATURE, namely universalsdk, framework, shared, profiling, toolbox-glue, ipv6, and unicode. Re: there is a compilation error. Sure, an error is reported. However, compilation should not fail because of that. Instead, compila
[ python-Bugs-1579931 ] not configured for tk
Bugs item #1579931, was opened at 2006-10-18 21:59 Message generated for change (Comment added) made by nironius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&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: Demos and Tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carl Wenrich (carlwenrich) Assigned to: Nobody/Anonymous (nobody) Summary: not configured for tk Initial Comment: When I try to run the sample tkinter script (hello.py) I get a message saying my python isn't configured for tk. -- Comment By: Borisov Michael (nironius) Date: 2006-11-19 12:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-19 00:06 Message: Logged In: YES user_id=21627 Why do you think this is a bug? What operating system are you using, and where do your Python binaries come from? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1579931 ] not configured for tk
Bugs item #1579931, was opened at 2006-10-18 21:59 Message generated for change (Comment added) made by nironius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&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: Demos and Tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carl Wenrich (carlwenrich) Assigned to: Nobody/Anonymous (nobody) Summary: not configured for tk Initial Comment: When I try to run the sample tkinter script (hello.py) I get a message saying my python isn't configured for tk. -- Comment By: Borisov Michael (nironius) Date: 2006-11-19 12:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working -- Comment By: Borisov Michael (nironius) Date: 2006-11-19 12:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-19 00:06 Message: Logged In: YES user_id=21627 Why do you think this is a bug? What operating system are you using, and where do your Python binaries come from? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1579931 ] not configured for tk
Bugs item #1579931, was opened at 2006-10-18 20:59 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&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: Demos and Tools Group: Python 2.4 >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Carl Wenrich (carlwenrich) Assigned to: Nobody/Anonymous (nobody) Summary: not configured for tk Initial Comment: When I try to run the sample tkinter script (hello.py) I get a message saying my python isn't configured for tk. -- Comment By: Borisov Michael (nironius) Date: 2006-11-19 11:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working -- Comment By: Borisov Michael (nironius) Date: 2006-11-19 11:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-18 23:06 Message: Logged In: YES user_id=21627 Why do you think this is a bug? What operating system are you using, and where do your Python binaries come from? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599055 ] csv module does not handle '\x00'
Bugs item #1599055, was opened at 2006-11-19 01:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Day (shday) Assigned to: Nobody/Anonymous (nobody) Summary: csv module does not handle '\x00' Initial Comment: The following from an interactive session failed instead of just returning the '\x00': >>> r = csv.reader(['a,line,with,a,null,\x00,byte']) >>> r.next() Traceback (most recent call last): File "", line 1, in -toplevel- r.next() Error: string with NUL bytes >>> -- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 15:09 Message: Logged In: YES user_id=849994 Originator: NO Why do you think a CSV reader should support null bytes? CSV is a text format, not a binary one. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 16:03 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=1599254&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Settings changed) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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.5 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599055 ] csv module does not handle '\x00'
Bugs item #1599055, was opened at 2006-11-18 20:47 Message generated for change (Comment added) made by shday You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Day (shday) Assigned to: Nobody/Anonymous (nobody) Summary: csv module does not handle '\x00' Initial Comment: The following from an interactive session failed instead of just returning the '\x00': >>> r = csv.reader(['a,line,with,a,null,\x00,byte']) >>> r.next() Traceback (most recent call last): File "", line 1, in -toplevel- r.next() Error: string with NUL bytes >>> -- >Comment By: Stephen Day (shday) Date: 2006-11-19 12:08 Message: Logged In: YES user_id=948502 Originator: YES I've been using the csv module to parse data coming from a serial port of a lab instrument. Occasionally the instrument transmits a lone /x00 (maybe when the power cycles, I'm not sure). Anyhow, I'm now using a try-except statement to catch the error. I guess my answer to your question is that I think the module should handle whatever string you pass it. Is there a specific reason not to handle /x00? -- Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 10:09 Message: Logged In: YES user_id=849994 Originator: NO Why do you think a CSV reader should support null bytes? CSV is a text format, not a binary one. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599055 ] csv module does not handle '\x00'
Bugs item #1599055, was opened at 2006-11-19 01:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&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.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Stephen Day (shday) Assigned to: Nobody/Anonymous (nobody) Summary: csv module does not handle '\x00' Initial Comment: The following from an interactive session failed instead of just returning the '\x00': >>> r = csv.reader(['a,line,with,a,null,\x00,byte']) >>> r.next() Traceback (most recent call last): File "", line 1, in -toplevel- r.next() Error: string with NUL bytes >>> -- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 17:23 Message: Logged In: YES user_id=849994 Originator: NO The core of the csv module is coded in C, so null bytes are as always notoriously problematic when handling strings. (This is why there's a specific error message only for null bytes.) I think that the try-except is the sanest solution to this. -- Comment By: Stephen Day (shday) Date: 2006-11-19 17:08 Message: Logged In: YES user_id=948502 Originator: YES I've been using the csv module to parse data coming from a serial port of a lab instrument. Occasionally the instrument transmits a lone /x00 (maybe when the power cycles, I'm not sure). Anyhow, I'm now using a try-except statement to catch the error. I guess my answer to your question is that I think the module should handle whatever string you pass it. Is there a specific reason not to handle /x00? -- Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 15:09 Message: Logged In: YES user_id=849994 Originator: NO Why do you think a CSV reader should support null bytes? CSV is a text format, not a binary one. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599325 ] htmlentitydefs.entitydefs assumes Latin-1 encoding
Bugs item #1599325, was opened at 2006-11-19 14:40 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=1599325&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 Private: No Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: htmlentitydefs.entitydefs assumes Latin-1 encoding Initial Comment: The code in htmlentitydefs.py that sets entitydefs uses chr whenever the codepoint is <= 0xff. This should be <= 0x7f. As it currently stands, htmlentitydefs.entitydefs['nbsp'] == '\xa0'. But this is only "true" in the Latin-1 encoding. For example, in UTF8, the same character (u'\xa0') would be encoded '\xc2\xa0'. While I think it is reasonable for entitydefs to use the ASCII codec for characters encodable in that codec (<= 0x7f), I do not think it is reasonable to assume Latin-1 encoding. This issue affects sgmllib.SGMLParser, for example, when handle_entityref calls handle_data. The passed data can be '\xa0', which handle_data is forced to assume is Latin-1, when the source string might be encoded otherwise. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599325&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-1599329 ] urllib(2) should allow automatic decoding by charset
Feature Requests item #1599329, was opened at 2006-11-19 14:47 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=1599329&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 Private: No Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: urllib(2) should allow automatic decoding by charset Initial Comment: Currently, urllib.urlopen(...).read() returns a string, not a unicode object. Ditto for urllib2. No attempt is made to decode the data using the charset encoding specified in the header info()['Content-Type']. Is it fair to assume that, in Python 3K, urllibread() will return (Unicode) strings instead of bytes, automatically decoding according to the charset? Do you think we could expose this futuristic functionality in Python 2? I doubt we could change read() without breaking a lot of existing code that already does this decoding (e.g., http://zesty.ca/python/scrape.py), but perhaps a 'uread()' method could return a unicode object instead of a string. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1599329&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599325 ] htmlentitydefs.entitydefs assumes Latin-1 encoding
Bugs item #1599325, was opened at 2006-11-19 20:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599325&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: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: htmlentitydefs.entitydefs assumes Latin-1 encoding Initial Comment: The code in htmlentitydefs.py that sets entitydefs uses chr whenever the codepoint is <= 0xff. This should be <= 0x7f. As it currently stands, htmlentitydefs.entitydefs['nbsp'] == '\xa0'. But this is only "true" in the Latin-1 encoding. For example, in UTF8, the same character (u'\xa0') would be encoded '\xc2\xa0'. While I think it is reasonable for entitydefs to use the ASCII codec for characters encodable in that codec (<= 0x7f), I do not think it is reasonable to assume Latin-1 encoding. This issue affects sgmllib.SGMLParser, for example, when handle_entityref calls handle_data. The passed data can be '\xa0', which handle_data is forced to assume is Latin-1, when the source string might be encoded otherwise. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-19 20:59 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug. entitydefs is specified to contain Latin-1 byte strings in its documentation, and many applications rely on that. If you have different processing needs, you may want to use htmlentitydefs.name2codepoint instead, or derive yet another table automatically from it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599325&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 17:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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.5 Status: Open Resolution: None >Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-11-19 21:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599055 ] csv module does not handle '\x00'
Bugs item #1599055, was opened at 2006-11-18 19:47 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&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.5 Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Stephen Day (shday) Assigned to: Nobody/Anonymous (nobody) Summary: csv module does not handle '\x00' Initial Comment: The following from an interactive session failed instead of just returning the '\x00': >>> r = csv.reader(['a,line,with,a,null,\x00,byte']) >>> r.next() Traceback (most recent call last): File "", line 1, in -toplevel- r.next() Error: string with NUL bytes >>> -- >Comment By: Skip Montanaro (montanaro) Date: 2006-11-19 14:17 Message: Logged In: YES user_id=44345 Originator: NO If the device is transmitting the occasional spurious you might try wrapping your file object in a class which simply deletes any NUL bytes it encounters. -- Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 11:23 Message: Logged In: YES user_id=849994 Originator: NO The core of the csv module is coded in C, so null bytes are as always notoriously problematic when handling strings. (This is why there's a specific error message only for null bytes.) I think that the try-except is the sanest solution to this. -- Comment By: Stephen Day (shday) Date: 2006-11-19 11:08 Message: Logged In: YES user_id=948502 Originator: YES I've been using the csv module to parse data coming from a serial port of a lab instrument. Occasionally the instrument transmits a lone /x00 (maybe when the power cycles, I'm not sure). Anyhow, I'm now using a try-except statement to catch the error. I guess my answer to your question is that I think the module should handle whatever string you pass it. Is there a specific reason not to handle /x00? -- Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 09:09 Message: Logged In: YES user_id=849994 Originator: NO Why do you think a CSV reader should support null bytes? CSV is a text format, not a binary one. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: David Watson (baikie) Date: 2006-11-19 20:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-19 20:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
