Dear All,
The solution / explanation follows.
Thanks to Graham Dumpleton, the author of mod_wsgi (the WSGI module for
Apache2) the source of the problem could be traced back to variables in
Apache2. Below are the details reproduced from
Chris Angelico ros...@gmail.com:
Apache itself most likely is running with LANG=C and other
environmental changes. It's not a Python-specific thing.
The topic is discussed also at: URL: http://blog.dscpl.com.au/2014/0
9/setting-lang-and-lcall-when-using.html.
Personally, I think the C locale
On Wednesday, August 26, 2015 at 5:59:12 PM UTC+2, Chris Angelico wrote:
On Thu, Aug 27, 2015 at 1:02 AM, RAH wrote:
7) Now, that source of the problem is known, I must investigate why my
run-time environment differs from the interpreter environment. I know it is
the same machine, same
On 26/08/15 04:19, RAH wrote:
UnicodeEncodeError: 'ascii' codec can't encode character '\\xc7' in position
15: ordinal not in range(128)
(Hi all, this is my first post to the list)
This can be a frustrating issue to resolve, but your issue might be
solved with this environment variable:
On Thu, Aug 27, 2015 at 1:02 AM, RAH rene.heym...@gmail.com wrote:
7) Now, that source of the problem is known, I must investigate why my
run-time environment differs from the interpreter environment. I know it is
the same machine, same Python 3.4.0. As the mod_wsgi module in Apache2
On Wed, Aug 26, 2015 at 7:12 PM, RAH rene.heym...@gmail.com wrote:
By the way my whole installation is defaulted to UTF-8:
HTML:headmeta charset=utf-8/head
Javascript: script type=text/javascript charset=UTF-8
PuTTY: TranslationCharacter set translationRemote character setUTF-8
Dear Chris,
I can confirm it is Python 3. Here is the line from the Apache2 log:
[Wed Aug 26 10:28:01.508194 2015] [mpm_worker:notice] [pid 1120:tid 3074398848]
AH00292: Apache/2.4.7 (Ubuntu) OpenSSL/1.0.1f mod_wsgi/4.4.13 Python/3.4.0
configured -- resuming normal operations
As a matter of
Dear Chris,
Thank you. I got the answer (at least a partial one) that I will share in a
while. I will first respond to the other posts I received to thank each and
everyone.
Please stay tuned.
René
--
https://mail.python.org/mailman/listinfo/python-list
Thank you Pete.
Indeed it has to do with choice of encoding.
I'll be back in a short while with more details.
Cheers,
René
--
https://mail.python.org/mailman/listinfo/python-list
Dear Dieter,
Indeed there is a difference.
I will share my discoveries in a while after I respond to each one.
Be in touch soon.
Thanks.
René
--
https://mail.python.org/mailman/listinfo/python-list
Thank you Chris. I'll share my findings in a moment.
Please bear with me a bit more time.
Cheers,
René
--
https://mail.python.org/mailman/listinfo/python-list
Dear All,
First, thanks to each and everyone.
There is indeed a solution by I haven't yet found the root of the problem (I'll
come back to that at the end of my post).
1) After many trials and errors, I found that the problem was with the write()
function in `h.write(str(d) + '\n')` and not
On Thu, Aug 27, 2015 at 5:23 AM, RAH rene.heym...@gmail.com wrote:
Nevertheless I can't figure out why calling Python in the shell (interactive
mode) or letting mod_wsgi start the same Python provide two different
environments. I guess I must investigate that part because mod_wsgi gets to
RAH rene.heym...@gmail.com writes:
I experienced an incomprehensible behavior (I've spent already many hours on
this subject): the `file.write('string')` provides an error in run mode and
not when interpreted at the console.
Maybe, I can explain the behavior: the interactive interpreter
On Wed, Aug 26, 2015 at 7:19 AM, RAH rene.heym...@gmail.com wrote:
rb = request_body.decode() # string
I'd recommend avoiding this operation in Python 2. As of Python 3,
omitting the encoding means UTF-8, but in Python 2 it means use the
default encoding,
Dear All,
I experienced an incomprehensible behavior (I've spent already many hours on
this subject): the `file.write('string')` provides an error in run mode and not
when interpreted at the console. The string must contain non-ASCII characters.
If all ASCII, there is no error.
The following
On Tue, Aug 25, 2015 at 2:19 PM, RAH rene.heym...@gmail.com wrote:
Dear All,
I experienced an incomprehensible behavior (I've spent already many hours on
this subject): the `file.write('string')` provides an error in run mode and
not when interpreted at the console. The string must contain
17 matches
Mail list logo
