[ python-Feature Requests-1052098 ] Seting defaultencoding through an environment variable

SourceForge.net noreply at sourceforge.net
Sat Oct 23 13:30:10 CEST 2004


Feature Requests item #1052098, was opened at 2004-10-22 12:11
Message generated for change (Comment added) made by diedrich
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1052098&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: Rejected
Priority: 1
Submitted By: Diedrich Vorberg (diedrich)
Assigned to: Nobody/Anonymous (nobody)
Summary: Seting defaultencoding through an environment variable

Initial Comment:
Hallo, I'd love to be able to set Python's default
encoding on a per instance basis through an environment
variable like

  PYTHON_DEFAULT_ENCODING

or something. That would require a trivial modification
to site.py. 

Diedrich

----------------------------------------------------------------------

>Comment By: Diedrich Vorberg (diedrich)
Date: 2004-10-23 13:30

Message:
Logged In: YES 
user_id=442849

Ah.. ok.. some examples:

I'm writing Web-Applications using CGI or FastCGI. The
webserver will pass user input as plain strings but within
my program I want to use plain strings as little as possible
to avoid all kinds of problems with diacritical characters
(foremost umlauts and the EUR symbol). The websites the CGI
scripts are used with usually have one charset for all
pages. But some sites use iso-8859-1 and some use utf-8 and
I don't want to modify my scripts to fit the charset of the
site. Rather I'd like to  use Apache's SetEnv directive to
tell my scripts what charset their input is going to be in.
Yes, I know, there are other ways to handle this :-)

I keep using XIST for html output
(http://www.livinglogic.de/Python). XIST tries to avoid
using the default encoding, probably in the light of it
being depricated. But it does not avoid it completely. There
are a number of subtle cases in which it still depends on it
and in all these cases I run into run-time errors which can
be avoided in a snap by 
setting the default encoding to what my actual default
encoding is.
I use XIST with Zope and FastCGI, running several instances
of the same interpreter on the same machine, with different
default encodings each (mostly utf-8, but some iso-8859-1,
which I can't just convert).

My own OSS project orm (http://t4w.de/orm) carefully
seperates the database's and the application's charset but
uses Python's default encoding as the default for each and
every setting. Those settings need to be set explicitly if
the default encoding does not match the encoding actually
used, cluttering the sourcecode and making maintaince more
difficult. I use orm in connection with all the above cases.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2004-10-23 12:55

Message:
Logged In: YES 
user_id=21627

No, I'm asking *why* you consider it useful. For example

a) here is this and that problem, and there is absolutely no
way to express this in Python today. If that feature is
added, I can write it in the following way.

b) here is this and that problem. Today, I have to write it
in this way. With the feature added, I can write it in that
way. That way is better than this way because of such and
such reason.

IOW, I would like to see what you are using the default
encoding *for* that makes it desirable to set it through an
environment variable.

----------------------------------------------------------------------

Comment By: Diedrich Vorberg (diedrich)
Date: 2004-10-23 12:40

Message:
Logged In: YES 
user_id=442849

Well... what more than useful is it supposed to be?
Earh-shaking? Spiritually rewarding? ;-) As long as there is
a default encoding I'd like to be able to set it in a
simpler way than I can now. And I'd like to be able to set
it once, at interpreter startup. An environment variable
seems like a reasonable way to do that.

If the notion of default encoding is removed from Python's
library the suggested modification is going to go away as well. 

If you want to reject the feature request because the notion
of default encoding is depricated, than so be it. From my
point of view the suggested modification is something I'd
like to see.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2004-10-23 12:09

Message:
Logged In: YES 
user_id=21627

I take it that you are withdrawing your feature request,
then? Closing it as rejected; if you still think this should
be done, please indicate so. It would be good if you then
could give some reasoning beyond "it would be useful"

----------------------------------------------------------------------

Comment By: Diedrich Vorberg (diedrich)
Date: 2004-10-23 12:05

Message:
Logged In: YES 
user_id=442849

Yes, you are right. I could also replace the global
unicode() function with my own version that adheres to my
global encoding settings. But that doesn't seem the right
thing to do. Anyway, this is not so much a technical
decision but one that touches design. 

Anyway, it's just a small thing I tought usefull. If the
defaultencoding goes away altogether, I'll have to make
something up on my own anyway.

Thanks for your comments!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2004-10-23 11:52

Message:
Logged In: YES 
user_id=21627

If your application just needs a global setting, it can come
up with its own environment variable, right? Just set
MY_DEFAULT_ENCODING, and do

encoding=os.environ["MY_DEFAULT_ENCODING"]

Alternatively, try using locale.getpreferredencoding(); this
may allow to avoid an additional environment variable
altogether.

----------------------------------------------------------------------

Comment By: Diedrich Vorberg (diedrich)
Date: 2004-10-23 11:08

Message:
Logged In: YES 
user_id=442849

Even if the notion of default encoding were dropped from
Python, my application will need a global variable to have
one encoding that is used most of the time. That`s what I`m
using the default encoding for right now. Also, at least one
of the 3d party modules I'm using does the same and it makes
tons of sense. Changing the default encoding from within my
application doesn't work, because sys.setdefaultencoding()
gets removed (which makes sense, too, of course). So I need
a custom sitecustomize.py for every project which may or may
not be adhered to, depending on the PYTHONPATH variable.
That`s why a  PYTHON_DEFAULT_ENCODING variable would be very
usefull to me.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2004-10-23 10:32

Message:
Logged In: YES 
user_id=21627

Why do you want this change? In the long run, Python will
drop the notion of a default encoding; code should be
changed to avoid relying on the default encoding.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1052098&group_id=5470


More information about the Python-bugs-list mailing list