[issue6988] shlex.split() converts unicode input to UCS-4 output with varying byte order
New submission from Bill Fenner fen...@gmail.com: In python 2.5, shlex handled unicode input fine: Python 2.5.1 (r251:54863, Jun 15 2008, 18:24:51) [GCC 4.3.0 20080428 (Red Hat 4.3.0-8)] on linux2 Type help, copyright, credits or license for more information. import shlex shlex.split( u'Hello, World!' ) ['Hello,', 'World!'] In python 2.6, shlex turns unicode input into UCS-4 output, thus utterly confusing execl: Python 2.6 (r26:66714, Jun 8 2009, 16:07:29) [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 Type help, copyright, credits or license for more information. import shlex shlex.split( u'Hello, World' ) ['H\x00\x00\x00e\x00\x00\x00l\x00\x00\x00l\x00\x00\x00o\x00\x00\x00,\x00\x00\x00', '\x00\x00\x00W\x00\x00\x00o\x00\x00\x00r\x00\x00\x00l\x00\x00\x00d\x00\x00\x00'] Even weirder, the two return strings have different byte order (see 'H\x00\x00\x00' vs. '\x00\x00\x00W'!) -- components: Library (Lib) messages: 93074 nosy: fenner severity: normal status: open title: shlex.split() converts unicode input to UCS-4 output with varying byte order versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6988] shlex.split() converts unicode input to UCS-4 output with varying byte order
Bill Fenner fen...@gmail.com added the comment: A colleague pointed out that the bad behavior was introduced in 2.5.2: Python 2.5.2 (r252:60911, Sep 30 2008, 15:42:03) [GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2 Type help, copyright, credits or license for more information. import shlex shlex.split( uHello, World! ) ['H\x00\x00\x00e\x00\x00\x00l\x00\x00\x00l\x00\x00\x00o\x00\x00\x00,\x00\x00\x00', '\x00\x00\x00W\x00\x00\x00o\x00\x00\x00r\x00\x00\x00l\x00\x00\x00d\x00\x00\x00!\x00\x00\x00'] -- versions: +Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6988] shlex.split() converts unicode input to UCS-4 output with varying byte order
Bill Fenner fen...@gmail.com added the comment: so, just to be clear, your position is that the output of shlex.split( u'Hello, World!' ) is *supposed* to be ['H\x00\x00\x00e\x00\x00\x00l\x00\x00\x00l\x00\x00\x00o\x00\x00\x00,\x00\x00\x00', '\x00\x00\x00W\x00\x00\x00o\x00\x00\x00r\x00\x00\x00l\x00\x00\x00d\x00\x00\x00']? -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6988] shlex.split() converts unicode input to UCS-4 output
Bill Fenner fen...@gmail.com added the comment: Sorry, I didn't read the web documentation, only the module documentation, which doesn't mention Unicode. I'd agree that since it's a documented behavior, this bug can become: - an RFE for shlex to handle Unicode - meanwhile, if there will be any releases before that happens, an RFE for the module documentation to mention the lack of Unicode support -- title: shlex.split() converts unicode input to UCS-4 output withvarying byte order - shlex.split() converts unicode input to UCS-4 output ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1339] smtplib starttls() should ehlo() if it needs to
Bill Fenner added the comment: jamesh, I attached the patch for that to the already-existing bug, filed in 2003: http://bugs.python.org/issue829951 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1339 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1511] csv input converts \r\n to \n but csv output does not when a field has internal line breaks
New submission from Bill Fenner: When a field has internal line breaks, e.g., foo,bar baz biff,boo that is actually 3 lines, but one csv-file row. csv.reader() converts this to ['foo', 'bar\nbaz\nbiff', 'boo']. This is a reasonable behavior. Unfortunately, csv.writer() does not use the dialect's lineterminator setting for values with such internal linebreaks. This means that the resulting file will have a mix of line-termination styles: foo,bar\n baz\n biff,boo\r\n If the reading csv implementation is strict about its line termination, these line breaks will not be read properly. -- messages: 57902 nosy: fenner severity: normal status: open title: csv input converts \r\n to \n but csv output does not when a field has internal line breaks type: behavior versions: Python 2.4 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1511 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1511] csv input converts \r\n to \n but csv output does not when a field has internal line breaks
Changes by Bill Fenner: -- components: +Library (Lib) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1511 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1511] csv input converts \r\n to \n but csv output does not when a field has internal line breaks
Bill Fenner added the comment: I realized that my description was not crystal clear - the file being read has \r\n line terminators - in the format that I used later, the input file is foo,bar\r\n baz\r\n biff,boo\r\n __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1511 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue829951] Fixes smtplib starttls HELO errors
Bill Fenner added the comment: I've attached an updated diff, against the 2.4.3 smtplib.py, which forgets all of the relevant pieces of information. The line numbers are offset from the standard lib because the original file has my patch for issue 1339 applied, but there is no overlap so this patch should apply cleanly. Added file: http://bugs.python.org/file8666/smtplib-startls-discard-knowledge.diff Tracker [EMAIL PROTECTED] http://bugs.python.org/issue829951 smtplib-startls-discard-knowledge.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1339] smtplib starttls() should ehlo() if it needs to
New submission from Bill Fenner: smtplib's complex methods, login and sendmail, try to EHLO or HELO if it hasn't been done yet. login also checks to see if the EHLO response included the ability to do authorization. starttls seems to me to be similar in nature: why should it not try to EHLO or HELO, and check that self.has_extn(starttls)? -- components: Library (Lib) messages: 56829 nosy: fenner severity: normal status: open title: smtplib starttls() should ehlo() if it needs to type: rfe versions: Python 2.4 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1339 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue829951] Fixes smtplib starttls HELO errors
Bill Fenner added the comment: Yes, the state that should be reset includes helo_resp, ehlo_resp, esmtp_features, and does_esmtp. The workaround commonly proposed is to always call ehlo() after starttls() . While this works (most of the time?), it seems arbitrary to require an explicit ehlo() call in this case but not other cases. -- nosy: +fenner versions: +Python 2.4 Tracker [EMAIL PROTECTED] http://bugs.python.org/issue829951 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
