Re: [Python-Dev] Unicode identifiers in test files?
On 5/4/19 2:48 AM, Serhiy Storchaka wrote: 04.05.19 05:46, Eric V. Smith пише: Is there a policy against using Unicode identifiers in test files? As part of adding !d to f-strings, there's a code path that's only executed if the text of the expression is non-ascii. The easiest way to exercise it, and the way I found a bug, is by using an identifier with Unicode chars. I know we have a policy against this in Lib/, but what about Lib/test/? I could work around this with exec-ing some strings, but that seems like added confusion that I'd avoid with a real Unicode identifier. Could you use string literals with non-ascii characters? They are more used in tests. Hi, Serhiy. I could and will, yes: thanks for the suggestion. But for this specific feature, I also want to test with simple variable-only expressions. I'm either going to use a unicode identifier in the code, or eval one in a string. Doing the eval dance just seems like extra work for some sort of purity that I don't think is important in a test, unless someone can think of a good reason for it. Eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode identifiers in test files?
On 5/4/19 3:54 AM, Eric V. Smith wrote: On 5/4/19 2:48 AM, Serhiy Storchaka wrote: 04.05.19 05:46, Eric V. Smith пише: Is there a policy against using Unicode identifiers in test files? As part of adding !d to f-strings, there's a code path that's only executed if the text of the expression is non-ascii. The easiest way to exercise it, and the way I found a bug, is by using an identifier with Unicode chars. I know we have a policy against this in Lib/, but what about Lib/test/? I could work around this with exec-ing some strings, but that seems like added confusion that I'd avoid with a real Unicode identifier. Could you use string literals with non-ascii characters? They are more used in tests. Hi, Serhiy. I could and will, yes: thanks for the suggestion. But for this specific feature, I also want to test with simple variable-only expressions. I'm either going to use a unicode identifier in the code, or eval one in a string. Doing the eval dance just seems like extra work for some sort of purity that I don't think is important in a test, unless someone can think of a good reason for it. And I just noticed that PEP 3131 has an exception for tests in its section that says the stdlib can't contain unicode identifiers: https://www.python.org/dev/peps/pep-3131/#policy-specification So, since it's the most direct and probably safest thing to do for a test, I'm going to use a unicode identier. Thanks, all, for your ideas. Especially Greg for reminding me to add the coding comment. Eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 2nd version
2019年5月3日(金) 4:59 Victor Stinner : > > * PyConfig now only uses wchar_t* for strings (unicode): char* (bytes) > is no longer used. I had to hack CPython internals for that :-) I prefer char* to wchar_t* on Unix. Since UTF-8 dominated Unix world in these decades, wchar_t* is less usable on Unix nowadays. Is it impossible to use just char* on Unix and wchar_t* on Windows? -- Inada Naoki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 2nd version
Hi INADA-san, This PEP is the result of 2 years of refactoring to *simplify* the *implementation*. I agree that bytes string is the native type on Unix. But. On Windows, Unicode is the native type. On Python 3, Unicode is the native type. One key of the simplified implementation is the unique PyConfig structure. It means that all platforms have to use the same types. I love the idea of using only wchar_t* for PyConfig because it makes Python initialization more reliable. The question of the encoding used to decode byte strings and any possible decoding error (very unlikely thanks to surrogateescape) is better defined: it occurs when you set the parameter, not "later during init". The PEP adds Py_UnixMain() for most trivial use cases, and PyConfig_DecodeLocale() and PyConfig_SetArgs() for more advanced cases. Victor Le samedi 4 mai 2019, Inada Naoki a écrit : > 2019年5月3日(金) 4:59 Victor Stinner : >> >> * PyConfig now only uses wchar_t* for strings (unicode): char* (bytes) >> is no longer used. I had to hack CPython internals for that :-) > > I prefer char* to wchar_t* on Unix. Since UTF-8 dominated Unix world > in these decades, wchar_t* is less usable on Unix nowadays. > > Is it impossible to use just char* on Unix and wchar_t* on Windows? > > -- > Inada Naoki > -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "if __name__ == '__main__'" at the bottom of python unittest files
Terry Reedy writes: > I agree that complete 100.000% test coverage is a nice ideal, but > sometimes the last percent can take hours to accomplish, if it is > indeed sensibly possible. 100% test coverage is an ideal. Reports *claiming* 100% coverage, however, are of practical benefit. The point is to identify a regression. It's best to have 100% coverage, because it's possible that improvements in the environment allow a test that wasn't reliable (== deterministic) or maybe not even feasible before to become feasible and reliable, and a coveragerc that says "oh, that line is OK" will obscure that possibility. But a *claim* (albeit somewhat undermined by a non-trivial coveragerc) of 100% coverage means it's *easy to identify regressions in coverage*. I think that's a bigger deal, at least at this time. > I have asked more that once what .coveragerc file is being used by > CI and whether we can somehow properly customize it for CPython. Seconded. Thank you for pushing this, and for all the other efforts you're making here. Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
