[issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English
Dmitry Jemerov added the comment: I personally don't, but the function is used by Sphinx, which is what I was trying to get to work when I ran into this problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English
New submission from Dmitry Jemerov: On Mac OS X 10.8 with the default language set to English (System Preferences | Language and Text), the default terminal application sets the LC_CTYPE environment variable to UTF-8. If you run Python from the terminal and try to use locale.getdefaultlocate(), you get the following error: python Python 2.7.2 (default, Oct 11 2012, 20:14:37) [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin Type help, copyright, credits or license for more information. import locale locale.getdefaultlocale() Traceback (most recent call last): File stdin, line 1, in module File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py, line 496, in getdefaultlocale return _parse_localename(localename) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py, line 428, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: UTF-8 (The stacktrace is from Python 2.7 but Python 3.3 suffers from the same problem.) There are numerous workarounds for this problem (turning off the Set locale environment variables on startup option in the terminal settings, or adding export LC_CTYPE=en_US.UTF8 to .bash_profile, selecting a language other than English in the Language Text settings), but these require additional configuration from the user's side. I think that the more useful behavior is for Python to handle this behavior of the system and not crash, even though it doesn't strictly comply to the POSIX standard. The attached patch (against current Python 3.4 master branch) is one possible fix. -- components: Library (Lib) files: getdefaultlocale.patch keywords: patch messages: 192422 nosy: Dmitry.Jemerov priority: normal severity: normal status: open title: locale.getdefaultlocale() fails on Mac OS X with default language set to English versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file30807/getdefaultlocale.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English
Dmitry Jemerov added the comment: Judging from the results of Googling for the error message, I'm far from the only one seeing this problem. What exactly would be the benefit of adding the code to check for the platform? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English
Dmitry Jemerov added the comment: Why exactly does this matter? UTF-8 not being a valid LC_CTYPE value simply means that no one running Linux will ever have LC_CTYPE set to UTF-8, and the branch will never be hit. OTOH, adding the check will make the code harder to test and simply larger (no code is always better than any non-zero amount of code). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English
Dmitry Jemerov added the comment: A related issue (with a patch that touches the same locale parsing code) is http://bugs.python.org/issue5815 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5815] locale.getdefaultlocale() missing corner case
Dmitry Jemerov added the comment: A related issue (a case which isn't taken into account by Serhiy's patch) is http://bugs.python.org/issue18378 -- nosy: +Dmitry.Jemerov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5815 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17143] trace.py uses _warn without importing it
New submission from Dmitry Jemerov:
trace.py in Python 3.3 standard library uses the _warn function without
importing it. As a result, an attempt to use a now-deprecated function fails
with a NameError:
python3
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 01:25:11)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type help, copyright, credits or license for more information.
import trace
trace.modname('')
Traceback (most recent call last):
File stdin, line 1, in module
File
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/trace.py,
line 827, in modname
_warn(The trace.modname() function is deprecated,
NameError: global name '_warn' is not defined
--
components: Library (Lib)
messages: 181531
nosy: Dmitry.Jemerov
priority: normal
severity: normal
status: open
title: trace.py uses _warn without importing it
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17143
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17143] trace.py uses _warn without importing it
Dmitry Jemerov added the comment: Workaround: import warnings; trace._warn = warnings.warn after importing trace -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17143 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum recursion depth exceeded in cmp
Dmitry Jemerov intelliy...@gmail.com added the comment: I've also run into this problem after upgrading to Python 2.6.6. My code, which uses the same HTTPBasicAuthHandler instance for many requests to the same server, worked correctly with Python 2.6.2 and broke with 2.6.6. It would be great if zenyatta's patch to fix the regression was included in 2.6.7. Also, unfortunately NEWS.txt doesn't mention this change at all. -- nosy: +Dmitry.Jemerov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8797 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8123] TypeError in urllib when trying to use HTTP authentication
Dmitry Jemerov intelliy...@gmail.com added the comment: Patch (with unittest) attached. -- keywords: +patch Added file: http://bugs.python.org/file18139/8123.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8123 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry
Dmitry Jemerov intelliy...@gmail.com added the comment: Patch (suggested fix and unittest) attached. -- keywords: +patch Added file: http://bugs.python.org/file18143/9291.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9291 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry
Dmitry Jemerov intelliy...@gmail.com added the comment: And by the way I've verified that the problem doesn't happen in py3k trunk. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9291 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9360] nntplib cleanup
New submission from Dmitry Jemerov intelliy...@gmail.com: The patch performs an extensive cleanup of nntplib: - Change API methods to return strings instead of bytes. This breaks API compatibility, but given that the parameters need to be passed as strings and many of the returned values would need to be passed to other API methods, I consider the current API to be broken. I've discussed this with Brett at the EuroPython sprint, and he agrees. - Add tests. - Add pending deprecation warnings for xgtitle() and xpath() methods, which are not useful in modern environments. - Use named tuples for returned values where appopriate. - Modernize the implementation a little bit. - Clean up the docstrings. -- components: Library (Lib) files: nntplib_cleanup.patch keywords: patch messages: 111364 nosy: Dmitry.Jemerov priority: normal severity: normal status: open title: nntplib cleanup versions: Python 3.2 Added file: http://bugs.python.org/file18159/nntplib_cleanup.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9360] nntplib cleanup
Dmitry Jemerov intelliy...@gmail.com added the comment: This is an issue only for the actual article content, right? I'll be happy to extend the API to allow getting the original bytes of the article content, while keeping the rest of API (like group names) string-based. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry
Dmitry Jemerov intelliy...@gmail.com added the comment: The problem doesn't happen on Python 3.1.2 because it doesn't have the code in mimetypes that accesses the Windows registry. Haven't tried the 3.2 alphas yet. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9291 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry
New submission from Dmitry Jemerov intelliy...@gmail.com: On Windows, mimetypes initialization reads the list of MIME types from the Windows registry. It assumes that all characters are Latin-1 encoded, and fails when it's not the case, with the following exception: Traceback (most recent call last): File mttest.py, line 3, in module mimetypes.init() File c:\Python27\lib\mimetypes.py, line 355, in init db.read_windows_registry() File c:\Python27\lib\mimetypes.py, line 260, in read_windows_registry for ctype in enum_types(mimedb): File c:\Python27\lib\mimetypes.py, line 250, in enum_types ctype = ctype.encode(default_encoding) # omit in 3.x! UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128) This can be reproduced, for example, on a Russian Windows XP installation which has QuickTime installed (QuickTime creates the non-Latin entries in the registry). The following line causes the exception to happen: import mimetypes; mimetypes.init() -- components: Library (Lib), Windows messages: 110637 nosy: Dmitry.Jemerov priority: normal severity: normal status: open title: mimetypes initialization fails on Windows because of non-Latin characters in registry versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9291 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8123] TypeError in urllib when trying to use HTTP authentication
Dmitry Jemerov intelliy...@gmail.com added the comment: from urllib.request import * opener = FancyURLopener() opener.retrieve(http://username:passw...@google.com/index.html;, index.html) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8123 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8123] TypeError in urllib when trying to use HTTP authentication
New submission from Dmitry Jemerov intelliy...@gmail.com: I'm trying to download a file from a site using HTTP authentication. I'm subclassing FancyURLOpener, returning my credentials from the prompt_user_passwd() method, and using opener.retrieve() to download the file. I get the following error: File C:/JetBrains/IDEA/build/eap/downandup.py, line 36, in download opener.retrieve(url, os.path.join(target_path, name)) File C:\Python31\lib\urllib\request.py, line 1467, in retrieve fp = self.open(url, data) File C:\Python31\lib\urllib\request.py, line 1435, in open return getattr(self, name)(url) File C:\Python31\lib\urllib\request.py, line 1609, in open_http return self._open_generic_http(http.client.HTTPConnection, url, data) File C:\Python31\lib\urllib\request.py, line 1605, in _open_generic_http response.status, response.reason, response.msg, data) File C:\Python31\lib\urllib\request.py, line 1621, in http_error result = method(url, fp, errcode, errmsg, headers) File C:\Python31\lib\urllib\request.py, line 1859, in http_error_401 return getattr(self,name)(url, realm) File C:\Python31\lib\urllib\request.py, line 1931, in retry_http_basic_auth return self.open(newurl) File C:\Python31\lib\urllib\request.py, line 1435, in open return getattr(self, name)(url) File C:\Python31\lib\urllib\request.py, line 1609, in open_http return self._open_generic_http(http.client.HTTPConnection, url, data) File C:\Python31\lib\urllib\request.py, line 1571, in _open_generic_http auth = base64.b64encode(user_passwd).strip() File C:\Python31\lib\base64.py, line 56, in b64encode raise TypeError(expected bytes, not %s % s.__class__.__name__) TypeError: expected bytes, not str The problem happens because _open_generic_http extracts the user password from the string URL, and passes the string to the b64encode method, which only accepts bytes and not strings. The problem happens with Python 3.1.1 for me, but as far as I can see it's still not fixed in the py3k branch as of now. -- components: Library (Lib) messages: 100938 nosy: Dmitry.Jemerov severity: normal status: open title: TypeError in urllib when trying to use HTTP authentication versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8123 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
