> That shouldn't be sys.getdefaultencoding(), but > locale.getpreferredencoding(). Agreed. > However, I agree with Barry that the current behaviour should not > be changed. People may already rely on gettext returning byte > strings as-is. Barry also said: """ Any sane app is going to use the class-based API an the ugettext() method anyway, so maybe it does make sense to simply be API compatible with GNU gettext for the old-style interface. """ > >- Change the default codeset used by gettext.py in functions > > returning an encoded string to match the system encoding. > > No. Explicit is better that implicit; users desiring that > feature should write [...] You belive that returning a string in some unpredictable encoding used by the translator is explicit? I have to disagree. We have something named 'gettext' with a different behavior than the original project, in a way that breaks the concepts used to decide the behavior of the classical implementation. > I advocate never to use gettext.install, in which case you > have a custom _ implementation *anyway*, which would then [...] "You shouldn't be using it" is not a point I'm taking into account. > >- Introduce bind_textdomain_codeset() in locale. > >- Introduce bind_textdomain_codeset() in gettext.py implementing > > an equivalent functionality. > > That is ok. You could also try to provide that feature > consistently, e.g. inside .install. Agreed. -- Gustavo Niemeyer http://niemeyer.net
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4