> 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=detail&aid=1283895&group_id=5470&atid=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