classification
Title: shlex have problems with parsing unicode
Type: behavior Stage: needs patch
Components: Documentation Versions: Python 3.5
process
Status: open Resolution:
Dependencies: 10587 Superseder:
Assigned To: Nosy List: Santiago.Romero, belopolsky, benjamin.peterson, cgwalters, dexen, doughellmann, eric.araujo, ezio.melotti, fperez, haypo, loewis, mark.dickinson, mcepl, nwerneck, orsenthil, r.david.murray, rhettinger, wombat
Priority: normal Keywords: easy, patch

Created on 2007-09-17 15:53 by dexen, last changed 2014-06-30 01:07 by belopolsky.

Files
File name Uploaded Description Edit
shlex-unicode.patch cgwalters, 2007-12-22 18:22
issue1170.diff belopolsky, 2010-07-28 00:55 py3k patch
shlex_wt.py wombat, 2011-09-15 11:25 shlex augmented with "wordterminators" member
Messages (44)
msg55967 - (view) Author: dexen deVries (dexen) Date: 2007-09-17 16:17
Feeding unicode to shlex object created in POSIX compat mode causes 
UnicodeDecodeError to be raised. It appears that shlex object defines 
sting .wordchars, containing latin-1 (iso8859-1) encoded characters 
with charcodes >=128, which is used to check whether a character from 
input constitues a word character or not.
msg55968 - (view) Author: dexen deVries (dexen) Date: 2007-09-17 16:20
A quick paste to illustrate: the exception is raised only when unicode 
object is passed to shlex. Warning: the cStringIO module is unsuitable 
for use there, only the StringIO. cStringIO does not output unicode.


dexen!muraena!~$ python
Python 2.5.1 (r251:54863, May  4 2007, 16:52:23)
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from StringIO import StringIO
>>> import shlex
>>> lx = shlex.shlex( StringIO( unicode( "abc" ) ) )
>>> lx.get_token()
u'abc'
>>> lx = shlex.shlex( StringIO( unicode( "abc" ) ), None, True )
>>> lx.get_token()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/shlex.py", line 96, in get_token
    raw = self.read_token()
  File "/usr/lib/python2.5/shlex.py", line 150, in read_token
    elif nextchar in self.wordchars:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xdf in position 
63: ordinal not in range(128)
>>>
msg55969 - (view) Author: dexen deVries (dexen) Date: 2007-09-17 16:31
One remark to previous message:
the first time i created shlex object in non-POSIX mode (the default), 
in later it's in POSIX mode (due to the third parameter to shlex being 
True). The bug in question manifests only in POSIX mode.

BTW, that so-called POSIX mode would be more POSIX-ish, if instead of 
comparing characters with a fixed, short list, would use the ctype() 
function as found in standard C library. The functions takes current 
locale (setable in process) into account when deciding what is leter, 
whitespace, punctuation etc.
msg58964 - (view) Author: Colin Walters (cgwalters) Date: 2007-12-22 18:22
Patch to add Unicode support.

Note: this patch recodes shlex.py from iso-8859-1 to utf-8, so it has
mixed encodings.
msg77972 - (view) Author: Nicolau Leal Werneck (nwerneck) Date: 2008-12-17 16:40
Hello. I tried to patch my own shlex, and this doens't seem to be
working properly. When I try the patched module isntead of th eoriginal,
in my otherwise working program, I get the result ahead.

Is there any conversion steps missing?...


mymachine$ python interp.py < exemplo.prg
Traceback (most recent call last):
  File "interp.py", line 11, in <module>
    tok = ss.get_token()
  File "shlexutf.py", line 103, in get_token
    raw = self.read_token()
  File "shlexutf.py", line 139, in read_token
    nextcategory = unicodedata.category(nextchar)
TypeError: category() argument 1 must be unicode, not str
msg77973 - (view) Author: Nicolau Leal Werneck (nwerneck) Date: 2008-12-17 17:12
OK, it worked after I found out I didn't know how to open unicode
files... Sorry for the noise, and thanks for this patch! :]
msg91853 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-08-22 06:13
The patch needs tests before it can be applied. Additionally, I'm not
sure if having a "utf" option is helpful. Is there a reason not to have
unicode support by default?
msg106424 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-05-25 10:35
shlex in 3.x works with Unicode strings. Is it still time to try to fix this bug for 2.7?
msg109292 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-07-05 03:38
shlex may use unicode in py3k, but since the file still starts with a latin-1 coding cookie and the posix logic hasn't been changed, I suspect that it does not work correctly (ie: does not correctly identify word characters, per msg55969).

It's too late for 2.7 I think, but it seems there is work still to do in py3k.
msg110854 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-07-20 03:00
As discussed in msg110828 under issue9308, it is not clear whether logic identifying word characters in shlex is correct in presence of unicode.
msg110856 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-07-20 03:19
I believe the e-mail thread that culminated in r32284, "Implemented posix-mode parsing support in shlex.py", was "shellwords" from April 2003:
http://mail.python.org/pipermail/python-dev/2003-April/034670.html

I scanned through the messages, but could not find a reference to the standard that was implemented.
msg111594 - (view) Author: Fernando Perez (fperez) Date: 2010-07-26 04:35
Here is an illustration of the problem with a simple test case (the value of the posix flag doesn't make any difference):

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import shlex
>>> list(shlex.shlex('ab'))
['ab']
>>> list(shlex.shlex(u'ab', posix=True))
['a', '\x00', '\x00', '\x00', 'b', '\x00', '\x00', '\x00']
>>> list(shlex.shlex(u'ab', posix=False))
['a', '\x00', '\x00', '\x00', 'b', '\x00', '\x00', '\x00']
>>>
msg111709 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-07-27 18:24
Fernando,

Is this 2.7 only problem?  In 3.2


>>> list(shlex.shlex('ab'))
['ab']

and bytes are not supported.

>> list(shlex.shlex(b'ab'))
Traceback (most recent call last):
..
AttributeError: 'bytes' object has no attribute 'read'

It is debatable whether either is a bug.
msg111710 - (view) Author: Fernando Perez (fperez) Date: 2010-07-27 18:26
Yes, sorry that I failed to mention the example I gave applies only to 2.x, not to 3.x.
msg111716 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-07-27 18:52
On Tue, Jul 27, 2010 at 2:26 PM, Fernando Perez <report@bugs.python.org> wrote:
..
> Yes, sorry that I failed to mention the example I gave applies only to 2.x, not to 3.x.

Why do you expect shlex to work with unicode in 2.x?  The
documentation clearly says that the argument should be a string.
Supporting unicode is not an unreasonable RFE, but won't be considered
for 2.x anymore.

What's your take on accepting bytes in 3.x?
msg111717 - (view) Author: Fernando Perez (fperez) Date: 2010-07-27 19:02
On Tue, Jul 27, 2010 at 11:52, Alexander Belopolsky
<report@bugs.python.org> wrote:
> Why do you expect shlex to work with unicode in 2.x? =A0The
> documentation clearly says that the argument should be a string.
> Supporting unicode is not an unreasonable RFE, but won't be considered
> for 2.x anymore.

Well, I didn't make the original report, just provided a short,
illustrative example :)  It's easy enough to work around the issue for
2.x that I don't care too much about it, so I have no problem with 2.x
staying as it is.

> What's your take on accepting bytes in 3.x?

Mmh... Not too sure.  I'd think about it from the perspective of what
possible sources of input could produce raw bytes, that would be
reasonable use cases for shlex.  Is it common in 3.x to read a file in
bytes mode?  If so, then it might be a good reason to have shlex parse
bytes as well, since I can imagine reading inputs from files to be
parsed via shlex.

But take my opinion on 3.x with a big grain of salt, I have very
little experience with it as of yet.

Cheers,

f
msg111718 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-07-27 19:04
+1 on get shlex to work better with Unicode.  The core concepts of this module are general purpose and applicable to all kinds of text.
msg111719 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-07-27 19:07
On Tue, Jul 27, 2010 at 3:04 PM, Raymond Hettinger
<report@bugs.python.org> wrote:
>
> Raymond Hettinger <rhettinger@users.sourceforge.net> added the comment:
>
> +1 on get shlex to work better with Unicode.

In 2.7.x?  It more or less works in 3.x already.
msg111751 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-07-28 00:32
Alexander: the "more or less" is on the "less" side when dealing with non-ASCII letters, I think.  See my msg109292 and your own followups.
msg111755 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-07-28 00:55
David,

What do you think about attached patch?  Would that be a change in the "more" direction?
msg111756 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-07-28 01:02
I am adding MvL to nosy.

Martin,

I believe you are the ultimate authority on how to tokenize a unicode stream.
msg112911 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-08-04 22:21
I don't like my patch anymore because it breaks code that manipulates public wordchars attribute.  Users may want to set it to their own alphabet or append additional characters to the default list.  Maybe wordchars should always be "non-posix" wordchars and iswordchar posix mode test be c.isalnum() or c in self.wordchars?
msg122919 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-11-30 17:09
Adding #10587 because we need to figure out the exact meaning of str.isspace() etc. first.  It is possible that for proper operation shlex should consult unicodedata directly.
msg122929 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-11-30 19:00
The key requirement to consider for in POSIX compatible mode is, well, POSIX compatibility, which is defined in

http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_03

Now, POSIX declares that what <blank> is depends on LC_CTYPE (character class blank). I'd argue that if the objective is to behave exactly like the shell, it really should be doing that (i.e. work in a locale-aware manner).
msg140227 - (view) Author: Santiago Romero (Santiago.Romero) Date: 2011-07-13 07:51
I think I'm suffering the same problem in some small programs that use shlex:


>>> import shlex

>>> text = "python and shlex"
>>> shlex.split(text)
['python', 'and', 'shlex']

>>> text = u"python and shlex"
>>> shlex.split(text)
['p\x00\x00\x00y\x00\x00\x00t\x00\x00\x00h\x00\x00\x00o\x00\x00\x00n\x00\x00\x00', '\x00\x00\x00a\x00\x00\x00n\x00\x00\x00d\x00\x00\x00', '\x00\x00\x00s\x00\x00\x00h\x00\x00\x00l\x00\x00\x00e\x00\x00\x00x\x00\x00\x00']


 I'm currently using the following "basic" workaround (while assuming that my strings have only ascii chars):

>>> [ x.replace("\0", "") for x in shlex.split(text) ]
['python', 'and', 'shlex']

 It would be very nice if shlex could work with unicode strings ...

 Thanks.
msg140246 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-07-13 11:15
This isn't going to get fixed in 2.x (shlex doesn't support unicode in 2.x, and doing so would be a new feature).  In 3.x all strings are unicode, so the problem you are seeing doesn't exist.  This issue is about the broader problem of what counts as a word character when more than ASCII is involved.
msg140262 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-07-13 14:50
Would raising a TypeError if the given argument is a unicode be unacceptable for 2.7?  It would at least make things clear.
msg140516 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2011-07-17 05:04
TypeError should be okay. But I am still -0 on that. It would be good
to hear a strong argument from the user that how did he end up passing
unicode to shlex.split? It is for parsing command line args for
programs and personally have not seen those cases. Or did he want
unicode everywhere if we was using just using ascii characters.
msg140518 - (view) Author: Santiago Romero (Santiago.Romero) Date: 2011-07-17 07:51
> It would be good to hear a strong argument from
> the user that how did he end up passing
> unicode to shlex.split? It is for parsing command
> line args for programs and personally have not
> seen those cases.

 I'm from Spain: I personally write programs and python/bash scripts that accept unicode input arguments. And I'm currently writing a wxpython gui program (SSH/rdesktop launcher, in Spanish) that needs (and cannot) do shlex.split in of a given text string.

 Remember that English is NOT the most spoken language on the world. It's the THIRD most spoken language, after Chinese and Spanish, languages that need and use unicode support.
msg140529 - (view) Author: Doug Hellmann (doughellmann) * (Python committer) Date: 2011-07-17 15:59
Right. Any program that needs to parse command lines containing filenames or other arguments with unicode characters will encounter this problem.
msg140586 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-07-18 14:25
We all recognize that ASCII is very much limited and that the real way to work with strings is Unicode.  However, here our hands are tied by our development process: shlex in 2.x does not support Unicode, adding that support would be a new feature, and 2.7 is closed to new features.  If shlex was supposed to support Unicode, then this would be a bug that could be fixed in 2.7, but it’s not.  All we can do is improve the 2.7 doc to show how to work around that (splitting on bytes and then decoding each chunk, for example).
msg140590 - (view) Author: Doug Hellmann (doughellmann) * (Python committer) Date: 2011-07-18 14:36
Is unicode supported by shlex in 3.x already? It's curious that unicode support is considered a new feature, rather than a bug. I understand wanting to allocate development resources carefully, though. If someone were to prepare a patch, would it even have a chance of being accepted in 2.7?
msg140591 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-07-18 14:43
See http://bugs.python.org/issue1170#msg106424 and following.
msg140592 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-07-18 14:51
It’s not about allocating resources, it’s about following process.  The first part is that we don’t add new features to stable releases, the second item is that this is not considered a bug fix: The code pre-dates Unicode, was not updated to support it, and the docs say “The shlex module currently does not support Unicode input”.
msg144074 - (view) Author: Andrew Jewett (wombat) Date: 2011-09-15 11:25
Proposed solution and patch to follow.  Please let me know if I am posting it in the wrong place.

The main problem with shlex is that the shlex interface is inadequate to handle unicode.  Specifically it is no longer feasible to provide a list of every possible character that the user could want to appear within a token.  Suppose the user wants the ability to parse words in simplified Chinese.  If I understand correctly, then currently, they would have to set "self.wordchars" to a string (or some other container) of 6000 (unicode) characters, and this enormous string would need to be searched each time a new character is read.  This was a problem with shlex from the beginning, but it became more acute when support for unicode was added.  Generally, in some cases, it is much more convenient instead to specify a short list of characters you -don't- want to appear in a word (word delimiters), than to list all the characters you do.

An obvious (although perhaps not optimal) solution is to add an additional data member to shlex, consisting of the characters which terminate the reading of a token.  (In other words, the set-inverse of wordchars.)  In the attached example code, I call it "self.wordterminators".  To remain backwards-compatible with shlex, self.wordterminators is empty by default.  But if not-empty, self.wordterminators overrides self.wordchars.

I've been distributing a customized version of shlex with my own software which implements this modest change (shlex_wt).  (See attachment.)  It is otherwise identical to the version of shlex.py that ships with python 3.2.2.  (It has been further modified only slightly to be compatible with both python 2.7 and python 3.)  It's not beautiful code, but it seems to be a successful kluge for this particular issue.  I don't know if it makes a worthy patch, but perhaps somebody out there finds it useful.  To make it easy to spot the changes, each of the lines I changed ends in a comment "#WORDTERMINATORS".  (There are only 15 of these lines.)
-Andrew Jewett
msg144076 - (view) Author: Andrew Jewett (wombat) Date: 2011-09-15 11:38
Not to get side-tracked, but on a related note, it would be nice if there was a python module which defined sets of unicode characters corresponding to different categories (similar to the categories listed here: http://www.fileformat.info/info/unicode/category/index.htm)
That way, for example, if the user wants to categorically ignore ALL mathematical symbols or punctuation marks, they could assign: 

self.wordterminators = unicode_math + unicode_punctuation.
(The + means set union.)

If somebody tried to specify all of them manually, this would be painful.  There are hundreds of punctuation symbols in unicode, for example.  (I suppose most of the time, one does not need to be so thorough.  This feature not really necessary for getting shlex to work.  But I think this would be a easy feature to add.)
msg144077 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-09-15 12:00
That can be done programmatically using the unicodedata module.  The regex module (that will hopefully be include in 3.3) is also able to match characters that belongs to specific categories.
msg144080 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-09-15 14:53
Andrew: Thanks for your contribution, but your patch cannot go into 2.7, as we don’t add new features in stable versions (re-read the whole thread if you need more info).  This report is still open because we need a doc patch to explain how to work around that.
msg144097 - (view) Author: Andrew Jewett (wombat) Date: 2011-09-15 19:52
> That can be done programmatically using the unicodedata module.  
> The regex module (that will hopefully be include in 3.3) is 
> also able to match characters that belongs to specific categories.

Ezio:  Thanks.  (New to me, actually)  Is this what you mean?:
http://www.regular-expressions.info/unicode.html
For the purposes of patching shlex, should we use regex instead of sets of characters (or strings) to test for membership in shlex.wordterminators?  (Or should we create a different class member?  Unfortunately, I guess shlex.wordchars has to be left as some kind of container object to maintain backwards compatibility.)
Something like that would definitely solve the problem nicely.

> Andrew: Thanks for your contribution, but your patch cannot 
> go into 2.7, as we don’t add new features in stable versions

Eric: That's fine.  I just posted here because this page currently gets the top hit when searching for "shlex unicode".  If you think it's appropriate to repost my message for python version 3.4, let me know.  The issue with shlex.wordchars that I raised is valid for any version of python.  I'm not sure my solution is optimal.  (I like the regex idea).
msg144193 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-09-17 15:23
Andrew: Ezio means http://docs.python.org/2.7/library/unicodedata

> For the purposes of patching shlex
Sorry, but we are not talking about patching shlex.

> I just posted here because this page currently gets the top hit
> when searching for "shlex unicode".
It’s okay.  A recipe on ActiveState and a “shlexu” module on PyPI would also be good things to have.

> If you think it's appropriate to repost my message for python version 3.4,
> let me know.
shlex supports Unicode in 3.x.  If there is a bug, can you please open another bug report?  This one is already too long, and I’d prefer to keep it focused on the need for a documentation patch.
msg144201 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-09-17 16:07
Ezio, I don't see any indication in this ticket that this bug was actually *fixed* in 3.x.  Unicode doesn't cause immediate errors in 3.x, but it isn't recognized as wordchars, etc.  Am I missing something?
msg144202 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-09-17 16:12
I haven't looked at the shlex code (yet), my comment was just about the idea of adding constants with chars that belong to different Unicode categories.
msg146219 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-10-23 05:36
$ ./python 
Python 2.7.2+ (2.7:27ae7d4e1983+, Oct 23 2011, 00:09:06) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import shlex
>>> shlex.split(u'Hello, World!')
['Hello,', 'World!']

This bug was fixed indirectly by a StringIO fix in 27ae7d4e1983, for #1548891.  BTW, this report was a duplicate of #6988, closed a year ago.

Python 2.7.3 will finally support unicode in shlex, so the doc change requested in this report is outdated.  However, I still want to do something for this.  I’ve noticed that shlex.split’s argument can be a file-like object, and I wonder if passing a StringIO.StringIO(my_unicode_string) wouldn’t work.  If such a short recipe works, I’m all for including it in the 2.7 docs for users of older versions.  If a longer recipe is needed, then ActiveState’s Python Cookbook would be more appropriate, and I’ll add a link to the docs.  If it’s very long and requires a PyPI project, then I’m willing to link to that.
msg146220 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-10-23 05:42
The second message in this page reports that StringIO.StringIO works, but when I pass a unicode string with non-ASCII chars there’s a method call that fails because of implicit unicode-to-str conversion:

Traceback (most recent call last):
  File "/usr/lib/python2.7/shlex.py", line 150, in read_token
    elif nextchar in self.wordchars:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xdf in position 63: ordinal not in range(128)

I’ll try to create a Shlex instance, replace self.wordchars with a decoded version and try again.
History
Date User Action Args
2014-06-30 01:07:10belopolskysetassignee: belopolsky ->
versions: + Python 3.5
2011-10-23 05:42:50eric.araujosetmessages: + msg146220
2011-10-23 05:36:14eric.araujosetmessages: + msg146219
2011-09-17 16:12:01ezio.melottisetmessages: + msg144202
2011-09-17 16:07:17r.david.murraysetmessages: + msg144201
2011-09-17 15:23:45eric.araujosetmessages: + msg144193
2011-09-15 19:52:00wombatsetmessages: + msg144097
2011-09-15 14:53:48eric.araujosetmessages: + msg144080
2011-09-15 12:00:21ezio.melottisetmessages: + msg144077
2011-09-15 11:38:42wombatsetmessages: + msg144076
2011-09-15 11:25:13wombatsetfiles: + shlex_wt.py
versions: - Python 2.7
nosy: + wombat

messages: + msg144074
2011-09-02 17:40:14eric.araujosetkeywords: + easy
stage: test needed -> needs patch
components: + Documentation, - Library (Lib), Unicode
versions: + Python 2.7, - Python 3.1, Python 3.2
2011-07-18 14:51:59eric.araujosetmessages: + msg140592
2011-07-18 14:43:38eric.araujosetmessages: + msg140591
2011-07-18 14:36:32doughellmannsetmessages: + msg140590
2011-07-18 14:25:42eric.araujosetmessages: + msg140586
2011-07-17 15:59:36doughellmannsetmessages: + msg140529
2011-07-17 08:33:42cvrebertsetnosy: - cvrebert
2011-07-17 07:51:39Santiago.Romerosetmessages: + msg140518
2011-07-17 05:04:13orsenthilsetnosy: + orsenthil
messages: + msg140516
2011-07-13 14:50:35eric.araujosetmessages: + msg140262
2011-07-13 11:15:42r.david.murraysetmessages: + msg140246
2011-07-13 07:56:10ezio.melottisetnosy: + ezio.melotti
2011-07-13 07:51:47Santiago.Romerosetnosy: + Santiago.Romero
messages: + msg140227
2011-01-14 20:16:45doughellmannsetnosy: + doughellmann
2010-11-30 19:00:30loewissetmessages: + msg122929
2010-11-30 17:09:05belopolskysetdependencies: + Document the meaning of str methods
messages: + msg122919
2010-08-04 22:21:48belopolskysetmessages: + msg112911
2010-07-28 01:02:23belopolskysetnosy: + loewis
messages: + msg111756
2010-07-28 00:55:47belopolskysetfiles: + issue1170.diff

messages: + msg111755
2010-07-28 00:32:32r.david.murraysetmessages: + msg111751
2010-07-27 19:07:13belopolskysetmessages: + msg111719
2010-07-27 19:04:18rhettingersetnosy: + rhettinger
messages: + msg111718
2010-07-27 19:02:37fperezsetmessages: + msg111717
2010-07-27 18:52:43belopolskysetmessages: + msg111716
2010-07-27 18:26:51fperezsetmessages: + msg111710
2010-07-27 18:24:08belopolskysetmessages: + msg111709
2010-07-26 04:35:46fperezsetnosy: + fperez
messages: + msg111594
2010-07-20 03:19:34belopolskysetmessages: + msg110856
2010-07-20 03:00:40belopolskysetnosy: mark.dickinson, belopolsky, haypo, dexen, benjamin.peterson, cgwalters, mcepl, eric.araujo, r.david.murray, nwerneck, cvrebert
2010-07-20 03:00:15belopolskysetnosy: + belopolsky
messages: + msg110854

assignee: belopolsky
keywords: + patch
2010-07-05 03:42:35hayposetnosy: + haypo
2010-07-05 03:38:59r.david.murraysetversions: + Python 3.1, Python 3.2, - Python 2.5
nosy: + r.david.murray, mark.dickinson

messages: + msg109292

stage: test needed
2010-05-25 10:35:48eric.araujosetmessages: + msg106424
2010-02-16 04:20:04eric.araujosetnosy: + eric.araujo
2009-08-22 06:13:07benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg91853
2009-08-22 00:08:24cvrebertsetnosy: + cvrebert
2008-12-17 17:12:20nwernecksetmessages: + msg77973
2008-12-17 16:40:57nwernecksetnosy: + nwerneck
messages: + msg77972
2008-02-27 11:10:15mceplsetnosy: + mcepl
2007-12-22 18:22:13cgwalterssetfiles: + shlex-unicode.patch
nosy: + cgwalters
messages: + msg58964
2007-09-18 15:15:02jafosetpriority: normal
2007-09-17 16:31:21dexensetmessages: + msg55969
2007-09-17 16:20:38dexensetmessages: + msg55968
2007-09-17 16:17:13dexensetnosy: + dexen
messages: + msg55967
2007-09-17 15:53:56dexencreate