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
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.
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.
_
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
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
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.
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'
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
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
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")
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
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
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
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
14 matches
Mail list logo