On 4 August 2018 at 08:37, Victor Stinner wrote:
> It seems like the PEP 432 proposes an API designed from scratch as the
> target API. I started from the 28 years old C code and I tried to
> cleanup the code. Our method is different, so it's not surprising that
> the result is different :-)
No,
On 3 August 2018 at 01:59, Victor Stinner wrote:
> 2018-08-02 1:18 GMT+02:00 Eric Snow :
>> The "core" config is basically the config for the runtime. In fact,
>> PEP 432 renamed "core" to "runtime". Please keep the firm distinction
>> between the runtime and the (main) interpreter.
>
> There is
On 2 August 2018 at 19:49, Victor Stinner wrote:
> About that, I'm working on a subproject: abandon Py_xxx global
> configuration variables to replace them with accessing
> interpreter->core_config->xxx. I'm not sure yet if it's a good idea or
> not, but it would allow to have two interpreters to
On 1 August 2018 at 08:14, Victor Stinner wrote:
> Hi,
>
> I finished my work on the _PyCoreConfig structure: it's a C structure
> in Include/pystate.h which has many fields used to configure Python
> initialization. In Python 3.6 and older, these parameters were scatted
> around the code, and it
It seems like the PEP 432 proposes an API designed from scratch as the
target API. I started from the 28 years old C code and I tried to
cleanup the code. Our method is different, so it's not surprising that
the result is different :-) My intent is to get:
* a function to read *all* configuration
Before I dive in, I'll say that I'd really like to hear Nick's opinion
on all this. :)
On Thu, Aug 2, 2018 at 9:59 AM Victor Stinner wrote:
> 2018-08-02 1:18 GMT+02:00 Eric Snow :
> > The "core" config is basically the config for the runtime. In fact,
> > PEP 432 renamed "core" to "runtime". Pl
2018-08-02 1:18 GMT+02:00 Eric Snow :
> The "core" config is basically the config for the runtime. In fact,
> PEP 432 renamed "core" to "runtime". Please keep the firm distinction
> between the runtime and the (main) interpreter.
There is already something called _PyRuntime but it's shared betwe
2018-08-02 17:17 GMT+02:00 Eric Snow :
> Note that there are backward compatibility issues to deal with. AFAIU
> if we start ignoring those global variables during initialization then
> it's going to cause problems for embedders.
One of the first operation of Py_Initialize(), Py_Main() and
_PyCor
On Thu, Aug 2, 2018 at 3:50 AM Victor Stinner wrote:
> I'm still doing further bug fixes and cleanup in the master branch:
> https://bugs.python.org/issue34170
>
> I'm doing more and more changes.
Yeah, it's a question of what you plan to backport. As Barry
suggested, it would be great if you ha
2018-08-02 1:18 GMT+02:00 Eric Snow :
> Backporting shouldn't be so risky since it's all private API and there
> are few other changes in the relevant code since 3.7, right? It
> depends on if Ned's okay with it or not. :)
I'm still doing further bug fixes and cleanup in the master branch:
https:
On Jul 31, 2018, at 15:14, Victor Stinner wrote:
>
> I finished my work on the _PyCoreConfig structure: it's a C structure
> in Include/pystate.h which has many fields used to configure Python
> initialization. In Python 3.6 and older, these parameters were scatted
> around the code, and it was h
On Tue, Jul 31, 2018 at 4:15 PM Victor Stinner wrote:
> I finished my work on the _PyCoreConfig structure:
\o/
Thanks for all the good work!
> Right now, the new API is still private. Nick Coghlan splitted the
> initialization in two parts: "core" and "main". I'm not sure that this
> split is n
On Tue, 31 Jul 2018 at 15:16 Victor Stinner wrote:
> Hi,
>
> I finished my work on the _PyCoreConfig structure: it's a C structure
> in Include/pystate.h which has many fields used to configure Python
> initialization. In Python 3.6 and older, these parameters were scatted
> around the code, and
13 matches
Mail list logo
