                                                                                                                                                                                                                                                                
Received-SPF: pass (google.com: domain of 3zld3UA4OAOMHTZHMIG-UdYMTSLTTLQJHTIJ....@codesite.bounces.google.com designates 209.85.212.75 as permitted sender) client-ip=209.85.212.75;
MIME-Version: 1.0
Reply-To: codesite-nore...@google.com
References: <6-12560507179679177234-16190220908923248440-couchdb-python=googlecode.com@googlecode.com>
 <0-12560507179679177234-16190220908923248440-couchdb-python=googlecode.com@googlecode.com>
In-Reply-To: <6-12560507179679177234-16190220908923248440-couchdb-python=googlecode.com@googlecode.com>
Message-ID: <7-12560507179679177234-16190220908923248440-couchdb-python=googlecode.com@googlecode.com>
Date: Thu, 11 Oct 2012 23:35:42 +0000
Subject: Re: Issue 209 in couchdb-python: couchdb-python doesn't support locales
From: couchdb-pyt...@googlecode.com
To: couchdb-python@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes


Comment #7 on issue 209 by kxepal: couchdb-python doesn't support locales
http://code.google.com/p/couchdb-python/issues/detail?id=209

unittest.skip will bring unittest2 dependency which couldn't help with  
prevent problem in future. Also it's impossible to check locale because it  
could not be available - as for me I have ('ru_RU', 'cp1251') while 'fr_FR'  
is missed for me.

There are two solutions:
1. Make tests for Windows only against ANSI encoding since it brings a  
problem, while Linux long ago has *.UTF-8 system encoding by default.

2. Since this bug dependent on OS environment AND processed Date value  
follows well known rules[1][2] it will be right decision to use right  
ways[3][4][4] to parse such value. Tests are redundant in this case since  
there is actually nothing to test - Python functions are well tested by his  
community and bug occurs not because of couchdb-python logic code.

As for me, second variant is better because:
- it follows RFC like parsed value does;
- it is not locale dependent;
- I don't see any portable and stable ways to test locale specific things  
without providing some dependency overhead (babel and mock may help there);

Patch attached. Thoughts?

[1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18
[2]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1
[3]: http://docs.python.org/library/email.util.html#email.utils.parsedate
[4]:  
http://stackoverflow.com/questions/1471987/how-do-i-parse-an-http-date-string-in-python
[5]:  
http://stackoverflow.com/questions/225086/rfc-1123-date-representation-in-python

Attachments:
	couchdb-python-209-r1.patch  882 bytes