Re: [Python-Dev] international python
This does make me think of the interesting prospect of an internationalised string literal, though (e.g., _This an il8n string). I'm not sure it would be enough of a win over the status quo though, I don't think so either. i18n doesn't require its specific string notation (in addition, dropping _() may make it harder to interface with standard gettext tools). On the hand, international support in Python apps will benefit from: - seamless unicode support: how about making the default Python charset utf-8 instead of ascii ? right now, someone (say an American or English) who does not design his app with non-ascii characters in mind may have a surprise when users enter those characters in customizable fields: for example, debug print statements which end up crashing the app with an UnicodeException on the user's machine, without even a way to diagnose this when the app is a GUI app and stdout is not shown ;)) - simple formatting syntax (the current % operator is quite fine in that regard) As for seamless unicode support, there are also problems sometimes with filenames and filepaths: see e.g. https://sourceforge.net/tracker/?func=detailaid=1283895group_id=5470atid=105470 Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] international python
Antoine Pitrou wrote: - seamless unicode support: how about making the default Python charset utf-8 instead of ascii ? right now, someone (say an American or English) who does not design his app with non-ascii characters in mind may have a surprise when users enter those characters in customizable fields: for example, debug print statements which end up crashing the app with an UnicodeException on the user's machine, without even a way to diagnose this when the app is a GUI app and stdout is not shown ;)) using a variable-width default encoding will break stuff that expect string lengths to be constant, or just prefer their character and slice indices to stay where they are. defaulting to replace (or better, an escaping UnicodeEncodeError handler) on the standard output channels would be a better idea. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] international python
Le vendredi 09 septembre 2005 à 23:09 +1000, Neil Hodgson a écrit : Antoine Pitrou: As for seamless unicode support, there are also problems sometimes with filenames and filepaths: see e.g. https://sourceforge.net/tracker/?func=detailaid=1283895group_id=5470atid=105470 This bug report is using byte string arguments causing byte string processing rather than unicode calls with unicode processing. Windows code that may encounter file paths outside the default locale should stick to unicode for paths. Try converting os.curdir to unicode before calling other functions: os.path.abspath(unicode(os.curdir)) I don't have a Windows machine at hand right now to test it, but, even if this solution works, it breaks the principle of least astonishment: os.path.abspath() should do the Right Thing regardless of what the current locale is. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] international python
Antoine Pitrou: I don't have a Windows machine at hand right now to test it, but, even if this solution works, it breaks the principle of least astonishment: Astonishment is subjective and so a poor tool to measure by. At one stage Ruby tried to follow the more common formulation principle of least surprise (POLS) but this produced arguments of the following form: I am surprised by X. Therefore, X contradicts POLS. Therefore, X must be fixed. POLS was then abandoned. os.path.abspath() should do the Right Thing regardless of what the current locale is. This was discussed recently and the consensus position was for functions that can not return a value in the default encoding to instead return a unicode value. Correct implementation of this would require not only changing the behaviour of functions returning strings but also those receiving strings (which should treat byte strings as being in the default encoding). This would require a large amount of work, and is unlikely to be performed in the near future. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
