Re: [Python-Dev] PEP 451 update

2013-10-31 Thread Nick Coghlan
On 1 Nov 2013 01:37, "PJ Eby" wrote: . ;-) > > I also suspect, that if properly spelled out, those use cases are > going to boil down to: > > 1. Throwing errors if you have an existing module object you can't > load into, and > 2. Passing in a previous spec object, if available > > In other words

Re: [Python-Dev] Compiler security

2013-10-31 Thread Terry Reedy
On 10/31/2013 10:57 AM, Christian Heimes wrote: I didnt' see this at first: STACK was run against a number of systems written in C/C++ and it found 160 new bugs in the systems tested, including ... and Python (5). Has anybody contact us? I neither saw a bug report nor a mail to PSRT.

Re: [Python-Dev] Compiler security

2013-10-31 Thread Serhiy Storchaka
31.10.13 16:56, Benjamin Peterson написав(ла): I believe the 5 problems they found in Python were dealt with here http://bugs.python.org/issue17016 Ah, now I have remembered author's name. http://bugs.python.org/issue18684 contains some other fixes of this kind. _

Re: [Python-Dev] PEP 451 update

2013-10-31 Thread PJ Eby
On Thu, Oct 31, 2013 at 5:52 AM, Nick Coghlan wrote: > > On 31 Oct 2013 18:52, "Eric Snow" wrote: >> >> On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan wrote: >> > There's also the option of implementing the constraint directly in the >> > finder, which *does* have the necessary info (with the ch

Re: [Python-Dev] Compiler security

2013-10-31 Thread Christian Heimes
Am 31.10.2013 15:48, schrieb MRAB: > Has anybody here heard about this, and, if so, is it anything we should > be thinking about: > > How your compiler may be compromising application security > http://www.itworld.com/security/380406/how-your-compiler-may-be-compromising-application-security > I

Re: [Python-Dev] Compiler security

2013-10-31 Thread Benjamin Peterson
I believe the 5 problems they found in Python were dealt with here http://bugs.python.org/issue17016 2013/10/31 MRAB : > Has anybody here heard about this, and, if so, is it anything we should > be thinking about: > > How your compiler may be compromising application security > http://www.itworld.

Re: [Python-Dev] Compiler security

2013-10-31 Thread Guido van Rossum
Interesting read. I'm surprised that the researchers didn't contact us, since the article mentions they found 5 bugs in Python. Regarding security: the article seems to use that term mostly to attract eyeballs; there are no specifics, just the implication that this *could* affect security. But it'

Re: [Python-Dev] Compiler security

2013-10-31 Thread Christian Heimes
Am 31.10.2013 15:48, schrieb MRAB: > Has anybody here heard about this, and, if so, is it anything we should > be thinking about: > > How your compiler may be compromising application security > http://www.itworld.com/security/380406/how-your-compiler-may-be-compromising-application-security http

[Python-Dev] Compiler security

2013-10-31 Thread MRAB
Has anybody here heard about this, and, if so, is it anything we should be thinking about: How your compiler may be compromising application security http://www.itworld.com/security/380406/how-your-compiler-may-be-compromising-application-security ___ P

Re: [Python-Dev] PEP 454 (tracemalloc) disable ==> clear?

2013-10-31 Thread Ethan Furman
On 10/31/2013 05:20 AM, Victor Stinner wrote: I did another experiment. I replaced enable/disable/is_enabled with start/stop/is_tracing, and added enable/disable/is_enabled functions to disable temporarily tracing. API: - clear_traces(): clear traces - start(): start tracing (the old "enable")

Re: [Python-Dev] PEP 454 (tracemalloc) disable ==> clear?

2013-10-31 Thread Victor Stinner
2013/10/31 Victor Stinner : > If I give access to this flag, it would be possible to disable > temporarily tracing in the current thread, but tracing would still be > enabled in other threads. Would it fit your requirement? It's probably not what you are looking for :-) As I wrote in the PEP, the

Re: [Python-Dev] PEP 454 (tracemalloc) disable ==> clear?

2013-10-31 Thread Victor Stinner
2013/10/29 Victor Stinner : > 2013/10/29 Kristján Valur Jónsson : >> I was thinking something similar. It would be useful to be able to "pause" >> and "resume" >> if one is doing any analysis work in the live environment. This would >> reduce the >> need to have "Filter" objects. > > Internally

Re: [Python-Dev] PEP 451 update

2013-10-31 Thread Nick Coghlan
On 31 Oct 2013 18:52, "Eric Snow" wrote: > > On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan wrote: > > There's also the option of implementing the constraint directly in the > > finder, which *does* have the necessary info (with the change to pass the > > previous spec to find_spec). > > Yeah, I

Re: [Python-Dev] PEP 451 update

2013-10-31 Thread Eric Snow
On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan wrote: > There's also the option of implementing the constraint directly in the > finder, which *does* have the necessary info (with the change to pass the > previous spec to find_spec). Yeah, I thought of that. I just prefer the more explicit suppo