I'm getting this error since I upgraded to Zope 2.6 (from 2.3). Formerly, everything was going ok. What can be the problem??: Traceback (innermost last): Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Shared.DC.Scripts.Bindings, line 252, in __call__ Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec Module Products.PythonScripts.PythonScript, line 315, in _exec Module Script (Python), line 32, in marcaResultados - <PythonScript at /jmruiz/1X2/marcaResultados> - Line 32 UnicodeError: ASCII encoding error: ordinal not in range(128) _______________________________________________________________ Yahoo! Messenger Nueva versión: Webcam, voz, y mucho más ¡Gratis! Descárgalo ya desde http://messenger.yahoo.es
Juan Manuel Ruiz Garcia wrote:
Module Script (Python), line 32, in marcaResultados - <PythonScript at /jmruiz/1X2/marcaResultados> - Line 32 UnicodeError: ASCII encoding error: ordinal not in range(128)
Go look at line 32 of your marcaResultados script. You've probabyl got a literal string that needs to be unicode, like this: u'a string' cheers, Chris
Juan Manuel Ruiz Garcia writes:
I'm getting this error since I upgraded to Zope 2.6 (from 2.3). Formerly, everything was going ok. What can be the problem??:
Traceback (innermost last): ... Module Script (Python), line 32, in marcaResultados - <PythonScript at /jmruiz/1X2/marcaResultados> - Line 32 UnicodeError: ASCII encoding error: ordinal not in range(128) Somehow you get a unicode string and implicitly convert it into a normal string.
Python uses the "defaultencoding" for such conversions. If it is not specified in "sitecustomize.py", Python uses ASCII encoding. Thus, when you unicode string contains a non-ASCII character, you get the above exception. As you live in a Western country, you probably should set "sys.setdefaultencoding('iso-8859-1')" in your "sitecustomize.py". Dieter
On Thursday 31 October 2002 8:27 pm, Dieter Maurer wrote:
Python uses the "defaultencoding" for such conversions. If it is not specified in "sitecustomize.py", Python uses ASCII encoding. Thus, when you unicode string contains a non-ASCII character, you get the above exception.
As you live in a Western country, you probably should set "sys.setdefaultencoding('iso-8859-1')" in your "sitecustomize.py".
I dont think that is good advice. sys.setdefaultencoding is left over from the early days of python unicode development. It is likely to disappear in future versions of python. Alot of code legitimately assumes the default encoding is ascii, and may break if you change it.
Toby Dickenson writes:
... ... setdefaultencoding ... It is likely to disappear in fu ture versions of python. Alot of code legitimately assumes the default encodin g is ascii, and may break if you change it. This would be a bad turn on Python's part.
For the time being, the encoding used in may files, the printer, the operating system is "latin-1". Python should provide a convenient way to transparently convert between Unicode and my default environment, when I tell is so. Hopefully, we can prevent this turn into Americanims! Dieter
On Fri, Nov 01, 2002 at 07:35:31PM +0000, Toby Dickenson wrote:
On Friday 01 November 2002 5:18 pm, Dieter Maurer wrote:
Python should provide a convenient way to
transparently
convert between Unicode and my default environment, when I tell is so. ^^^^^^^^^^^^^^^^^^
explicit is better than implicit.
seems to me Toby wants explicit. -- Paul Winkler http://www.slinkp.com "Welcome to Muppet Labs, where the future is made - today!"
Toby Dickenson writes:
On Friday 01 November 2002 5:18 pm, Dieter Maurer wrote:
Python should provide a convenient way to
transparently
convert between Unicode and my default environment, when I tell is so.
explicit is better than implicit. It is explicit:
I tell Python explicitly that my environment is a lation-1 environment. This is similar to the "locale". I specify at a central point that I live in a "de_DE" "locale". It would be hell when I had to do that at each place, the "locale" setting might be be relevant. Dieter
Hi Dieter, Toby, Juan, --On Freitag, 1. November 2002 18:18 +0100 Dieter Maurer <dieter@handshake.de> wrote:
Toby Dickenson writes:
... ... setdefaultencoding ... It is likely to disappear in fu ture versions of python. Alot of code legitimately assumes the default encodin > g is ascii, and may break if you change it. This would be a bad turn on Python's part.
For the time being, the encoding used in may files, the printer, the operating system is "latin-1".
Python should provide a convenient way to transparently convert between Unicode and my default environment, when I tell is so.
Hopefully, we can prevent this turn into Americanims!
I dont know why this code is in site.py: encoding = "ascii" # Default value set by _PyUnicode_Init() if 0: # Enable to support locale aware default string encodings. import locale loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1] if 0: # Enable to switch off string to Unicode coercion and implicit # Unicode to string conversion. encoding = "undefined" if encoding != "ascii": sys.setdefaultencoding(encoding) This implies modification of the installed code to change default behavior. I would consider this as bad. Why isnt a locales sensitive version the default? However, there is lukyly another way to do it: let us provide a sitecustomize.py module for zope. If its in the path, it has access to sys.setdefaultencoding I use it that way (I set utf-8) and Zope unicodes and strings quite good. Also without the nasty cStringIO -> StringIO patch in ZPT and friends. However I had to change some things in ZPublisher/HTTPResponse.py to always get correct charset in the header. Also there are some products who use latin-1 per default. This is a bug to. Regards Tino
On Saturday 02 November 2002 1:48 am, Tino Wildenhain wrote:
if encoding != "ascii": sys.setdefaultencoding(encoding)
This implies modification of the installed code to change default behavior. I would consider this as bad. Why isnt a locales sensitive version the default?
That would make it difficult to write reliable portable Python code. It is a good thing that Python has predictable behaviour for things like (string+integer), a local-sensitive or user-sensitive default encoding would make (plain string+unicode string) unpredictable. Note that nothing else in Python depends on locales by default. Not even date formatting, for example.
However, there is lukyly another way to do it:
let us provide a sitecustomize.py module for zope. If its in the path, it has access to sys.setdefaultencoding
That still breaks Python libraries that assume this has not been changed. This is a legitimate assumption made by these libraries; the same as assuming the behaviour of (string+integer).
I use it that way (I set utf-8) and Zope unicodes and strings quite good.
Feel free to do that in your own zope, but this will never be a supported way of using Python. I think it is irresponsible to recommend this approach as if it was standard practice.
Toby Dickenson kirjutas P, 03.11.2002 kell 01:15:
On Saturday 02 November 2002 1:48 am, Tino Wildenhain wrote:
if encoding != "ascii": sys.setdefaultencoding(encoding)
This implies modification of the installed code to change default behavior. I would consider this as bad. Why isnt a locales sensitive version the default?
That would make it difficult to write reliable portable Python code. It is a good thing that Python has predictable behaviour for things like (string+integer), a local-sensitive or user-sensitive default encoding would make (plain string+unicode string) unpredictable.
So the default encoding = 'ascii' is there to always force explicit conversion ?
Note that nothing else in Python depends on locales by default. Not even date formatting, for example.
Has python finally got a decent standard date module ?
However, there is lukyly another way to do it:
let us provide a sitecustomize.py module for zope. If its in the path, it has access to sys.setdefaultencoding
That still breaks Python libraries that assume this has not been changed.
This is a legitimate assumption made by these libraries; the same as assuming the behaviour of (string+integer).
Otoh it is quite weird to have a way to set default encoding that is inaccessible for users ;(
I use it that way (I set utf-8) and Zope unicodes and strings quite good.
Feel free to do that in your own zope, but this will never be a supported way of using Python. I think it is irresponsible to recommend this approach as if it was standard practice.
sitecustomize.py seems to be the recommended way of overriding the default charset , so why not recommend it as such? And UTF-8 as default encoding for unicode should become the supported way of using Python - computing is becoming universally available to all people, not just plain-ascii-speaking ones. ----------------------- Hannu
Toby Dickenson writes:
... Why isnt a locales sensitive version the default?
That would make it difficult to write reliable portable Python code. I (and probably a high percentage of Python users) am usually uninterested to write portable Python code.
I am *really* interested to write uncluttered code that works in my standard environment (as already noted: almost all in the filesystem and all devices use Latin-1 encoding). Therefore, I want a way to declare to Python what this standard environment is. And I feel these "Unicode conversion errors" really stupid when I interactively work with Python. Authors of modules that should be used internationally are free to set their default encoding to the least common denominator: ASCII. I am able to patch Python to give it back its "setdefaultencoding" should Guido decide to remove it. And I can publish the necessary patch. But, I doubt that we should need such a patch. Dieter
Dieter Maurer wrote:
I am *really* interested to write uncluttered code that works in my standard environment (as already noted: almost all in the filesystem and all devices use Latin-1 encoding). Therefore, I want a way to declare to Python what this standard environment is. And I feel these "Unicode conversion errors" really stupid when I interactively work with Python.
I'm with Dieter on this one... Chris
Hi, --On Samstag, 2. November 2002 20:15 +0000 Toby Dickenson <tdickenson@geminidataloggers.com> wrote:
On Saturday 02 November 2002 1:48 am, Tino Wildenhain wrote:
if encoding != "ascii": sys.setdefaultencoding(encoding)
This implies modification of the installed code to change default behavior. I would consider this as bad. Why isnt a locales sensitive version the default?
That would make it difficult to write reliable portable Python code. It is a good thing that Python has predictable behaviour for things like (string+integer), a local-sensitive or user-sensitive default encoding would make (plain string+unicode string) unpredictable.
*think* *think* *think* Sorry, I cannot see how this would be unpredictable. Ascii-users will use only thier ascii charset information and - with or without locales - get their ascii unicode strings concenated. Fine. international users who whould have no locales - this would bring them the same error they are getting now -> default would be ascii international users with locales setting would assume they can use every allowed character in their encoding - because of locales sensitiveness it would happen to work as expected. In every module. If some modules has seriously requirements to depend on a specific encoding it should explicitely use encode('ascii') on it. I'm open to comments on what I might have overlooked. Regards Tino
Tino Wildenhain writes:
I dont know why this code is in site.py:
encoding = "ascii" # Default value set by _PyUnicode_Init()
if 0: # Enable to support locale aware default string encodings. import locale loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1]
if 0: # Enable to switch off string to Unicode coercion and implicit # Unicode to string conversion. encoding = "undefined"
if encoding != "ascii": sys.setdefaultencoding(encoding)
This implies modification of the installed code to change default behavior. I would consider this as bad. Why isnt a locales sensitive version the default? Good! That would be a sensible default!
Dieter
participants (7)
-
Chris Withers -
Dieter Maurer -
Hannu Krosing -
Juan Manuel Ruiz Garcia -
Paul Winkler -
Tino Wildenhain -
Toby Dickenson