Re: [Python-Dev] [PEP 576/580] Comparing PEP 576 and 580
Antoine Pitrou writes: > 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. I think this is too decentralized. I think there should be enthusiasm for the delegate, say two "seconds" (with discussion of why they think the delegate is appropriate) besides the PEP proponent(s). > 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. I agree that this is an important point. I think you (disclaimer: I'm a social scientist, but not a committer) should be careful that delegates be broadly respected, and where possible have interests in other areas of Python development besides the one they're delegate for. ___ 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)
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://bugs.python.org/issue34170 I'm doing more and more changes. I just added two new files: Include/coreconfig.h and Python/coreconfig.h. IMHO it's better to put similar code in separated files. FYI Python/coreconfig.c has 954 files and Include/coreconfig.h has 319 lines. I'm ok to rename the structure and the files if you prefer a different name. 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 have their own different configuration. Imagine two interpreters with different sys.path running in isolated mode. Or maybe an interpreter without importlib? One of the issue is that we have now two copies of the same option. For example, Py_BytesWarningFlag and interpreter->core_config->bytes_warning. That's why I would like to switch to core_config. But I'm also trying to make sure that the two variables have the same value: https://github.com/python/cpython/commit/a4d20b2e5ece2120f129cb4dda951a6c2461e92d Victor ___ 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
On 01/08/2018 18:03, Brett Cannon wrote: Open an issue as this will surely get forgotten otherwise, then people can discuss on the issue how to handle this. Will do. I have more homework - as I just tested AIX 7.1 TL5 as a build system. The good news is libz.a is finally updated to something newer. The bad news is they introduced libreadline-6, with no support, and that it seems it going to be difficult to get it to link. I so wish they would include "include files" with these standard libraries. Not doing so is one of the reasons things break - either double files, overwriting files and/or mixed versions. Sigh. 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
[Python-Dev] [RELEASED] Python 3.4.9 and Python 3.5.6 are now available
On behalf of the Python development community, I'm happy to announce the availability of Python 3.4.9 and Python 3.5.6. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You can find Python 3.4.9 here: https://www.python.org/downloads/release/python-349/ And you can find Python 3.5.6 here: https://www.python.org/downloads/release/python-356/ We now return you to your pitched debate already in progress, //arry/ ___ 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] [python-committers] [RELEASED] Python 3.4.9 and Python 3.5.6 are now available
Hi, 2018-08-02 16:00 GMT+02:00 Larry Hastings : > On behalf of the Python development community, I'm happy to announce the > availability of Python 3.4.9 and Python 3.5.6. Great! FYI these versions fix two security vulnerabilities: (*) CVE-2018-1000117: Buffer overflow vulnerability in os.symlink on Windows http://python-security.readthedocs.io/vuln/cve-2018-1000117_buffer_overflow_vulnerability_in_os.symlink_on_windows.html (*) CVE-2018-1060: difflib and poplib catastrophic backtracking http://python-security.readthedocs.io/vuln/cve-2018-1060_difflib_and_poplib_catastrophic_backtracking.html 3.4.9 and 3.5.6 have no more known security vulnerabilities :-) Victor ___ 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 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 had a WIP PR for the backport, just so Ned (and others) has a point of reference. > I just added two new files: > Include/coreconfig.h and Python/coreconfig.h. IMHO it's better to put > similar code in separated files. > > FYI Python/coreconfig.c has 954 files and Include/coreconfig.h has 319 lines. Nick might have a better opinion, particularly when in comes to a C codebase, but I'm in favor of keeping separate things separate, and especially when in relates to the runtime. (Historically we haven't been great about considering the runtime as a distinct part of CPython.) Hence +1 to keeping the runtime config separate, especially given the size of the files. :) Presumably pystate.c (and pystate.h) got smaller by roughly the same amount? Also, would it make sense for at least some of coreconfig.h to live in Include/internal, either as coreconfig.h or in the internal pystate.h? > I'm ok to rename the structure and the files if you prefer a different name. I'd love to see all the "core" names changed to "runtime", in the same way that PEP 432 was updated. It was a point of confusion in the PEP until we changed the name, and doing so helped. I thought we had also changed the code, but apparently not. For that matter, I'd love to see PEP 432 and the codebase synced up. While the overall plan is still consistent, a number of details (e.g. the intent and content of the "core" config) have diverged. > About that, I'm working on a subproject: abandon Py_xxx global > configuration variables to replace them with accessing > interpreter->core_config->xxx. +1 IMHO it's a natural consequence of having a runtime/core config. In fact, having both is problematic because it's easy for us to accidentally ignore a global-var-as-config (prior to Py_Initialize); the relationship between those global variables and runtime initialization isn't very obvious in the code (unlike the config struct). It's also confusing for embedders if we have both. As I've already expressed, I'm definitely in favor of improving encapsulation of the runtime (and moving away from globals). :) 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. If we get rid of the variables altogether then it would break extension modules that currently rely on reading those parts of the runtime config. So I'm guessing you planned on deprecating any use of those global variables and, in the spirit of your goals for the C-API, provide a public API for extensions to access the info in the runtime config instead. FWIW, I recall that Nick and I discussed this relative to PEP 432 a while ago and remember the decision to stay with the status quo for now (to avoid scope creep in the PEP). Apparently that consideration did not get recorded in the PEP (that I could see with a quick skim of the text). The mailing lists may have the discussion somewhere. > I'm not sure yet if it's a good idea or > not, but it would allow to have two interpreters to have their own > different configuration. Imagine two interpreters with different > sys.path running in isolated mode. Or maybe an interpreter without > importlib? Yeah, a number of interesting possibilities open up as we further encapsulate the runtime and move away from globals. > One of the issue is that we have now two copies of the same option. > For example, Py_BytesWarningFlag and > interpreter->core_config->bytes_warning. That's why I would like to > switch to core_config. +1 > But I'm also trying to make sure that the two variables have the same value: > https://github.com/python/cpython/commit/a4d20b2e5ece2120f129cb4dda951a6c2461e92d Yep. That is necessary while the global config variables still exist. It's just risky since it's easy for us to change the config but forget to update the global config vars (that are shadowing the config). It would probably be worth making sure we have tests that verify that the two stay synchronized. -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)
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 _PyCoreConfig_Read() is to get the current value of all global configuration variables. The change is more that modifying a global configuration variable after Py_Initialize() or Py_Main() may or may not have an effect. And in the future, it should no longer have effect. In short, these variables should only be read to populate the initialization configuration and then it should no longer change. > So I'm guessing you planned on deprecating any use of those global variables > and, in the spirit of your goals for the C-API, provide a public API > for extensions to access the info in the runtime config instead. There is no *need* to deprecate anything. _PyCoreConfig remains fully compatible with them and there are now unit tests to make sure that their value is read at Python startup. The priority is: core config > global vars > env vars. >> But I'm also trying to make sure that the two variables have the same value: >> https://github.com/python/cpython/commit/a4d20b2e5ece2120f129cb4dda951a6c2461e92d > > Yep. That is necessary while the global config variables still exist. > It's just risky since it's easy for us to change the config but forget > to update the global config vars (that are shadowing the config). It > would probably be worth making sure we have tests that verify that the > two stay synchronized. If possible, I would prefer that the configuration is *not* modified after Python has been initialized. I even hesitate to mark PyInterpreterState.core_config a constant to prevent such change. The idea would be to know exactly how Python has been initialize, to make the initialization more deterministic and explicit. To come back to a concrete example: https://github.com/python/cpython/commit/a4d20b2e5ece2120f129cb4dda951a6c2461e92d We can easily modify core_config->inspect before Python initialization. For this commit, it's just that I wanted to make tiny and incremental changes. Victor ___ 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)
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 between all interpreters. _PyCoreConfig is already *per* interpreter. Would you mind to elaborate what you mean by the "main interpreter"? I don't see anything obvious in the current code about what is a "main interpreter". Technically, I don't see anything like that. I'm still not convinced that we need _PyMainInterpreterConfig: _PyCoreConfig contains the same information. Is it really worth it to duplicate all _PyCoreConfig (more than 36 fields) in _PyMainInterpreterConfig? _PyMainInterpreterConfig adds a third copy of many paramters: another opportunity to introduce an inconsistency. Right now, an interpreter contains both: core and main configurations... I propose to *remove* _PyMainInterpreterConfig and rename _PyCoreConfig as _PyInterpreterConfig. I would also propose to merge again Py_Initialize() to have a single step instead of the current core step + main step: 2 steps. Victor ___ 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
On Wed, Aug 1, 2018 at 2:40 PM, Armin Rigo wrote: > 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. > But can you do the same thing with pure-python methods? After all, this thread started with trying ot unify what error folks get regardless of how the method was written. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ 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] [python-committers] [RELEASED] Python 3.4.9 and Python 3.5.6 are now available
On 08/02/2018 07:17 AM, Victor Stinner wrote: 3.4.9 and 3.5.6 have no more known security vulnerabilities :-) Well, not to be a complete pill, but... https://bugs.python.org/issue17180 https://bugs.python.org/issue17239 https://bugs.python.org/issue19050 Sadly, just because they're languishing on bpo doesn't mean they aren't valid security vulnerabilities. //arry/ ___ 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
