Note: This would be in addition to a directive like in Python files:
coding: ...
- (+) Simple, straight-forward
- (-)
Builder.load_file(...)
andBuilder.load_string(open(...))
would have differing behaviours (Windows, Linux without UTF-8 locale) because defaultopen(...)
uses preferred system encoding - (?) can't say what the impact on mobile devices is (Android/iOS)
- (?) can't say what the impact on OSX is
- (~) unsure how many people on Windows use editors which safe their files in the default encoding
- (~) py2 only people might be surprised about the difference between .py <-> .kv
- (+) it's probably what people expect
- for those doing only py2 development, they already need to care about the directive, and if not there are no surprises in where it fails (.kv == .py)
- py2/py3 compat: devs should always include the
coding: utf-8
directive, that's imho the easiest way of doing compatible Python programs (together withfrom __future__ import unicode_literals
). [TODO example?] - py3 defaults to utf-8 and so would .kv when run with py3
- (+) could probably build on code in tokenize.py
(lower chance of a bug)actually, just using utf-8 should be trivial enough - (-)
Builder.load_file(...)
andBuilder.load_string(open(...))
would have differing behaviours (Windows, Linux without UTF-8 locale) because defaultopen(...)
uses preferred system encoding.- at least on py3; py2 might work as expected [TODO verify]
- (-) py2/py3 compat pretty much requires adding that directive in every file to be on the safe side.
- (-) Windows (Linux without utf-8 locale): introduces not just one breaking encoding change, but potentially 2, because different behaviour on py2 <-> py3.
- (?) can't say what the impact on mobile devices is (Android/iOS)
- (?) can't say what the impact on OSX is
- (+) Doesn't break existing code
- (-) People have to add the directive in all their files
- Android note: The Android platform default is always UTF-8. excerpt from Charset | Android Developers