I don't like adding more Python callback from low level.
Python runtime is very complicated already, especially __del__,
shutdown process, and multi threading. Python callback from low level
is source of very difficult bugs always.
Additionally, if we used the PEP for logging complex
On 29Mar.2019 1939, Cameron Simpson wrote:
> Can you get a branch into your pipeline? Then you could just hack the
> tarfile test with something quick and dirty like:
>
> pid = os.getpid()
> system("strace -p %d 2>/path/to/strace.out &" % pid)
> time.sleep(2) # get strace heaps of time
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.
>
On 29Mar2019 19:30, Steve Dower wrote:
On 29Mar.2019 1731, Nathaniel Smith wrote:
That does sound strange.
Oh good, it's not just me :)
How easily can you reproduce it? That majorly
effects how I would try to debug something like this...
No idea. Looking at the builds on Pipelines again,
On 29Mar.2019 1731, Nathaniel Smith wrote:
> That does sound strange.
Oh good, it's not just me :)
> How easily can you reproduce it? That majorly
> effects how I would try to debug something like this...
No idea. Looking at the builds on Pipelines again, it seems that all the
builds since
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
That does sound strange. How easily can you reproduce it? That majorly
effects how I would try to debug something like this...
If you're able to get an strace of a failed run then that would probably
tell us a *lot*.
On Fri, Mar 29, 2019, 16:28 Steve Dower wrote:
> Hi
>
> I'm trying to track
Hi
I'm trying to track down the cause of the failed Linux tests on this
build (it's also been happening on random PR builds for the last day or
two, but this is the first I've seen it happen on already merged code):
https://dev.azure.com/Python/cpython/_build/results?buildId=40189
One of
On 29Mar2019 1218, Christian Heimes wrote:
On 28/03/2019 23.35, Steve Dower wrote:
The ``importlib.util.open_for_import()`` function is a drop-in
replacement for ``open(str(pathlike), 'rb')``. Its default behaviour is
to open a file for raw, binary access. To change the behaviour a new
handler
On 28/03/2019 23.35, 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 Steering Council.
>
> The formatted text is at https://www.python.org/dev/peps/pep-0578/
On Thu, Mar 28, 2019 at 5:03 PM Victor Stinner wrote:
> Hi,
>
> I read quickly the PEP
>
I would like to encourage everyone to read PEPs so that they never feel the
need to write those words ever again. ;)
PEPs are never decided in less than 24 hours, so there is no rush to read a
PEP as
PEP 551 (referenced from this one) contains information about using
these hooks for security purposes, along with other approaches to
minimize the risk of having Python in your production environments.
Threat models have to be designed by the user; we can't predict what it
looks like for the
ACTIVITY SUMMARY (2019-03-22 - 2019-03-29)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7048 ( -3)
closed 41176 (+76)
total 48224 (+73)
Open issues
Like in the mktemp thread earlier, I would request a threat model (what use cases are supposed to be protected (in this case, by reporting
rather than preventing) and from what threats) -- in the discussion, and eventually, in the PEP.
Without one, any claims and talks about whether something
Thanks Christian for responding - I endorse and support all your
comments. (I'd hoped that by explicitly saying "this is not a sandbox"
it would avoid people thinking it was a sandbox, but apparently I would
have been better just to avoid the keyword completely...)
On 29Mar2019 0324,
On 29Mar2019 0334, Christian Heimes wrote:
On 28/03/2019 23.35, Steve Dower wrote:
Audit Hook
--
In order to observe actions taken by the runtime (on behalf of the
caller), an API is required to raise messages from within certain
operations. These operations are typically deep within
On Thu, Mar 28, 2019 at 11:28 PM Jeroen Demeyer wrote:
> On 2019-03-29 04:08, Stephen J. Turnbull wrote:
> > In this case, it's here:
> >
> > >
> https://discuss.python.org/t/pep-570-Python-Positional-Only-Parameters/1078
>
> So, are we supposed to discuss PEPs on discuss.python.org now?
On 28/03/2019 23.35, Steve Dower wrote:
> Audit Hook
> --
>
> In order to observe actions taken by the runtime (on behalf of the
> caller), an API is required to raise messages from within certain
> operations. These operations are typically deep within the Python
> runtime or standard
On 29/03/2019 01.02, Victor Stinner wrote:
> 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
>>
On 2019-03-29 04:08, Stephen J. Turnbull wrote:
In this case, it's here:
> https://discuss.python.org/t/pep-570-Python-Positional-Only-Parameters/1078
So, are we supposed to discuss PEPs on discuss.python.org now? That's
fine for me, should I create a thread like that for PEP 580 too?
20 matches
Mail list logo
