On 3/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
> The teeobject has GC (hence the word 'and' in 'itertools.tee and its
> internal teedataobject' ;-) The problem with test_generators is that this
> also leaks:
>
> def leak():
> def gen():
> while True:
> yield g
>
We've made a lot of improvement with testing over the years.
Recently, we've gotten even more serious with the buildbot, Coverity,
and coverage (http://coverage.livinglogic.de). However, in order to
improve quality even further, we need to do a little more work. This
is especially important with
On 3/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I propose that someone start writing a Py3k PEP for class decorators.
> I don't think it's fair to the 2.5 release team to want to push this
> into 2.5 though; how about 2.6?
Wasn't there already a (pretty small) patch? I guess it would
On 3/28/06, Gerhard Häring <[EMAIL PROTECTED]> wrote:
>
> > Even better, the authors should be willing to keep the version in
> > Python synchronized with the separate release.
>
> In particular, I would then synchronize changes that have proven stable
> in the standalone release to the Python core
These issues are on HEAD. There might be some others I missed.
With cc there are at least 2 issues:
* test_file causes interpreter exit due to sys.stdin.seek(-1)
* test_pty fails apparently due to whitespace differences
http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/
On 3/29/06, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>
> This is an ideal job for VMWare on an existing linux build machine if
> someone can ante up a win xp and msvc++ license to the cause.
It probably isn't great from a practical point of view if you wanted
to run buildbot for both the server
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 interpreter.
The problem is that the string is converted without question to a
unicode buffer. Within unicode,
On 3/29/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
> I'll just point out that Atlassian has offered us free hosting for a
> Jira/Confluence solution (plus svn and other stuff we may or may not
> want). I personally support this option, but I know (and accept!) that
> there are differing opinion
On 3/29/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
>
> > I'm in favor of having Atlassian setup a system to be used for 3k. It
> > would be completely experimental and could be completely thrown away
> > which should be made clear to
On 3/30/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> The problem is that now PyXML is no longer maintainable (not that it
> has been maintained very well, though): The files that used to be
> identical in PyXML and Python no longer are identical, so keeping
> them synchronized adds unreason
On 3/30/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> Disabling a test on a platform is usually a bad thing, overall. The
Agreed.
> purpose of the test suite isn't to get a lot of green buildbot boxes
> <0.5 wink>, it's to determine whether Python works as expected. If a
> platform bug causes so
On 4/1/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
>
> I don't know if anyone runs Python under valgrind regularly though.
I do for some definition of "regularly". It would be better to setup
a cron job to truly run it regularly, perhaps once a month. It should
run on both HEAD and supported r
On 4/2/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Does anyone else routinely use -R? If anyone does, do all the tests
> pass for them?
Yes and no. Every 12 hours, see Misc/build.sh
For the latest results, see:
http://docs.python.org/dev/results/make-test-refleak.out
Several tests fail cons
I updated the PEP to include owners. If this message is sent directly
to you, you are an owner.
http://www.python.org/dev/peps/pep-0356/
There are still some items without owners as I don't know who will be
leading the charge to get some of the modules in the stdlib. If we
don't have anyone pus
On 4/3/06, Zachary Pincus <[EMAIL PROTECTED]> wrote:
>
> Sorry if it's bad form to ask about patches one has submitted -- let
> me know if that sort of discussion should be kept strictly on the
> patch tracker.
No, it's fine. Thanks for reminding us about this issue.
Unfortunately, without an ex
On 4/3/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
> Greg Ewing <[EMAIL PROTECTED]> writes:
>
> > Michael Hudson wrote:
> >
> >> And if we want to have a version of __del__ that can't reference
> >> 'self', we have it already: weakrefs with callbacks.
> >
> > Does that actually work at the moment
On 4/4/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
>
> On 4/4/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> >
> >
> > Oh, goodie, a segmentation fault. Let's see if I can reproduce it ;P
>
>
> And so I could.
> test_banana.CananaTestCase.testCrashNegativeLong crashes,
> because it calls PyStr
The freeze is still a few hours away, but please refrain from
modifications unless they are really, really important for the
release. The tests are just starting to turn green again.
I'm not as worried about doc changes. Andrew feel free to keep
updating whatsnew.
Cheers,
n
Debian (ia64, ppc) is broken for several reasons, including the
following test failures: test_ctypes test_curses test_sqlite. Some
of the reasons vary depending on architecture.
Ubuntu on hppa seems to have problems with at least: test_wait[34]
seems to crash.
cygwin has major problems (ie, it
On 4/5/06, Benji York <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > What operating system and compiler?
>
> Oops, should have included that:
> Ubuntu Breezy, Kernel 2.6.12-10-686
> GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
32-bit or 64-bit? I would expect a modes
On 4/9/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Guido]
> > On Linux, In HEAD 2.5, but only with the non-debug version, I get a
> > segfault when I do this:
> >
> > >>> '''
> > ... '''
>
> It rings a bell here only in that the front end had lots of
> allocate-versus-free mismatches between the P
On 4/10/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
> It appears the problem is an object/mem mismatch: both PyOS_Readline in
> pgenmain.c, and PyOS_StdioReadline use PyObject_MALLOC, but bltinmodule.c
> is freeing the pointer with PyMem_FREE.
This (Readline using PyObject) was due to my recen
On 4/10/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I seem to recall some Python-dev discussion about this particular behavior,
> but can't find it in Google. Is this test currently known to be
> failing? If so, why, and what's the plan for it?
Only failing for 2.4 IIRC: http://python.org/s
On 4/10/06, Trent Mick <[EMAIL PROTECTED]> wrote:
>
> Sorry that I took so long to run this. It is a little unfortunate that
> with the last build step being "clean", I couldn't just cd into the
> build directory and try to run this.
Maybe we should clean before we configure/compile? That would l
On 4/10/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 4/10/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >
> > It appears the problem is an object/mem mismatch: both PyOS_Readline in
> > pgenmain.c, and PyOS_StdioReadline use PyObject_MALLOC, but bltinmodule.
On 4/11/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> > It strikes me that it should not be used, or maybe renamed to
> > _PyObject_REPR.
> > Should removing or renaming it be done in 2.5 or in Py3K?
>
> Since it is intrinsically buggy, I would support removal in Py2.5
+1 on removal. Goog
On 4/11/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> 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 :-)
Tsk, tsk, Thomas. Should be fixed
nvenient
> 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.
>
> Jeremy
>
> On 4/11/06, Neal Norwitz <[EMAIL
If you don't write or otherwise maintain Python Extension Modules
written in C (or C++) or embed Python in your application,
you can stop reading.
Python 2.5 alpha 1 was released April 5, 2006. The second alpha
should be released in a few weeks. There are several changes
which can cause C extens
Can all developers try to logon to SF and take a look at the
bugs/patches assigned to you? Sometimes we were assigned items and we
may not have been notified (or forgot that we have outstanding items).
This link should take you to your page:
http://sourceforge.net/my/tracker.php
If you aren't
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 a
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 thei
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. Co
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
> &g
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:
2
On 4/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> > 235:
> > assert(length > unicode->length = (int)length;
>
> Right: I just changed it. It may date back to a version of the patch
> where I only changed the signatures of the functions, but not the
> object layout.
I just gr
On 4/13/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> >
> > Does this mean you would like to see this patch checked in to 2.5?
>
> Yes.
Ok, I checked this in to 2.5 (minus the syntax error).
> I also think that changing the type from signed to unsigned
> by backporting the configure fix will onl
On 4/13/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Rather than delete a leak test, perhaps we could simply move it into a
> new old-leaking-tests subdirectory? Likewise for crash tests. When
> the bug reappears, it's helfpul to have the focussed (whittled-down)
> old test that provoked it hand
On 4/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > I just grepped for INT_MAX and there's a ton of them still (well 83 in
> > */*.c). Some aren't an issue like posixmodule.c, those are
> > _SC_INT_MAX. marshal
If you don't write or otherwise maintain Python Extension Modules
written in C (or C++) or embed Python in your application,
you can stop reading.
Python 2.5 alpha 1 was released April 5, 2006. The second alpha
should be released in a few weeks. There are several changes
which can cause C extens
This was run on linux amd64. It would be great to run purify on
windows and other platforms. If you do, please report back here, even
if nothing was found. That would be a good data point.
Summary of tests with problems:
test_codecencodings_jp (1 invalid read)
test_coding (1 invalid read)
test
The windows buildbot slaves (cygwin too) are still having problems
with the DLL being in use when we start compiling so the compile
fails. clean.bat is not called afterwards based on the buildbot log.
I don't know if clean fixes the problem. If it does, would this patch
fix the problem:
Index:
We've only got a short time to get setup for Google's Summer of Code.
We need to start identifying mentors and collecting ideas for students
to implement. We have the SimpleTodo list
(http://wiki.python.org/moin/SimpleTodo), but nothing on the SoC page
yet (http://wiki.python.org/moin/SummerOfCod
On 4/18/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > As for discussion, Guido originally brought up the question here a few
> > months ago, and it's been listed in PEP 356 for a while. I've also
> > posted things related to the inclusion both here and in distutils-sig.
On 4/18/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:55 PM 4/18/2006 +0200, Fredrik Lundh wrote:
> >who decided that setuptools should be added to 2.5, btw?
>
> Guido proposed it on Python-dev when the 2.5 schedule was first being
> discussed. I discussed it with him off-list, ...
I thou
On 4/18/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-04-19 at 14:57 +1000, Anthony Baxter wrote:
> > I'm not sure how people would prefer this be handled. I don't think we
> > need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
> > pysqlite or cProfile, either.
>
> C
of the
>library. In essence, that committer is a "second" for the
>package inclusion.
>
> setuptools has 1 and 2, but fails on 3 and 4 so far. There is
> discussion now after the fact, but it results in objection.
>
> Now, I know that Neal Norwitz had asked hi
ing a student though PSF are encouraged to
contact me, Neal Norwitz at [EMAIL PROTECTED] People unknown to Guido
or myself should find a couple of people known within the Python community
who are willing to act as references.
Feel free to contact me if you have any questions. I look forward to meeting
On 4/21/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Thomas Heller wrote:
> > I forgot to mention that there are a lot of warnings about conversion
> > betweem Py_ssize_t to int - if you want me to fix the obvious ones
> > I'll offer to correct some of them from time to time and commit the
>
On 4/21/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> >> Right - they have been there ever since I started (in fact, I started
> >> this entire project *because* of these warnings). You can get them on
> >> x86, too, if you
On 4/24/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 24, 2006 at 12:30:12PM -0400, Alan McIntyre wrote:
> > My unglamorous proposal is to review bugs & patches (starting with the
> > oldest) and resolve at least 200 of them. Is that too much? Too few?
> > I'll fix as many as possibl
Hi Karol.
Please see the wiki: http://wiki.python.org/moin/SummerOfCode/
There are a bunch of ideas up there. If you want to hash out new
ideas, I suppose this list is as good as any. But please do some
searching to find if your idea has been tried before.
It might also help you to guage inte
The following PEPs are open according to PEP 0 and haven't seen much
activity recently IIRC. I'd like everyone to take a cut and bring
these up to date. For all the PEPs that aren't going anywhere, can we
close them? Please update your PEP if appropriate.
PEP 237 mentions changing an OverflowWa
On 4/22/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [19 Apr 2006, Neal Norwitz]
> > test_cmd_line leaked [0, 17, -17] references
> > test_filecmp leaked [0, 13, 0] references
> > test_threading_local leaked [-93, 0, 0] references
> > test_urllib2 leaked [-121,
If you are addressed on this message, it means you have open issues
that need to be resolved for 2.5. Some of these issues are
documentation, others are code issues. This information comes from
PEP 356. The best way to get me to stop bugging you is to close out
these tasks. :-)
Who is the owner
There's a new SoC mailing list.
[EMAIL PROTECTED]
You can sign up here: http://mail.python.org/mailman/listinfo/soc2006
This list is for any SoC discussion: mentors, students, idea, etc.
Student can submit applications starting May 1, so now is the time to
get students interested in your
python look spiffy
* what's happening with these modules: timing, cl, sv?
n
On 4/28/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 27, 2006 at 10:58:49PM -0700, Neal Norwitz wrote:
> > If you are addressed on this message, it means you have open issues
> > tha
Results: 2.86% for 1 arg (len), 11.8% for 2 args (min), and 1.6% for pybench.
./python.exe -m timeit 'for x in xrange(1): len([])'
./python.exe -m timeit 'for x in xrange(1): min(1,2)'
One part of it is a little dangerous though.
http://python.org/sf/1479611
The general idea is to preal
On 5/1/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> > Author: neal.norwitz
> > Date: Tue May 2 06:43:14 2006
> > New Revision: 45850
> >
> > Modified:
> >python/trunk/Doc/lib/libfuncs.tex
> >python/trunk/Lib/test/test_subprocess.py
> >python/trunk/Misc/NEWS
> >python/trunk/Objects/f
There is less than a week left before students must submit a final
application. There are a bunch of ideas up on the wiki:
http://wiki.python.org/moin/SummerOfCode/
The wiki has instructions for how to submit a proposal. There are
many different areas including: core language features, lib
On 5/4/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Since I hope we see a lot more of these problems in the future, what
Me too.
> can be done to ease the pain? I don't know enough about SVN admin to
> know what might be realistic. Adding a pile of "temporary
> committers" comes to mind, but
If you are addressed on this message, it means you have open issues
that need to be resolved for 2.5. Some of these issues are
documentation, others are code issues. This information comes from
PEP 356. The best way to get me to stop bugging you is to close out
these tasks. :-)
Note the next al
On 5/11/06, Edward Loper <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > Another benefit of this is the ability to get more info through
> > introspection. Right now, you can't even find the number of arguments
> > of a function implemented in C. Yo
On 5/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> > '%zd' won't work since my value can be negative, and the 'z' modifier
> > converts the argument to size_t.
>
> That's a bug. It should print it signed. If unsigned printing of size_t
> is desired, %zu should be used.
Looking in stringo
On 5/16/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
> > Broadening the ifdef to cover all posix systems rather than just AIX
> > might be the right thing to do.
>
> As I said: I doubt it is the right thing to do. Instead, the lock
> should get released in the child proces
On 5/17/06, Dave Cinege
<[EMAIL PROTECTED]> wrote:
> Very oftenmake that very very very very very very very very very often,
> I find myself processing text in python that when .split()'ing a line, I'd
> like to exclude the split for a 'quoted' item...quoted because it contains
> whitespace or
I moved up the 2.5 release date by a bit. Ideally, I wanted to have
the final on July 27 which corresponds to OSCON. This seems too
aggressive since I haven't updated the schedule publicly. So the new
schedule has rc1 slated for July 27.
http://www.python.org/dev/peps/pep-0356/
So far we'v
On 5/19/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> Remember, the feature freeze isn't until beta1. New stuff can still go
> in after the next alpha, before beta1.
>
> And pure speedup related items aren't likely to cause feature changes
> (I hope)
I agree. Of course, it's preferable to get th
On 5/22/06, martin.v.loewis <[EMAIL PROTECTED]> wrote:
> Author: martin.v.loewis
> Date: Mon May 22 11:15:18 2006
> New Revision: 46064
>
> Modified: python/trunk/Include/Python.h
> ==
> --- python/trunk/Include/Python.h
, everyone
needs to know.
n
--
On 5/21/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Sun, May 21, 2006, Neal Norwitz wrote:
> > On 5/19/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> >>
> >>Remember, the feature freeze isn't until beta1. New stuff
This is probably orthogonal to the problem, however, you may want to
look into trying to speed up Python/errors.c. This link will probably
not work due to sessions, but click on the latest run for python and
Python/errors.c
http://coverage.livinglogic.de/coverage/web/selectEntry.do?template=2850&
First off, good work to everyone involved. You did a tremendous job.
I just hope to hell you're done, because I can't keep up! :-)
It would help me enormously if someone could summarize the status and
everything that went on. These are the things that would help me the
most.
* What are the spe
On 5/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> In the process of reviewing and possibly extending getargs.c, I stumbled
> over the "compatibility" flag supposedly used for METH_OLDARGS functions.
> No code in the core uses this calling convention any more, and it has been
> deprecated for qu
On 5/28/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
>
> I think I've fixed the refleaks too, but running regrtest -R :: takes
> rther a while.
FYI, I typically run -R 4:3: since it seems to do a pretty good job
and takes 20% less time. I never run -R with -u all, only a normal
run or specif
On 5/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > On 5/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> In the process of reviewing and possibly extending getargs.c, I stumbled
> >> over the "compatibility" flag su
$ grep long */*.h
minus comments, etc yields several questions about whether some
values should use Py_ssize_t rather than C longs. In particular:
* hash values
Include/abstract.h: long PyObject_Hash(PyObject *o); // also in object.h
Include/object.h:typedef long (*hashfunc)(PyObject *);
Here's the int questions. The entire list is too big to post (50k),
so it's here:
http://www.python.org/neal/header-ints
Should the following values be ints (limited to 2G)?
* dict counts (ma_fill, ma_used, ma_mask)
* line #s and column #s
* AST (asdl.h) sequences
* recursion limit
* read/
On 5/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Georg Brandl wrote:
> > I thought more about PyArg_Parse for __deprecated__.
>
> Ah, PyArg_Parse can, of course. Having it actually do that should not
> hurt, either - but you need a reliable check whether the compiler
> supports __deprecat
On 5/29/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On 5/29/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> >
> > this is a clear case of unnecessary meddling. removing it won't remove
> > much code (a whopping 11 lines is dedicated to this), nor give any speed
> > ups whatsoever; all you're do
On 5/29/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
> >
> > is there some natural and obvious connection between generators and that
> > number that I'm missing, or is that constant perhaps best hidden inside
> > some introspection support module?
>
> It seems to be a combina
On 5/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> > OTOH, perhaps a deprecation warning on PyArgs_Parse() is sufficient?
> > What about that? It doesn't address other cases where OLDARGS are
> > used without PyArgs_Parse though.
>
> What other cases remain? People might have complex arg
I've been starting to get some of the buildbots working again. There
was some massive problem on May 25 where a ton of extra files were
left around. I can't remember if I saw something about that at the
NFS sprint or not.
There is a lingering problem that I can't fix on all the boxes. Namely:
On 5/30/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
>
> > I've been starting to get some of the buildbots working again. There
> > was some massive problem on May 25 where a ton of extra files were
> > left around. I can't remem
Bob,
There are a couple of things I don't understand about the new struct.
Below is a test that fails.
$ ./python ./Lib/test/regrtest.py test_tarfile test_struct
test_tarfile
/home/pybot/test-trunk/build/Lib/struct.py:63: DeprecationWarning: 'l'
format requires -2147483648 <= number <= 2147483647
On 5/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Zitat von Neal Norwitz <[EMAIL PROTECTED]>:
>
> > I've been starting to get some of the buildbots working again. There
> > was some massive problem on May 25 where a ton of extra files were
> >
On 5/31/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
> On May 31, 2006, at 12:49 AM, Neal Norwitz wrote:
>
> > Bob,
> >
> > There are a couple of things I don't understand about the new struct.
> > Below is a test that fails.
> >
> > $
On 5/31/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> "standard" is a technical word with precise meaning here, and is
> defined by the struct module docs, in contrast to "native". It means
> whatever they say it means :-) "Portable" may have been a more
> intuitive word than "standard" here -- r
This is still in Lib/test/string_tests.py:
#EQ("A", "", "replace", "", "A")
# That was the correct result; this is the result we actually get
# now (for str, but not for unicode):
#EQ("", "", "replace", "", "A")
Is this going to be fixed?
n
___
I was about to remove Mac/IDE scripts, but it looks like there might
be more stuff that is OS 9 related and should be removed. Other
possibilities look like (everything under Mac/):
Demo/* this is a bit more speculative
IDE scripts/*
MPW/*
Tools/IDE/* this references IDE scripts, so pre
Any ideas?
http://www.python.org/dev/buildbot/all/MIPS%20Debian%20trunk/builds/176/step-test/0
==
FAIL: test_count (test.test_unicode.UnicodeTest)
--
Traceback (
Looks pretty good, except for 1 cjk problem:
test_codecencodings_jp
Invalid read of size 1
at 0x110AEBC3: shift_jis_2004_decode (_codecs_jp.c:642)
by 0xBFCBDB7: mbidecoder_decode (multibytecodec.c:839)
Address 0xAEC376B is 0 bytes after a block of size 3 alloc'd
at 0x4A19B7E:
On 6/1/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
>
> > Any ideas?
>
> this is a recent change, so it looks like the box simply didn't get
> around to rebuild the unicodeobject module.
That shouldn't be. make distclean should be cal
On 5/29/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Neal Norwitz]
> > * hash values
> > Include/abstract.h: long PyObject_Hash(PyObject *o); // also in
> > object.h
> > Include/object.h:typedef long (*hashfunc)(PyObject *);
>
> We should leav
[Tim and Martin talking about leak tests when running regtest with -R]
I've disabled the LEAKY_TESTS exclusion in build.sh. This means if
any test reports leaks when regtest.py -R :: is run, mail will be sent
to python-checkins. The next run should kick off in a few hours (4
and 16 ET). We'll s
It's June 9 in most parts of the world. The schedule calls for beta 1
on June 14. That means there's less than 4 days until the expected
code freeze. Please don't rush to get everything in at the last
minute. The buildbots should remain green to keep Anthony happy and
me sane (or is it the othe
The most important outstanding issue is the xmlplus/xmlcore issue.
It's not going to get fixed unless someone works on it. There's only
a few days left before beta 1. Can someone please address this? If
that means reverting changes to maintain compatibility, so be it.
There is still the missing
I wonder if this is similar to Kevin's problem? I couldn't reproduce
his problem though. This happens with both debug and release builds.
Not sure how to reduce the test case. pychecker was just iterating
through the byte codes. It wasn't doing anything particularly
interesting.
./python pyche
On 6/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:00 AM 6/13/2006 +0200, Giovanni Bajo wrote:
> >IMO, the better way is exactly this you depicted: move the official
> >development
> >tree into this Externals/ dir *within* Python's repository. Off that, you can
> >have your own branch fo
On 6/13/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [georg.brandl]
> >> Author: georg.brandl
> >> Date: Fri Jun 9 20:45:48 2006
> >> New Revision: 46795
> >>
> >> Log:
> >> RFE #1491485: str/unicode.endswith()/startswith() now accept
x2a95dd6d84 "Lib/encodings/cp1140.py") at import.c:642
#6 0x004b6ff8 in load_source_module (name=0x2a95ded434 "cp1140",
pathname=0x2a95dd6d84 "Lib/encodings/cp1140.py", fp=0x731d10) at
import.c:923
On 6/11/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
301 - 400 of 523 matches
Mail list logo
