Re: [Python-Dev] New Python Initialization API

2019-04-09 Thread Steve Dower
On 05Apr2019 0936, Victor Stinner wrote: For the PyMainConfig structure idea, I cannot comment at this point. I need more time to think about it. About the "path configuration" fields, maybe a first step to enhance the API would be to add the the following function: PyInitError PyConfig_Comput

Re: [Python-Dev] New Python Initialization API

2019-04-09 Thread Steve Dower
On 05Apr2019 0922, Victor Stinner wrote: While there are supporters of an "isolated Python" (sometimes called "system python"), the fact that it doesn't exist in any Linux distribution nor on any other operating system (Windows, macOS, FreeBSD), whereas it's already doable in Python 3.6 with Py_I

Re: [Python-Dev] New Python Initialization API

2019-04-09 Thread Steve Dower
On 05Apr2019 0912, Victor Stinner wrote: About PyPreConfig and encodings. [...] * ``PyInitError Py_PreInitialize(const PyPreConfig *config)`` * ``PyInitError Py_PreInitializeFromArgs( const PyPreConfig *config, int argc, char **argv)`` * ``PyInitError Py_PreInitializeFromWideArgs( const PyPreC

Re: [Python-Dev] New Python Initialization API

2019-04-09 Thread Steve Dower
Thanks for the replies. Anything I don't comment on means that I agree with you :) On 05Apr2019 0900, Victor Stinner wrote: Honestly, I'm not sure that we really have to distinguish "user error" and "internal error". It's an old debate about calling abort()/DebugBreak() or not. It seems like mo

Re: [Python-Dev] New Python Initialization API

2019-04-06 Thread Nick Coghlan
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

Re: [Python-Dev] New Python Initialization API

2019-04-06 Thread Nick Coghlan
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 de

Re: [Python-Dev] New Python Initialization API

2019-04-06 Thread Victor Stinner
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 coe

Re: [Python-Dev] New Python Initialization API

2019-04-05 Thread Inada Naoki
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 t

Re: [Python-Dev] New Python Initialization API

2019-04-05 Thread Victor Stinner
For the PyMainConfig structure idea, I cannot comment at this point. I need more time to think about it. About the "path configuration" fields, maybe a first step to enhance the API would be to add the the following function: PyInitError PyConfig_ComputePath(PyConfig *config, const wchar *home);

Re: [Python-Dev] New Python Initialization API

2019-04-05 Thread Victor Stinner
> I think my biggest point (about halfway down) is that I'd rather use > argv/environ/etc. to *initialize* PyConfig and then only use the config > for initializing the runtime. That way it's more transparent for users > and more difficult for us to add options that embedders can't access. I chose

Re: [Python-Dev] New Python Initialization API

2019-04-05 Thread Victor Stinner
> > Example of Python initialization enabling the isolated mode:: > > > > PyConfig config = PyConfig_INIT; > > config.isolated = 1; > > Haven't we already used extenal values by this point that should have > been isolated? On this specific example, "config.isolated = 1;" ensures that Py_Pr

Re: [Python-Dev] New Python Initialization API

2019-04-05 Thread Victor Stinner
About PyPreConfig and encodings. > The appendix is excellent, by the way. Very useful detail to have > written down. Thanks. The appendix is based on Include/cpython/coreconfig.h comments which is now my reference documentation. By the way, this header file contains more information about PyConfi

Re: [Python-Dev] New Python Initialization API

2019-04-05 Thread Victor Stinner
Le dim. 31 mars 2019 à 01:49, Steve Dower a écrit : > Here is my first review of https://www.python.org/dev/peps/pep-0587/ and > in general I think it's very good. Ah nice, that's a good start :-) Thanks for reviewing it. Your email is long, and answer makes it even longer, so I will reply in mu

Re: [Python-Dev] New Python Initialization API

2019-03-30 Thread Steve Dower
Here is my first review of https://www.python.org/dev/peps/pep-0587/ and in general I think it's very good. There are some things I'd like to consider changing before we embed them permanently in a public API, and as I'm still keen to have the ability to write Python code for configuration (to repl

Re: [Python-Dev] New Python Initialization API

2019-03-30 Thread Nick Coghlan
On Sat, 30 Mar 2019 at 12:45, Steve Dower wrote: > > On 29Mar.2019 1830, Victor Stinner wrote: > > The purpose of the PEP 587 is to have a working document so everyone > > can look at the proposed API (stay focused to the API rather than > > bothering with the implementation). IMHO it's now time t

Re: [Python-Dev] New Python Initialization API

2019-03-29 Thread Steve Dower
On 29Mar.2019 1830, Victor Stinner wrote: > The purpose of the PEP 587 is to have a working document so everyone > can look at the proposed API (stay focused to the API rather than > bothering with the implementation). IMHO it's now time to get more > people looking at the Python Initialization. >

Re: [Python-Dev] New Python Initialization API

2019-03-29 Thread Victor Stinner
The purpose of the PEP 587 is to have a working document so everyone can look at the proposed API (stay focused to the API rather than bothering with the implementation). IMHO it's now time to get more people looking at the Python Initialization. > But there are enough of us > with fuzzy but valid

Re: [Python-Dev] New Python Initialization API

2019-03-28 Thread Steve Dower
On 28Mar2019 0703, Victor Stinner wrote: In fact, there is already a PyConfig._init_config flag (currently named _PyCoreConfig._init_main) which only initializes Python up to the "core initialization" if set to 0. This parameter is private since it's unclear to me what should be the exact scope o

Re: [Python-Dev] New Python Initialization API

2019-03-28 Thread Victor Stinner
Le mer. 27 mars 2019 à 21:26, Brett Cannon a écrit : > On Wed, Mar 27, 2019 at 12:39 PM Steve Dower wrote: >> I this this should be its own PEP, since as you say it is not >> implementing the only PEP we have (or alternatively, maybe you should >> collaborate to update PEP 432 so that it reflects

Re: [Python-Dev] New Python Initialization API

2019-03-28 Thread Ivan Pozdeev via Python-Dev
On 27.03.2019 20:48, Victor Stinner wrote: Hi, I would like to add a new C API to initialize Python. I would like your opinion on the whole API before making it public. The code is already implemented. Doc of the new API: https://pythondev.readthedocs.io/init_config.html To make the API

Re: [Python-Dev] New Python Initialization API

2019-03-28 Thread Victor Stinner
Le jeu. 28 mars 2019 à 05:27, Stephen J. Turnbull a écrit : > Victor Stinner writes: > > > I just fixed the mojibake issue in Python 3.8 by disabling C locale > > coercion and UTF-8 Mode by default. I'm not sure if nor how Python 3.7 > > should be fixed in a minor 3.7.x release. > > That sounds

Re: [Python-Dev] New Python Initialization API

2019-03-27 Thread Stephen J. Turnbull
Victor Stinner writes: > I just fixed the mojibake issue in Python 3.8 by disabling C locale > coercion and UTF-8 Mode by default. I'm not sure if nor how Python 3.7 > should be fixed in a minor 3.7.x release. That sounds like a potential regression. Those two features were added *and turned

Re: [Python-Dev] New Python Initialization API

2019-03-27 Thread Victor Stinner
Ah, I forgot to say that a major enhancement for the implementation is that I wrote a lot of new unit tests for the existing Python Initialization API. Python 3.7 has most of these tests. I wrote even more tests for my new private initialization API ;-) I wrote these tests to specify and validate

Re: [Python-Dev] New Python Initialization API

2019-03-27 Thread Victor Stinner
Le mer. 27 mars 2019 à 19:35, Alexander Belopolsky a écrit : > Would you consider making _Py_UnixMain public as well? > > It is useful for high level embedding and not trivial for 3rd parties to > reimplement. Right, Py_Main() is causing a lot of practice issues, especially mojibake because of t

Re: [Python-Dev] New Python Initialization API

2019-03-27 Thread Brett Cannon
On Wed, Mar 27, 2019 at 12:39 PM Steve Dower wrote: > On 27Mar2019 1048, Victor Stinner wrote: > > Since November 2017, I'm refactoring the Python Initialization code to > > cleanup the code and prepare a new ("better") API to configure Python > > Initialization. I just fixed the last issues that

Re: [Python-Dev] New Python Initialization API

2019-03-27 Thread Steve Dower
On 27Mar2019 1048, Victor Stinner wrote: Since November 2017, I'm refactoring the Python Initialization code to cleanup the code and prepare a new ("better") API to configure Python Initialization. I just fixed the last issues that Nick Coghlan asked me to fix (add a pre-initialization step: done

Re: [Python-Dev] New Python Initialization API

2019-03-27 Thread Alexander Belopolsky
> To make the API public, _PyWstrList, _PyInitError, _PyPreConfig, > _PyCoreConfig and related functions should be made public. Would you consider making _Py_UnixMain public as well? It is useful for high level embedding and not trivial for 3rd parties to reimplement.

[Python-Dev] New Python Initialization API

2019-03-27 Thread Victor Stinner
Hi, I would like to add a new C API to initialize Python. I would like your opinion on the whole API before making it public. The code is already implemented. Doc of the new API: https://pythondev.readthedocs.io/init_config.html To make the API public, _PyWstrList, _PyInitError, _PyPreConfig