Re: [Python-Dev] Confused on git commit tree about Lib/datetime.py
FWIW, it looks like this is the first (earliest) merge commit that caused the v2.7.4 line to contain cf86e368ebd17e10f68306ebad314eea31daaa1e: $ git show -q d26b658f1433a28b611906c078f47bc804a63dd1 commit d26b658f1433a28b611906c078f47bc804a63dd1 Merge: 2d639d5665 f8b9dfd9a1 Author: Georg Brandl Date: Sat Aug 11 11:08:04 2012 +0200 Graft a89d654adaa2 from 3.2 branch. Fixes #15620. --Chris On Tue, Jul 31, 2018 at 11:53 PM, Chris Angelico wrote: > On Wed, Aug 1, 2018 at 1:16 PM, Jeffrey Zhang wrote: >> I found a interesting issue when checking the Lib/datetime.py implementation >> in python3 >> >> This patch is introduced by cf86e368ebd17e10f68306ebad314eea31daaa1e [0]. >> But if you >> check the github page[0], or using git tag --contains, you will find v2.7.x >> includes this commit too. >> >> $ git tag --contains cf86e368ebd17e10f68306ebad314eea31daaa1e >> 3.2 >> v2.7.10 >> v2.7.10rc1 >> v2.7.11 >> v2.7.11rc1 >> ... >> >> whereas, if you check the v2.7.x code base, nothing is found >> >> $ git log v2.7.4 -- Lib/datetime.py >> >> >> I guess it maybe a git tool bug, or the commit tree is messed up. Is there >> any guys could explain this >> situation? > > I suppose you could say that the commit tree is "messed up", in a > sense, but it's not truly messed up, just a little odd. It's a > consequence of the way merges have been done in the CPython > repository. Nothing is actually broken, except for the ability to > track down a commit the way you're doing. > > ChrisA > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/chris.jerdonek%40gmail.com ___ 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] [PEP 576/580] Comparing PEP 576 and 580
On 2018-07-31 11:12, INADA Naoki wrote: Any PEP won't be accepted in few month, because we don't have flow to accept PEPs for now. Is that certain? I haven't been following the process discussions, so I'm just asking the question. For example, given that you are already looking at PEP 580, would it be possible for you to handle PEP 580 as official BDFL-Delegate (even if there is no BDFL)? So it's worthless that waiting PEP accepted before start PoC. First of all, it's too early for a proof-of-concept of native C calling. We first have to design the theory before we can start implementing anything. But even if we could start to write a proof of concept, I would really prefer doing that on top of PEP 580. There are two reasons for this: 1. If PEP 580 is rejected, I very much doubt that the native C calling protocol will be accepted. 2. I would be good to use PEP 580 as a framework for the implementation. Otherwise we have to implement it twice: once before PEP 580 with the proof-of-concept and then again after PEP 580 with the "real" implementation. Jeroen. ___ 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] [PEP 576/580] Comparing PEP 576 and 580
On 8/1/2018 6:17 AM, Jeroen Demeyer wrote: On 2018-07-31 11:12, INADA Naoki wrote: Any PEP won't be accepted in few month, because we don't have flow to accept PEPs for now. Is that certain? I haven't been following the process discussions, so I'm just asking the question. For example, given that you are already looking at PEP 580, would it be possible for you to handle PEP 580 as official BDFL-Delegate (even if there is no BDFL)? I think this would be a reasonable thing to discuss either here or on the committers list or both. -- Terry Jan Reedy ___ 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
[Python-Dev] test_zlib.py suggestion
I have a build_bot running (yeah me!), and was surprised to see test_zlib fail on AIX. There is not an issue with test_zlib, but I do have a suggestion. I was getting an error with test_flushes(). On python2-2.7.15 the test passes and in python3-3.8 (and earlier I expect) the test fails. The difference is the addition of the two modes 'Z_PARTIAL_FLUSH' and 'Z_BLOCK' sync_opt = ['Z_NO_FLUSH', 'Z_SYNC_FLUSH', 'Z_FULL_FLUSH', 'Z_PARTIAL_FLUSH', 'Z_BLOCK'] On default AIX installs zlib is, sadly, still at version 1.2.3 and Z_BLOCK was 'improved' in version 1.2.5. And it fails on Z_BLOCK. My suggestion is to enhance the test_library_version() so that it verifies that the minor (or smaller?) number is at least '5' When I static link python with zlib-1.2.11 then the test_zlib passes all sub-tests. Again, not a python bug - but a suggestion for improving what is tested. I can open an issue, and with a bit of assistance/interest from others I'll even do a PR. Michael ___ 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
[Python-Dev] spwd and AIX
a) I am looking at getting spwd integrated from AIX b) only the parameter sp_pwdp is my concern - as AIX really does not want to reveal the encrypted password. Rather, AIX will say '!' (meaning there is, or should be a shadow password, or '*' - no user password). Would this horribly break things if only '!' was returned, rather than the shadow password? It does not look terribly hard - but how do you deal with defaults such as 0 or -1 for the numeric values? Regards, Michael ___ 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] spwd and AIX
On 2018-08-01 13:58, Michael wrote: > a) I am looking at getting spwd integrated from AIX > > b) only the parameter sp_pwdp is my concern - as AIX really does not > want to reveal the encrypted password. Rather, AIX will say '!' (meaning > there is, or should be a shadow password, or '*' - no user password). > Would this horribly break things if only '!' was returned, rather than > the shadow password? > > It does not look terribly hard - but how do you deal with defaults such > as 0 or -1 for the numeric values? Please note that I'm planning to deprecate and remove the spwd module. The module has several limitation. Most importantly it bypasses the PAM stack. Therefore it's not compatible with password policies or other password storages like LDAP. Christian ___ 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] test_zlib.py suggestion
Open an issue as this will surely get forgotten otherwise, then people can discuss on the issue how to handle this. On Wed, 1 Aug 2018 at 08:40 Michael wrote: > I have a build_bot running (yeah me!), and was surprised to see > test_zlib fail on AIX. > > There is not an issue with test_zlib, but I do have a suggestion. > > I was getting an error with test_flushes(). On python2-2.7.15 the test > passes and in python3-3.8 (and earlier I expect) the test fails. The > difference is the addition of the two modes 'Z_PARTIAL_FLUSH' and 'Z_BLOCK' > > sync_opt = ['Z_NO_FLUSH', 'Z_SYNC_FLUSH', 'Z_FULL_FLUSH', > 'Z_PARTIAL_FLUSH', 'Z_BLOCK'] > > On default AIX installs zlib is, sadly, still at version 1.2.3 and > Z_BLOCK was 'improved' in version 1.2.5. And it fails on Z_BLOCK. > > My suggestion is to enhance the test_library_version() so that it > verifies that the minor (or smaller?) number is at least '5' > > When I static link python with zlib-1.2.11 then the test_zlib passes all > sub-tests. > > Again, not a python bug - but a suggestion for improving what is tested. > > I can open an issue, and with a bit of assistance/interest from others > I'll even do a PR. > > Michael > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ 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] [PEP 576/580] Comparing PEP 576 and 580
On Wed, 1 Aug 2018 at 07:47 Terry Reedy wrote: > On 8/1/2018 6:17 AM, Jeroen Demeyer wrote: > > On 2018-07-31 11:12, INADA Naoki wrote: > >> Any PEP won't be accepted in few month, because we don't have flow to > >> accept PEPs for now. > > > > Is that certain? I haven't been following the process discussions, so > > I'm just asking the question. For example, given that you are already > > looking at PEP 580, would it be possible for you to handle PEP 580 as > > official BDFL-Delegate (even if there is no BDFL)? > > I think this would be a reasonable thing to discuss either here or on > the committers list or both. > If there was an absolute certainty of who the BDFL delegate would be then we might be able to not wait, but without that I don't know if enough core devs will feel comfortable choosing one right now. ___ 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 _Py_InitializeFromConfig() function (PEP 432)
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 it was hard to get an exhaustive list of it. > That's great! Thanks for doing this! I know I have always found it hard to track down where stuff in the start-up process ultimately gets set. > > This work is linked to the Nick Coghlan's PEP 432 "Restructuring the > CPython startup sequence": > https://www.python.org/dev/peps/pep-0432/ > > 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 needed. We should see what to do, but it would be nice to > make the _PyCoreConfig API public! IMHO it's way better than the old > way to configuration Python initialization. > > -- > > It is now possible to only use _PyCoreConfig to initialize Python: it > overrides old ways to configure Python like environment variables (ex: > PYTHONPATH), global configuration variables (ex: Py_BytesWarningFlag) > and C functions (ex: Py_SetProgramName()). > > I added tests to test_embed on the different ways to configure Python > initialization: > > * environment variables (ex: PYTHONPATH) > * global configuration variables (ex: Py_BytesWarningFlag) and C > functions (ex: Py_SetProgramName()) > * _PyCoreConfig > > I found and fixed many issues when writing these tests :-) > > Reading the current configuration, _PyCoreConfig_Read(), no longer > changes the configuration. Now the code to read the configuration and > the code to apply the configuration is properly separated. > > The work is not fully complete, there are a few remaining corner cases > and some parameters (ex: Py_FrozenFlag) which cannot be set by > _PyCoreConfig yet. My latest issue used to work on this API: > > https://bugs.python.org/issue34170 > > I had to refactor a lot of code to implement all of that. > > -- > > The problem is that Python 3.7 got the half-baked implementation, and > it caused issues: > > * Calling Py_Main() after Py_Initialize() fails with a fatal error on > Python 3.7.0 > https://bugs.python.org/issue34008 > * PYTHONOPTIMIZE environment variable is ignored by Py_Initialize() >https://bugs.python.org/issue34247 > > I fixed the first issue, I'm now working on the second one to see how > it can be fixed. Other option would be to backport the code from > master to the 3.7 branch, since the code in master has a way better > design. But it requires to backport a lot of changes. I'm not sure yet > what is the best option. > If it is not extremely painful to fix just the issue then I say don't backport the whole thing. ___ 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
[Python-Dev] Using Cython for the stdlib (was: Let's change to C API!)
[new thread as this no longer has anything to do with Victor's proposal] On Tue, 31 Jul 2018 at 13:42 Stefan Behnel wrote: > Antoine Pitrou schrieb am 31.07.2018 um 09:45: > > On Tue, 31 Jul 2018 09:27:03 +0200 > > Jeroen Demeyer wrote: > >> On 2018-07-31 08:58, Antoine Pitrou wrote: > >>> I think Stefan is right that we > >>> should push people towards Cython and alternatives, rather than direct > >>> use of the C API (which people often fail to use correctly, in my > >>> experience). > >> > >> I know this probably isn't the correct place to bring it up, but I'm > >> sure that CPython itself could benefit from using Cython. For example, > >> most of the C extensions in Modules/ could be written in Cython. > > > > We don't depend on any third-party Python modules. Adding a Cython > > dependency for CPython development would be a tough sell. > > I don't really want to get into that discussion (it's more about processes > than arguments), but let me note that the CPython development already has a > couple of dependencies, such as github and its bots, or tools like argument > clinic (admittedly included), make and a C compiler (not included), and a > text editor. It's not like it's free of tools that help in writing and > maintaining the code. That's pretty much the level at which I also see > Cython. It's more complex than argument clinic, but it otherwise serves a > similar need. > You're right that since Cython generates C code that we could check in like we do all of our other generated code we could view Cython as another external tool we rely on for maintaining the code base. > > > > Also, a C extension can be built-in (linked statically into the > > interpreter), which I think would be hard to do with Cython. > > Someone recently contributed a feature of hiding the pyinit function for > the embedding case, so people do these things already. This could use the > normal inittab mechanism, for example. What I think you might be referring > to is that Cython modules require the CPython runtime to be initialised to > a certain extent, so you couldn't implement "sys" in Cython, for example. > I think the key thing is that on Windows all extension modules are built-in modules, so that use-case would need to be supported (I don't know Cython well enough to know whether this would be doable if we converted as much as possible to Cython itself). > But Jeroen is right, Cython should be a viable option for (most of?) the > extension modules in the stdlib. Whether the CPython core devs would accept > it in their workflow or not is a totally different question. > I think it's definitely something to consider, although I think Victor's proposal to clean up the C API so we have a clearly delineated private API, a version-specific API, and a stable ABI is a separate idea and so this should be its own thread (plus Victor's is easier to accomplish in the short-term ;) . ___ 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] [PEP 576/580] Comparing PEP 576 and 580
On Wed, 1 Aug 2018 09:05:52 -0700 Brett Cannon wrote: > On Wed, 1 Aug 2018 at 07:47 Terry Reedy wrote: > > > On 8/1/2018 6:17 AM, Jeroen Demeyer wrote: > > > On 2018-07-31 11:12, INADA Naoki wrote: > > >> Any PEP won't be accepted in few month, because we don't have flow to > > >> accept PEPs for now. > > > > > > Is that certain? I haven't been following the process discussions, so > > > I'm just asking the question. For example, given that you are already > > > looking at PEP 580, would it be possible for you to handle PEP 580 as > > > official BDFL-Delegate (even if there is no BDFL)? > > > > I think this would be a reasonable thing to discuss either here or on > > the committers list or both. > > > > If there was an absolute certainty of who the BDFL delegate would be then > we might be able to not wait, but without that I don't know if enough core > devs will feel comfortable choosing one right now. We could proceed by consensus: the PEP author publicly proposes a PEP delegate, and if no core developer opposes, that person is officially accepted as delegate. Often PEP authors have a pretty good idea of who can be a delegate for a PEP. This is especially true on specialized topics which only a couple core devs are interested in discussing actively. Regards Antoine. ___ 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] Using Cython for the stdlib (was: Let's change to CAPI!)
I don’t think there would be any trouble linking in the generated C files. The built in modules like this just have their *_init() functions called at startup, so possibly nothing would even change. Top-posted from my Windows 10 phone From: Brett Cannon Sent: Wednesday, 1 August 2018 17:20 To: Stefan Behnel Cc: [email protected] Subject: [Python-Dev] Using Cython for the stdlib (was: Let's change to CAPI!) [new thread as this no longer has anything to do with Victor's proposal] On Tue, 31 Jul 2018 at 13:42 Stefan Behnel wrote: Antoine Pitrou schrieb am 31.07.2018 um 09:45: > On Tue, 31 Jul 2018 09:27:03 +0200 > Jeroen Demeyer wrote: >> On 2018-07-31 08:58, Antoine Pitrou wrote: >>> I think Stefan is right that we >>> should push people towards Cython and alternatives, rather than direct >>> use of the C API (which people often fail to use correctly, in my >>> experience). >> >> I know this probably isn't the correct place to bring it up, but I'm >> sure that CPython itself could benefit from using Cython. For example, >> most of the C extensions in Modules/ could be written in Cython. > > We don't depend on any third-party Python modules. Adding a Cython > dependency for CPython development would be a tough sell. I don't really want to get into that discussion (it's more about processes than arguments), but let me note that the CPython development already has a couple of dependencies, such as github and its bots, or tools like argument clinic (admittedly included), make and a C compiler (not included), and a text editor. It's not like it's free of tools that help in writing and maintaining the code. That's pretty much the level at which I also see Cython. It's more complex than argument clinic, but it otherwise serves a similar need. You're right that since Cython generates C code that we could check in like we do all of our other generated code we could view Cython as another external tool we rely on for maintaining the code base. > Also, a C extension can be built-in (linked statically into the > interpreter), which I think would be hard to do with Cython. Someone recently contributed a feature of hiding the pyinit function for the embedding case, so people do these things already. This could use the normal inittab mechanism, for example. What I think you might be referring to is that Cython modules require the CPython runtime to be initialised to a certain extent, so you couldn't implement "sys" in Cython, for example. I think the key thing is that on Windows all extension modules are built-in modules, so that use-case would need to be supported (I don't know Cython well enough to know whether this would be doable if we converted as much as possible to Cython itself). But Jeroen is right, Cython should be a viable option for (most of?) the extension modules in the stdlib. Whether the CPython core devs would accept it in their workflow or not is a totally different question. I think it's definitely something to consider, although I think Victor's proposal to clean up the C API so we have a clearly delineated private API, a version-specific API, and a stable ABI is a separate idea and so this should be its own thread (plus Victor's is easier to accomplish in the short-term ;) . ___ 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] Using Cython for the stdlib (was: Let's change to C API!)
Brett Cannon schrieb am 01.08.2018 um 18:17: > On Tue, 31 Jul 2018 at 13:42 Stefan Behnel wrote: >> Antoine Pitrou schrieb am 31.07.2018 um 09:45: >>> Also, a C extension can be built-in (linked statically into the >>> interpreter), which I think would be hard to do with Cython. >> >> Someone recently contributed a feature of hiding the pyinit function for >> the embedding case, so people do these things already. This could use the >> normal inittab mechanism, for example. What I think you might be referring >> to is that Cython modules require the CPython runtime to be initialised to >> a certain extent, so you couldn't implement "sys" in Cython, for example. > > I think the key thing is that on Windows all extension modules are built-in > modules, so that use-case would need to be supported (I don't know Cython > well enough to know whether this would be doable if we converted as much as > possible to Cython itself). As Steve noted, this is probably easy. What Cython produces is just the C code file for an extension module. Whether you turn that into a shared library or statically link it into something else (that knows how to initialise an extension module) is up to you. I would say, from the point on where CPython is ready to initialise its own extension modules, it can also initialise Cython generated modules. So, just to give an example, if you want to compile difflib.py into an accelerator module and link that into the core, that's probably fine, as long as you first initialise everything that difflib needs in its module init code (such as importlib to execute the module level imports) before you initialise the compiled difflib module. Stefan ___ 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] Error message for wrong number of arguments
Hi, On 30 July 2018 at 22:19, Chris Barker via Python-Dev wrote: > Oh well. This is a serious usability issue -- but what can you do? I think that argument clinic knows if the built-in function is supposed to be a method or a function. It doesn't look too hard to add a new flag METH_IS_METHOD or something, which would be taken in consideration in the common cases, and which can be added manually OR used automatically by argument clinic. This would not be a 100% solution out of the box, but if the new wording is right, it shouldn't be a problem. A bientôt, Armin. ___ 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] spwd and AIX
Sounds like i can skip this then. Thx. Sent from my iPhone > On 1 Aug 2018, at 17:52, Christian Heimes wrote: > >> On 2018-08-01 13:58, Michael wrote: >> a) I am looking at getting spwd integrated from AIX >> >> b) only the parameter sp_pwdp is my concern - as AIX really does not >> want to reveal the encrypted password. Rather, AIX will say '!' (meaning >> there is, or should be a shadow password, or '*' - no user password). >> Would this horribly break things if only '!' was returned, rather than >> the shadow password? >> >> It does not look terribly hard - but how do you deal with defaults such >> as 0 or -1 for the numeric values? > > Please note that I'm planning to deprecate and remove the spwd module. > The module has several limitation. Most importantly it bypasses the PAM > stack. Therefore it's not compatible with password policies or other > password storages like LDAP. > > Christian > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/aixtools%40felt.demon.nl ___ 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 _Py_InitializeFromConfig() function (PEP 432)
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 needed. 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. > We should see what to do, but it would be nice to > make the _PyCoreConfig API public! IMHO it's way better than the old > way to configuration Python initialization. +1 However, shouldn't that happen after PEP 432 is accepted? > [snip] > > The problem is that Python 3.7 got the half-baked implementation, and > it caused issues: > > * Calling Py_Main() after Py_Initialize() fails with a fatal error on > Python 3.7.0 > https://bugs.python.org/issue34008 > * PYTHONOPTIMIZE environment variable is ignored by Py_Initialize() >https://bugs.python.org/issue34247 > > I fixed the first issue, I'm now working on the second one to see how > it can be fixed. Other option would be to backport the code from > master to the 3.7 branch, since the code in master has a way better > design. But it requires to backport a lot of changes. I'm not sure yet > what is the best option. 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. :) -eric ___ 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 _Py_InitializeFromConfig() function (PEP 432)
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 hard to get an exhaustive list of it. Great work Victor! +1 for making _PyCoreConfig public, although I’m sure you’re only proposing that for Python 3.8, not in any future backport. > I had to refactor a lot of code to implement all of that. > > The problem is that Python 3.7 got the half-baked implementation, and > it caused issues: > > * Calling Py_Main() after Py_Initialize() fails with a fatal error on > Python 3.7.0 > https://bugs.python.org/issue34008 > * PYTHONOPTIMIZE environment variable is ignored by Py_Initialize() > https://bugs.python.org/issue34247 > > I fixed the first issue, I'm now working on the second one to see how > it can be fixed. Other option would be to backport the code from > master to the 3.7 branch, since the code in master has a way better > design. But it requires to backport a lot of changes. I'm not sure yet > what is the best option. Do you have WIP branch for the backport? I agree that it’s probably low enough risk given the private nature of the API in 3.7, but that it’s up to Ned to decide. -Barry signature.asc Description: Message signed with OpenPGP ___ 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
