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
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
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
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
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
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
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
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
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);
> 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
> > 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
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
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
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
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
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.
>
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
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
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
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
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
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
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
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
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
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
> 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.
27 matches
Mail list logo
