[Neal Norwitz]
...
I'm concerned about the negative ref leak in test_contextlib. I
wonder if this was a result of PJE's fix for generators?
I don't know, but if you do
while 1:
test_contextlib.test_main()
gc.collect()
under a debug build it eventually ( 500 iterations) crashes with
[Neal]
...
I'm concerned about the negative ref leak in test_contextlib. I
wonder if this was a result of PJE's fix for generators?
[Tim]
I don't know, but if you do
while 1:
test_contextlib.test_main()
gc.collect()
under a debug build it eventually ( 500 iterations) crashes
Jeremy Hylton wrote:
It's intended as an internal debugging API. I find it very convenient
for adding with a printf() here and there, which is how it got added
long ago. It should really have a comment mentioning that it leaks
the repr object, and starting with an _ wouldn't be bad either.
Tim Peters wrote:
All the trunk buildbots started failing about 5 hours ago, in
test_parser. There have been enough checkins since then that the
boundary between passing and failing is about to scroll off forever.
It's not lost, though; it's just not displayed anymore. It would be
possible
On 4/12/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
The failures might have nothing to with the changes, though: It appears
that some files are still left from earlier tests, and now the setUp
code fails because /tmp/dir already exists...
That was my guess. I went in and cleaned up all the
Phillip J. Eby wrote:
At 07:43 AM 4/12/2006 +1000, Nick Coghlan wrote:
Phillip J. Eby wrote:
I propose to create a new API, 'imp.find_loader()' and have it
return a PEP
302-compatible loader object, even for cases that would normally be
handled
via 'imp.load_module()'. In such cases,
A compiler hook on string initialization, eh?
I have a distantly related story--this isn't important, just another
random Python use case for the file. (The ixyzzy proposal wouldn't
help this case.)
In scons, your SConscripts (makefiles, essentially) are Python source
code. You typically have
Anthony I've done a lot of the work to get Python to build with g++ -
Anthony ... I can't spend much more time on this now, but if someone
Anthony wants to take over and finish it off, that'd be great.
Is this on a branch or available as a patch somewhere?
Skip
At 08:39 PM 4/12/2006 +1000, Nick Coghlan wrote:
In this particular case, it would be a Python module imp.py that
included the line from _imp import * (where _imp is the current C-only
module with a different name).
I don't think that's going to work, since importing won't work until _imp
Hi all,
On Sun, Mar 26, 2006 at 11:39:50PM -0800, Neal Norwitz wrote:
There are 5 tests that leak references that are present in 2.4.3c1,
but not on HEAD. It would be great if someone can diagnose these and
suggest a fix.
test_doctest leaked [1, 1, 1] references
test_pkg leaked [10, 10,
[Tim ]
I'd whine about not checking buildbot health after a code change,
except that it's much more tempting to point out that Thomas couldn't
have run the test suite successfully on his own box in this case :-)
[Thomas]
Not with -uall, yes. Without -uall it ran fine (by chance, I admit.)
[Tim]
Phillip, when eyeballing gen_dealloc(), I didn't understand two things:
1. Why doesn't
if (gen-gi_frame-f_stacktop!=NULL) {
check first to be sure that gen-gi_frame != Py_None?
[Phillip]
Apparently, it's because I'm an idiot, and because nobody else realized
this during
Can someone have a look at #860326? I got bitten by it today, and I can
see no reason not to apply suggested patch.
Thanks!
Seo Sanghyeon
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Wed, Apr 12, 2006 at 01:43:43PM -0400, Tim Peters wrote:
BTW, someone looking for an easy task might enjoy rewriting other
tp_traverse slots to use Py_VISIT. We even have cases now (like
super_traverse) where modules define their own workalike
traverse-visit macros, which has become
On 4/12/06, A.M. Kuchling [EMAIL PROTECTED] wrote:
On Wed, Apr 12, 2006 at 01:43:43PM -0400, Tim Peters wrote:
BTW, someone looking for an easy task might enjoy rewriting other
tp_traverse slots to use Py_VISIT. We even have cases now (like
super_traverse) where modules define their own
On Wed, Apr 12, 2006 at 01:43:43PM -0400, Tim Peters wrote:
BTW, someone looking for an easy task might enjoy rewriting other
tp_traverse slots to use Py_VISIT. We even have cases now (like
super_traverse) where modules define their own workalike
traverse-visit macros, which has become
On Sat, Apr 08, 2006 at 02:47:28PM -0700, Brett Cannon wrote:
OK, I am going to write the PEP I proposed a week or so ago, listing
all modules and packages within the stdlib that are maintained
externally so we have a central place to go for contact info or where
to report bugs on issues.
Seo Sanghyeon wrote:
Can someone have a look at #860326? I got bitten by it today, and I can
see no reason not to apply suggested patch.
I've reviewed it and checked it in.
Cheers,
Georg
___
Python-Dev mailing list
Python-Dev@python.org
Georg Brandl wrote:
Seo Sanghyeon wrote:
Can someone have a look at #860326? I got bitten by it today, and I can
see no reason not to apply suggested patch.
I've reviewed it and checked it in.
Hm. This broke a few doctests. I can fix them, but I wonder if
doctest should accept a bare
Phillip J. Eby wrote:
At 08:39 PM 4/12/2006 +1000, Nick Coghlan wrote:
In this particular case, it would be a Python module imp.py that
included the line from _imp import * (where _imp is the current
C-only module with a different name).
I don't think that's going to work, since importing
Anthony I've done a lot of the work to get Python to build with g++ -
Is this on a branch or available as a patch somewhere?
It's the trunk.
Is there a primer that will get me to where Anthony is? I tried the obvious
CC=g++ ./configure --with-cxx=g++
and the build fails trying
On Thursday 13 April 2006 10:59, Skip Montanaro wrote:
Anthony I've done a lot of the work to get Python to build
with g++ -
Is this on a branch or available as a patch somewhere?
It's the trunk.
Is there a primer that will get me to where Anthony is? I tried
the obvious
[georg.brandl]
Author: georg.brandl
Date: Wed Apr 12 23:14:09 2006
New Revision: 45321
Modified:
python/trunk/Lib/test/test_traceback.py
python/trunk/Lib/traceback.py
python/trunk/Misc/NEWS
Log:
Patch #860326: traceback.format_exception_only() now prepends the
exception's
At 09:14 PM 4/12/2006 -0400, Tim Peters wrote:
The 2.4 backport of this patch should be reverted, since it changes
visible behavior (for example, all the 2.4 branch buildbot runs also
fail now).
Fine by me if we change the failing tests on the trunk to pass (noting
that should have been done
[Georg Brandl]
Hm. This broke a few doctests. I can fix them, but I wonder if
doctest should accept a bare exception name if the exception
is defined in the current module.
No.
Or should it ignore the module name altogether?
No. doctest strives to be magic-free WYSIWYG. If someone
On Thursday 13 April 2006 11:14, Tim Peters wrote:
Patch #860326: traceback.format_exception_only() now prepends the
exception's module name to non-builtin exceptions, like the
interpreter itself does.
And all the trunk buildbot runs have failed since, in at least
test_decimal,
[Tim]
...
Fine by me if we change the failing tests on the trunk to pass (noting
that should have been done before checking in).
[Phillip]
It's not fine by me if the reason for the failure is that doctests trapping
specific exceptions no longer work with the patch.
If that's the case, the
On 4/12/06, Anthony Baxter [EMAIL PROTECTED] wrote:
The code is _nearly_ building fine. there's an issue in _sre.c with
some code that either returns a Py_UNICODE* or an SRE_CHAR* (unsigned
char*) in a void*. The code probably needs a refactoring to deal with
that. There's also
On Thursday 13 April 2006 12:03, Jeremy Hylton wrote:
The code in compile.c is pretty dodgy. I'd like to think of a
better way to represent an array of cmpop_ty objects than casting
ints to void* and then back.
Well, it's compiling and working with C++ now, at least. But yeah,
that's pretty
So I lied - I found the time today to spread the magic pixie dust of
extern C {} around to get the Python core to build and link with
g++. (It still builds with gcc). There's still an issue with
Modules/_sre.c, and now that we can run setup.py, there's lots and
lots of errors from the various
Jeremy The code in compile.c is pretty dodgy. I'd like to think of a
Jeremy better way to represent an array of cmpop_ty objects than
Jeremy casting ints to void* and then back.
http://python.org/sf/1469594
might be a step in the right direction.
I assigned it to Anthony. Feel
Looks good to me. Why don't you check it in.
Jeremy
On 4/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Jeremy The code in compile.c is pretty dodgy. I'd like to think of a
Jeremy better way to represent an array of cmpop_ty objects than
Jeremy casting ints to void* and then
Tim Peters wrote:
A less-desirable (IMO) alternative is to change the Python core to
display bare (non-dotted) exception names when it produces a
traceback.
Much less desirable, considering that there are modules
which define an exception just called error on the
assumption that you're going
[A.M. Kuchling]
Do we need a list of CPython cleanup projects?
(Compare to the Linux kernel janitors:
http://janitor.kernelnewbies.org/TODO.)
[Neal Norwitz]
+1. Could add a page to the wiki and link to it from the dev faq.
Not the same thing, but I just added:
On 4/12/06, Tim Peters [EMAIL PROTECTED] wrote:
[A.M. Kuchling]
Do we need a list of CPython cleanup projects?
(Compare to the Linux kernel janitors:
http://janitor.kernelnewbies.org/TODO.)
[Neal Norwitz]
+1. Could add a page to the wiki and link to it from the dev faq.
Not the same
On 3/31/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
Neal Norwitz wrote:
See http://python.org/sf/1454485 for the gory details. Basically if
you create a unicode array (array.array('u')) and try to append an
8-bit string (ie, not unicode), you can crash the
Martin,
In Include/ucnhash.h I notice some integers and wonder if those should
be Py_ssize_t. It looks like they are just names so they should be
pretty short.
But in Objects/unicodeobject.c, I notice a bunch of ints and casts to
int and wonder if they should be changed to Py_ssize_t/removed:
37 matches
Mail list logo
