Gustavo Sverzut Barbieri wrote:
> Yes, they're... If you check the cvs logs you see my changes are very
> punctual, but I spent a lot of time making it work... and discovering
> where it breakes... as you mentioned below, it generally breaks when
> doing str(), cause python uses ASCII as default encoding. One possible
> solution is to keep it unicode as far as possible and when we need to
> make it a string, we should use some testings, like:
>
> if type( possible_string ) == unicode:
> s = possible_string.encode( "utf-8" )
We should check were we need it and wrap this functions. We only need
it when outputing from Freevo and our outputs are 1. the _debug_
function, 2. some stuff in osd.py and 3. calling Python functions,
most of all the os-calls. Right now it seems to break here and there.
> it works everywhere, given you have the font.
>
>
>> The default encoding in Python 2.3 is 'ascii'. You can't change
>> that. If you have a string (when I say string, I mean str()) which
>> non
>> ascii chars (e.g. latin-1),
>
> Talking to people in #python I discovered a package called "site" which
> let you change it. But from what I understand, it changes the whole
> system, not just the program.
Yes, in site.py is a variable to set the locale. But it's fixed to
'ascii' and a warning about changing it.
>> you can't just run unicode(mystring), it
>> would cause an UnicodeError, because Freevo want's to use the 'ascii'
>> encoding. The correct way is unicode(mystring, 'latin-1') or in our
>> case replace latin-1 with config.LOCALE.
>
> Now we have config.encoding, which uses (in order) FREEVO_LOCALE, LANG
> and LC_ALL. It contains the second element in the pair:
> LANGUAGE.ENCODING. If you want freevo to use UTF-8 (my case), just do:
> "FREEVO_LOCALE=pt_BR.UTF-8 freevo"
Also try config.LOCALE. We use it very often, so we not reuse a
variable.
>> Now we can keep all internal
>> strings as unicode. But the problem is also the way back.
>
> Yes. And I would apreciate if you devs look at my changes and check if
> I'm converting it to string (.encode(...)) when we could keep it
> unicode.
Maybe we should create our own object. This whole enocde, decode,
unicode() stuff is making me crazzy. And it looks gad in the code if
we encode and decode all the time.
class freevostring:
def __init__:
creates a string and converts it to unicode internaly
def __str__
returns the string as str()
But are there member functions like __unicode__ and __add__ (for x +
y)? We would need that. Maybe inherit from Unicode and only fix the
str() function inside that?
> If you use os.listdir( u'string' ) it returns (if possible, if not it
> returns a string. must check. I did it one place, maybe we need to
> check others too) a list of unicode objects.
>
> Others like statvfs doesn't, so you need the .encode( ... )
Yes, IMHO it's very ugly to encode and decode all the time. That's
very bad in Python right now.
> The major problem I see is with metadata. I saw that ogg uses utf-8
> internally, but if others don't it will become a real mess, since the
> metdata probably come from the internet and then you have no way to
> guess what encoding to use.
All data coming to freevo needs to be converted to unicode if they are
string. And we should always make sure there will be no UnicodeError
ever!
> I commited it soon so people could test. I don't use freevo daily and
> have few non-ascii filenames/metadata, so I can't test it much more.
I will try which German Umlauts (����)
Dischi
--
Time passed, which, basically, is its job.
-- Terry Pratchett (in: Equal Rites)
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
