Re: [Python-Dev] New Python Initialization API
Maybe I should clarify in the PEP 587 Rationale what are the use cases for the API. Embeding Python is one kind of use case, but writing your own Python with a specific config like "isolated Python" or "system Python" is also a valid use case. For a custom Python, you might want to get C locale coercion and UTF-8 Mode. The most common case is to embed Python in an application like Blender or vim: the application already executes a lot of code and manipulated strings and encoding before Python is initialized, so Python must not coerce the C locale in that case. That's why Nick and me decided to disable C loclae coercion and UTF-8 Mode by default when the C API is used. Victor Le samedi 6 avril 2019, Inada Naoki a écrit : > On Sat, Apr 6, 2019 at 1:13 AM Victor Stinner wrote: >> >> > > ``PyPreConfig`` fields: >> > > >> > > * ``coerce_c_locale_warn``: if non-zero, emit a warning if the C locale >> > > is coerced. >> > > * ``coerce_c_locale``: if equals to 2, coerce the C locale; if equals to >> > > 1, read the LC_CTYPE to decide if it should be coerced. >> > >> > Can we use another value for coerce_c_locale to determine whether to >> > warn or not? Save a field. >> >> coerce_c_locale is already complex, it can have 4 values: -1, 0, 1 and 2. >> I prefer keep a separated field. >> >> Moreover, I understood that you might want to coerce the C locale *and* >> get the warning, or get the warning but *not* coerce the locale. >> > > Are these configurations are really needed? > > Applications embedding Python may not initialize Python interpreter at first. > For example, vim initializes Python when Python is used first time. > > On the other hand, C locale coercion should be done ASAP application starts. > > I think dedicated API for coercing C locale is better than preconfig. > > // When application starts: > Py_CoerceCLocale(warn=0); > > // later... > Py_Initialize(); > > -- > Inada Naoki > -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Python Initialization API
On Sat, 6 Apr 2019 at 02:16, Victor Stinner wrote: > > > ``PyPreConfig`` fields: > > > > > > * ``coerce_c_locale_warn``: if non-zero, emit a warning if the C locale > > > is coerced. > > > * ``coerce_c_locale``: if equals to 2, coerce the C locale; if equals to > > > 1, read the LC_CTYPE to decide if it should be coerced. > > > > Can we use another value for coerce_c_locale to determine whether to > > warn or not? Save a field. > > coerce_c_locale is already complex, it can have 4 values: -1, 0, 1 and 2. > I prefer keep a separated field. > > Moreover, I understood that you might want to coerce the C locale *and* > get the warning, or get the warning but *not* coerce the locale. Yeah, that's how they ended up being two different fields in the first place. However, I wonder if the two fields might be better named: * warn_on_legacy_c_locale * coerce_legacy_c_locale Neither set: legacy C locale is left alone Only warning flag set: complain about the legacy C locale on stderr Only coercion flag set: silently attempt to coerce the legacy C locale to a UTF-8 based one Both flags set: attempt the coercion, and then complain about it on stderr (regardless of whether the coercion succeeded or not) The original PEP 580 implementation tried to keep the config API simpler by always complaining, but that turned out to break the world (plenty of contexts where things get upset by unexpected output on stderr). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Python Initialization API
On Sun, 7 Apr 2019 at 12:45, Nick Coghlan wrote: > The original PEP 580 implementation tried to keep the config API > simpler by always complaining, but that turned out to break the world > (plenty of contexts where things get upset by unexpected output on > stderr). Err, PEP 538. No idea why my brain swapped in the wrong PEP number :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating "instance method" class
05.04.19 20:56, Jeroen Demeyer пише: On 2019-04-05 19:53, Serhiy Storchaka wrote: At Python level we can monkeypatch __gt__, but not tp_richcompare. Sure, but you're planning to use C anyway so that's not really an argument. total_ordering monkeypatches the decorated class. I'm planning to implement in C methods that implement __gt__ in terms of __lt__ etc. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
