On 09/03/2012 20:44, Thomas Wouters wrote:
(...) it would be nice to still
run the tests that can be run without _testcapi. Any objections to
fixing the tests to use test.support.import_module() for _testcapi and a
'needs_testcapi' skipping decorator?
test.support.import_module() looks fine fo
On Fri, Mar 09, 2012 at 05:38:05PM -0500, Yury Selivanov wrote:
> Actually, I too noticed that you've dropped few crasher tests. I think
> we need to keep them, to make sure that future development will not
> introduce the same vulnerabilities. That's a common practice with
> unit-testing.
The
2012/3/9 Thomas Wouters :
>
> While testing Python 2.7 internally (at Google) I noticed that (now that
> ImportErrors aren't automatically test skips) lots of tests fail if you
> don't have the _testcapi module. These tests are (as far as I've seen)
> properly marked as cpython-only, but when some
On Fri, Mar 9, 2012 at 14:44, Thomas Wouters wrote:
>
> While testing Python 2.7 internally (at Google) I noticed that (now that
> ImportErrors aren't automatically test skips) lots of tests fail if you
> don't have the _testcapi module. These tests are (as far as I've seen)
> properly marked as
Victor Stinner wrote:
On 09/03/2012 22:32, Jim Jewett wrote:
I do not believe the change set below is valid.
As I read it, the new test verifies that one particular type of Nasty
key will provoke a RuntimeError -- but that particular type already
did so, by hitting the recursion limit. (It doe
Actually, I too noticed that you've dropped few crasher tests. I think
we need to keep them, to make sure that future development will not
introduce the same vulnerabilities. That's a common practice with
unit-testing.
On 2012-03-09, at 5:27 PM, Victor Stinner wrote:
> On 09/03/2012 22:32, Jim
On 09/03/2012 22:32, Jim Jewett wrote:
I do not believe the change set below is valid.
As I read it, the new test verifies that one particular type of Nasty
key will provoke a RuntimeError -- but that particular type already
did so, by hitting the recursion limit. (It doesn't even really
mutate
I do not believe the change set below is valid.
As I read it, the new test verifies that one particular type of Nasty
key will provoke a RuntimeError -- but that particular type already
did so, by hitting the recursion limit. (It doesn't even really
mutate the dict.)
Meanwhile, the patch throws
Antoine Pitrou, 08.03.2012 21:36:
> On Thu, 8 Mar 2012 14:36:06 -0600
> Benjamin Peterson wrote:
>> 2012/3/8 Stefan Behnel:
>>> Would that be acceptable for CPython as well or would you prefer full
>>> fledged normalisation?
>>
>> I think we have to normalize for correctness. Consider that it may b
While testing Python 2.7 internally (at Google) I noticed that (now that
ImportErrors aren't automatically test skips) lots of tests fail if you
don't have the _testcapi module. These tests are (as far as I've seen)
properly marked as cpython-only, but when some wacko decides the _testcapi
module s
ACTIVITY SUMMARY (2012-03-02 - 2012-03-09)
Python tracker at http://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:
open3318 (+19)
closed 22704 (+44)
total 26022 (+63)
Open issues wit
On 09/03/2012 12:57, Mark Shannon wrote:
No. But it won't be slower.
Cheers,
Mark
Please prove it, you have to convince a number of core developers
including, but not limited to, the BDFL :).
--
Cheers.
Mark Lawrence.
___
Python-Dev mailing lis
Victor Stinner wrote:
The reason I am proposing this here rather than on python-ideas is that
treating the triple of [locals, globals, builtins] as a single
"execution context" can be implemented in a really nice way.
Internally, the execution context of [locals, globals, builtins]
can be treate
> The reason I am proposing this here rather than on python-ideas is that
> treating the triple of [locals, globals, builtins] as a single
> "execution context" can be implemented in a really nice way.
>
> Internally, the execution context of [locals, globals, builtins]
> can be treated a single im
If you use your own comparaison function (__eq__) for objects used as
dict keys, you may now get RuntimeError with Python 3.3 if the dict is
modified during a dict lookup in a multithreaded application. You
should use a lock on the dict to avoid this exception.
Said differently, a dict lookup is n
Nick Coghlan wrote:
On Fri, Mar 9, 2012 at 6:19 PM, Mark Shannon wrote:
The Python API would be changed, but in a backwards compatible way.
exec, eval and __import__ would all gain an optional (keyword-only?)
"builtins" parameter.
No, some APIs effectively define *protocols*. For such APIs, *
On Fri, Mar 9, 2012 at 6:19 PM, Mark Shannon wrote:
> The Python API would be changed, but in a backwards compatible way.
> exec, eval and __import__ would all gain an optional (keyword-only?)
> "builtins" parameter.
No, some APIs effectively define *protocols*. For such APIs, *adding*
parameters
- Original Message -
> But the stuff you run is not really benchmarking anything. As far as I
> know django benchmarks benchmark something like mostly DB creation and
> deletion, although that might differ between CPython and PyPy. How
> about running *actual* django benchmarks, instead
Guido van Rossum wrote:
On Thu, Mar 8, 2012 at 4:33 PM, Nick Coghlan wrote:
On Fri, Mar 9, 2012 at 3:31 AM, Guido van Rossum wrote:
But the __builtins__ that are actually used by any particular piece of
code is *not* taken by importing builtins. It is taken from what the
globals store under t
19 matches
Mail list logo
