Re: [Python-Dev] A request for PEP announcement format [was: PEP 570]

2019-03-28 Thread Jonathan Goble
On Thu, Mar 28, 2019 at 11:11 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > > https://discuss.python.org/t/pep-570-Python-Positional-Only-Parameters/1078 > > (sorry, case changed for emphasis so clicking won't work) > Clicking actually did work for me. Not only is

[Python-Dev] A request for PEP announcement format [was: PEP 570]

2019-03-28 Thread Stephen J. Turnbull
A proponent writes: > We have submitted PEP 570 for consideration to the steering > council: I would like to ask *future* proponents to please include the title explicitly in the first mention. (This is not a criticism of the previous post. How could he know I would write this?) In this

Re: [Python-Dev] PEP 578: Python Runtime Audit Hooks

2019-03-28 Thread Victor Stinner
Hi, I read quickly the PEP, I'm not sure that I understood it correctly, so here are some early questions more about the usage of the PEP, than its implementation. > This is not sandboxing, as this proposal does not attempt to prevent > malicious behavior (though it enables some new options to

Re: [Python-Dev] PEP 578: Python Runtime Audit Hooks

2019-03-28 Thread Steve Dower
The implementation can be viewed as a PR at https://github.com/python/cpython/pull/12613 On 28Mar2019 1535, Steve Dower wrote: Hi all Time is short, but I'm hoping to get PEP 578 (formerly PEP 551) into Python 3.8. Here's the current text for review and comment before I submit to the

[Python-Dev] PEP 578: Python Runtime Audit Hooks

2019-03-28 Thread Steve Dower
Hi all Time is short, but I'm hoping to get PEP 578 (formerly PEP 551) into Python 3.8. Here's the current text for review and comment before I submit to the Steering Council. The formatted text is at https://www.python.org/dev/peps/pep-0578/ (update just pushed, so give it an hour or so,

Re: [Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc

2019-03-28 Thread Neil Schemenauer
On 2019-03-28, Antoine Pitrou wrote: > On Wed, 27 Mar 2019 15:59:25 -0700 > "Gregory P. Smith" wrote: > > > > That had a C++ stack trace 1000+ levels deep repeating the pattern of > > > > ... > > @ 0x564d59bd21de 32 func_dealloc > > @ 0x564d59bce0c1 32

[Python-Dev] VxWorks and Python

2019-03-28 Thread Kuhl, Brian
Hi Python developers, Victor suggested I post a little background to help the maintainers understand VxWorks a little better. It can be found here https://github.com/Wind-River/cpython/wiki/Python-on-VxWorks If you'd like more detail in a particular area, please feel free to reply on or off

[Python-Dev] PEP 570

2019-03-28 Thread Pablo Galindo Salgado
Hi everyone, We have submitted PEP 570 for consideration to the steering council: https://github.com/python/steering-council/issues/4 The discussion is happening on discourse: https://discuss.python.org/t/pep-570-python-positional-only-parameters/1078 To eliminate splitting the discussion

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

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

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

Re: [Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc

2019-03-28 Thread Jeroen Demeyer
On 2019-03-28 01:38, Tim Peters wrote: The bad news is that the traschcan mechanism is excruciating, a long-time source of subtle bugs of its own :-( It just happens that I created a PR to fix some of the trashcan problems: see https://bugs.python.org/issue35983 and

Re: [Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc

2019-03-28 Thread Antoine Pitrou
On Wed, 27 Mar 2019 15:59:25 -0700 "Gregory P. Smith" wrote: > > That had a C++ stack trace 1000+ levels deep repeating the pattern of > > ... > @ 0x564d59bd21de 32 func_dealloc > @ 0x564d59bce0c1 32 cell_dealloc > @ 0x564d5839db41 48

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

Re: [Python-Dev] PEP 556 threaded garbage collection & linear recursion in gc

2019-03-28 Thread Tim Peters
[Gregory P. Smith ] > Good point, I hadn't considered that it was regular common ref > count 0 dealloc chaining. It pretty much has to be whenever you see a chain of XXX_dealloc routines in a stack trace. gcmodule.c never even looks at a tp_dealloc slot directly, let alone directly invoke a