On Tue, Mar 18, 2008 at 11:17 AM, John Millikin <[EMAIL PROTECTED]> wrote:
> > Possible features for 2.6
> > New modules in the standard library:
> > - JSON implementation
> >
> Have there been any plans made for which one? All of the
No. This was something I added as a nice to ha
On Tue, Mar 18, 2008 at 10:51 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The key goal here (well, mine in any case :-)
> is to manage developers, not to get releases out at all cost. Even
> though the release schedule is set in stone, I think we should send
> out a variety of reminders a
[changing to: and subject: ]
On Tue, Mar 18, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 18, 2008 at 3:58 PM, neal.norwitz
> <[EMAIL PROTECTED]> wrote:
> > Get this test to pass (UserList/UserDict no longer exist and caused a
> skip).
>
> I think the automatic s
On Tue, Mar 18, 2008 at 4:43 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> The tabs/spaces checker that is run before doing a svn ci on the python
> repository spits out an error message about which files have problems.
>
> Could someone please update this error message to say something to the
On Wed, Mar 5, 2008 at 4:27 PM, Henrik Vendelbo <[EMAIL PROTECTED]> wrote:
> It appears to me that if you can make mapping mechanisms faster in
> Python you can make significant
> overall speed improvements. I also think the proposed concept could
> add flexibility to persistence formats
> and
On Tue, Mar 18, 2008 at 10:07 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> Now that we're aggressively adding Py3k warnings to the trunk, I think it's
> a good time to get this straightened out. The docs [1] say PyErr_Warn is
> deprecated in favor of PyErr_WarnEx. However, I have seen both in
Great work Trent! You'll need to take a picture of Martin buying you
the beer once you get the rest green. :-)
n
On Wed, Mar 19, 2008 at 5:57 PM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> We've just experienced our first 2.6 green x64 Windows builds on the build
> slaves! Well, almost green.
Unfortunately, I don't have ssh access from my hotel room. This means
I won't be able to help much until I get home.
On Wed, Mar 19, 2008 at 7:26 PM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> Quick update on the status of the trunk buildbots:
>
> Failing:
> [x8
Hi Mike.
Travis is the best person to discuss the status of the buffer APIs.
Cheers,
n
On Sat, Mar 22, 2008 at 2:50 PM, Mike Sullivan <[EMAIL PROTECTED]> wrote:
> What is the current state of the N-D Array Interface proposal
> (http://numpy.scipy.org/array_interface.shtml). Some work was done o
On Thu, Feb 14, 2008 at 10:09 AM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote:
> On 14 Feb, 16:36, "Giampaolo Rodola'" <[EMAIL PROTECTED]> wrote:
> > Ok, I'll try to take a look at all asyncore/chat reports and try to
> > summarize them by splitting patches which solve bugs and patches which
> >
The next releases of 2.6/3.0 are planned for April 2, just over a week
from now. There is much work that needs to be done. The buildbots
are in a pretty sad state and the gods are seeing too much red.
http://www.python.org/dev/buildbot/stable/
http://www.python.org/dev/buildbot/all/
See my
We need to get the tests for Python to be more stable so we can push
out solid releases. In order to achieve this result, we need tests
that are *100% reliable* and fail _only when there is a problem with
Python_. While we aren't nearly as close to that goal as we need to
be, we have to work towa
On Wed, Mar 26, 2008 at 9:04 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> On Mar 26, 2008, at 8:14 AM, Facundo Batista wrote:
> > 2008/3/26, Neal Norwitz <[EMAIL PROTECTED]>:
> >
> >> We ne
Christian,
Please fix the build on the various buildbots that are failing or
revert your changes for unicode literals. The build failures started
to occur at r61953. There were several more (~5) follow up checkins.
You can find all the failures here: http://www.python.org/dev/buildbot/all/
Th
On Wed, Mar 26, 2008 at 5:52 PM, <[EMAIL PROTECTED]> wrote:
> >> The next releases of 2.6/3.0 are planned for April 2, just over a
> >> week from now. There is much work that needs to be done. The
> >> buildbots are in a pretty sad state and the gods are seeing too much
> >> red.
On Thu, Mar 27, 2008 at 11:31 AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > There
> > have been other tests that have also been flaky like test_asynchat,
> > test_smtplib, test_ssl, test_urllib2net, test_urllibnet,
> > test_xmlrpc_net and some of the tests that use networking.
>
> Some of t
On Fri, Mar 28, 2008 at 3:31 AM, <[EMAIL PROTECTED]> wrote:
>
> Neal> Anything that connects to a remote host is definitely flaky.
>
> Would it maybe help to set up a dedicated host (or virtual host) to serve as
> the sole target of all network tests?
It would help, but not fix the problem.
On Sun, Mar 30, 2008 at 7:41 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
>
>
> On Sun, Mar 30, 2008 at 4:54 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
> wrote:
> >
> > > If you'd like, I can merge the rest.
> >
> > If you have the time to figure it all out, sure.
> > I found that quite a tedi
On Sun, Mar 30, 2008 at 7:44 PM, Josiah Carlson
<[EMAIL PROTECTED]> wrote:
>
> I haven't really had time to update the tests/documentation, but
> again, I wasn't experiencing any strange test failures with
> asyncore/asynchat, nor have I been able to find the buildbot failures
> that you are re
test_io is the only leaky test on trunk that I know of. I narrowed
down the leaks to the code below.
It's possible there are other leaks in test_io.
n
--
import sys, gc
import _fileio, io
class FileIO(_fileio._FileIO, io.RawIOBase):
def close(self):
io.RawIOBase.close(self)
def mai
The Windows buildbots are still failing because some tests keep files
opened. This causes subsequent tests which use the same file to fail.
Here is a recent run which had a failure early on:
http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1209/step-test/0
I'm assuming the fir
The release schedule for 2.6/3.0 is http://www.python.org/dev/peps/pep-0361/
3.0 will have the feature, 2.6 may or may not.
n
On Thu, Apr 3, 2008 at 4:47 AM, Heshan Suriyaarachchi
<[EMAIL PROTECTED]> wrote:
> Hi,
> I need to work with annotations as it is said in [1]. Currently I am
> using
On Fri, Apr 4, 2008 at 11:52 AM, Thomas Heller <[EMAIL PROTECTED]> wrote:
> I can offer an OS X x86 machine to run a buildbot on. This is a physical
> machine,
> running OS X 10.5 Leopard.
Thanks Thomas!
Martin and I will coordinate with you off-list.
n
___
I was also going to suggest a platform independent option. I like
-Xwhat-follows-is-impl-dependent.
n
On Fri, Apr 11, 2008 at 12:39 PM, Dino Viehland
<[EMAIL PROTECTED]> wrote:
> IronPython already uses -X:OptionName for special IronPython only options so
> +1 for -X.
>
>
>
> -Original Mes
On Fri, Apr 11, 2008 at 2:53 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I just tried it, and although it works, I get this output:
> > svn: 'post-revprop-change' hook failed; no error output available
> >
> > Significant?
>
> It's the mailer.py hook failing. I'm not quite sure why it
On Sat, Apr 12, 2008 at 11:02 AM, <[EMAIL PROTECTED]> wrote:
>
> I know this is old stuff, but...
>
> I want to update our Python 2.4 installation at work from 2.4.2 to 2.4.5
> (the latest 2.4 source release). I get a test failure for test_pty, an
> extra ^M at the end of one line. I don't g
On Mon, Apr 14, 2008 at 2:56 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> Good idea! A 3to2 project is going to make backporting io.py and other
> new stuff less painful and much faster. For the io.py backport I spent
> most time on removing annotations and replacing "" with u"".
>
> Wha
On Wed, Apr 9, 2008 at 7:12 AM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is there another online sprint/bugfix day in the pipeline? If not, can
> there be? ;-)
Trent, I think you just volunteered to lead it. :-)
We should either do it this weekend Apr 19-20 or wait until after the
rel
On Tue, Apr 15, 2008 at 2:21 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > Iteration with the dict methods (e.g., keys -> iterkeys()),
> > map/zip/filter returning iterator rather than list.
>
> That's only an optimisation, it's n
[Michael working on cleaning up the unittest module]
it seems like most of the good ideas have been captured already. I'll
through two more (low priority) ideas out there.
1) Randomized test runner/option that runs tests in a random order
(like regrtest.py -r, but for methods)
2) decorator to
On Thu, Jun 12, 2008 at 8:41 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> My colleague and SVN developer Ben Sussman-Collins occasionally blogs
> about the social side of (mostly open source) software development. He
> just posted a new one that struck a chord:
>
> http://blog.red-bean.com/sus
On Sun, Aug 17, 2008 at 3:04 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 17, 2008 at 1:40 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Brett Cannon schrieb:
>>> After Christian mentioned how we could speed up interpreter start-up
>>> by removing some dead imports he found, I decided
Below are the problems I found that have not been fixed at r65995 on
trunk (2.6). There will be a separate mail for the 3.0 problems.
I've done the following:
* built in debug and opt mode (gcc 4.1.2) fixing the important warnings
* run all the tests in both modes
* run all the tests (except t
Thanks Antoine!
On Sun, Aug 24, 2008 at 5:58 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Neal Norwitz gmail.com> writes:
>> Can someone (else) compare performance of 2.5, 2.6, and 3.0?
>
> Tests done on a 32-bit Linux installation on an Athlon 3600+ X2. Compiled
Many buildbots are running bsddb 4.7, particularly the debian/ubuntu
ones (4.7.25 which seems to be the latest). Some of them are
crashing, others are not. The max version we support in both 2.6 and
3.0 is 4.7. Should we allow this version or should we use a lower
maximum that is more likely to
On Mon, Sep 8, 2008 at 3:24 AM, Trent Nelson
<[EMAIL PROTECTED]> wrote:
> On Fri, Sep 05, 2008 at 05:55:13PM +0200, Jesus Cea wrote:
>> Trent, are you available to look at the ?spurious? timeout failures in
>> bsddb replication code in the Windows buildbot?.
>>
>> Ten seconds timeout should be plen
On Sun, Sep 14, 2008 at 5:24 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Sun, Sep 14, 2008 at 4:07 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Neal Norwitz wrote:
>>> test_epoll skipped -- kernel doesn't support epoll()
>> ...
>>
On Tue, Sep 23, 2008 at 1:52 AM, Ulrich Eckhardt
<[EMAIL PROTECTED]> wrote:
> Greetings!
>
> I'm currently trying to assess the effort required for a CE port. I'm already
> aware of the project at http://pythonce.sourceforge.net, but I find it a
> waste of time to have two separate projects which t
On Thu, Oct 2, 2008 at 6:21 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Jesse Noller schrieb:
>> So, we just released and there are a few doc typo bugs being filed -
>> my question is if all doc-fixes have to wait for 2.6.1/2.7 or if we
>> can hotfix the 2.6 docs?
>
> I intend to set things up so
Should we plan to put out a final 2.5 release? If so, should we
continue to backport fixes (like Martin's removal of Alpha in
setup.py)? My preference is that we do put out a final 2.5 that has
all accumulated bug fixes. Then close the branch. That way if we put
out a security release for 2.5,
If you only care about this running on a single machine to get some
coverage and don't care about all architectures, you can change
Misc/build.sh to add the configure option.
n
On Mon, Jan 26, 2009 at 2:31 PM, Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>>
>> Me. Does it have t
On Thu, Jan 29, 2009 at 2:38 AM, Dr Andrew Perella wrote:
> Hi,
>
> I was thinking of adding a breakpoint opcode to python to enable less
> invasive debugging.
>
> I came across posts from 1999 by Vladimir Marangozov and Christian Tismer
> discussing this issue but the links to the code are all ou
Can we remove aclocal.m4? The last log message states:
fix for bug #811160 - autoconf vs. hp/ux system header files.
also applied to release23-maint.
Note that aclocal.m4 can go away when autoconf 2.58 is out.
And configure says:
# Generated by GNU Autoconf 2.59
On Wed, Jan 05, 2005 at 10:08:49PM +1100, Andrew McNamara wrote:
> >Also, review comments from Neal Norwitz, 22 Mar 2003 (some of these should
> >already have been addressed):
>
> I should apologise to Neal here for not replying to him at the time.
Hey, I'm impressed
I added a patch to SF: http://python.org/sf/1107887
I would like feedback on whether the approach is desirable.
The patch adds a new method type (flags) METH_ARGS that is used in
PyMethodDef. METH_ARGS means the min and max # of arguments are
specified in the PyMethodDef by adding 2 new fields.
On Mon, 24 Jan 2005 23:36:24 +0100, "Martin v. Löwis"
<[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > I would like feedback on whether the approach is desirable.
>
> I'm probably missing something really essential, but...
>
> Where are the Py_DEC
On Mon, 24 Jan 2005 03:11:05 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> Replacing METH_O and METH_NOARGS seems straight-forward, but
> METH_VARARGS has much broader capabilities. How would you handle the
> simple case of "O|OO"? How could you determine useful default values
> (NULL,
On Tue, 25 Jan 2005 00:30:44 +0100, "Martin v. Löwis"
<[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> >>Where are the Py_DECREFs done for the function arguments?
> >
> > The original code path still handles the Py_DECREFs.
> > This is the while lo
On Tue, 25 Jan 2005 06:42:57 -0500, Raymond Hettinger
<[EMAIL PROTECTED]> wrote:
> >
> > I think tested a method I changed from METH_O to METH_ARGS and could
> > not measure a difference.
>
> Something is probably wrong with the measurements. The new call does much
> more work than METH_O or MET
On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > I agree that METH_O and METH_NOARGS are near
> > optimal wrt to performance. But if we could have one METH_UNPACKED
> > instead of 3 METH_*, I think that would be a win.
> . . .
> > Sorry, I meant eliminated w/3.
On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> This is what I mean about the patch taking on a life of its own. It's
> an optimization patch that slows down METH_O and METH_NOARGS. It's a
> incremental change that throws away backwards compatibility. It's a
On Sun, 6 Feb 2005 10:49:05 -0600, Skip Montanaro <[EMAIL PROTECTED]> wrote:
>
> Wouldn't it be better to have the peephole optimizer recognize the throwaway
> nature of lists in these contexts:
>
> for elt in [1, 2, 4, 8, 16]:
> ...
>
> if foo in [list, tuple]:
> ...
>
On 6/2/05, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> Looking at bug #1209880, the following function from threadmodule.c is
> referenced. I think the args==NULL case, which can return None
> instead of a Boolean value, can never be reached because
> PyArg_ParseTuple() will fail if args==NULL.
>
On 2/13/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Monday 13 February 2006 10:03, Georg Brandl wrote:
> > The above docs are from August 2005 while docs.python.org/dev is current.
> > Shouldn't the old docs be removed?
>
> I'm afraid I've generally been too busy to chime in much on th
On 2/14/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
>
> Releases generally aren't a problem, since they're heavily automated and
> scheduled well in advance. I'm glad to continue helping with that,
> especially since that seems to be about all I can get to sometimes.
Great, I updated the PE
I was hoping to get a lot more feedback about PEP 356 and the 2.5
release schedule.
http://www.python.org/peps/pep-0356.html
I updated the schedule it is now:
alpha 1: May 6, 2006 [planned]
alpha 2: June 3, 2006 [planned]
alpha 3: July 1, 2006 [planned]
beta 1: July 29, 2006 [pl
someone go through PEP 4 and 11 and determine what work needs to be done?
The more we distribute the work, the easier it will be on everyone.
You don't really want to listen to me whine any more do you? ;-)
Thank you,
n
PEP: 356
Title: Python 2.5 Release Schedule
Version: $Revision: 42375 $
Autho
On 2/15/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
> I haven't been following the AST stuff closely enough, but I'm not crazy
> about putting access to this in the sys module. It seems like it
> clutters that up with a name that will be rarely used by the average
> Python programmer.
Agreed.
On 2/15/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
> (is the xmlplus/xmlcore issue still an issue, btw?)
What issue are you talking about?
n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
On 2/15/06, Alain Poirier <[EMAIL PROTECTED]> wrote:
> - isn't the current implementation of itertools.tee (cache of previous
> generated values) incompatible with the new possibility to feed a
> generator (PEP 342) ?
I'm not sure what you are referring to. What is the issue?
n
___
On 2/15/06, Arkadiusz Miskiewicz <[EMAIL PROTECTED]> wrote:
>
> Still few questions... one of developers/commiters reviews patch and commit
> it? Few developers has to review single patch?
One developer can review and commit a patch. Sometimes we request
more input from other developers or intere
[Moving to python-dev]
I don't have a strong opinion. Any one else have an opinion about
removing --with-wctype-functions from configure?
n
--
On 2/16/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> neal.norwitz wrote:
> > Author: neal.norwitz
> > Date: Thu Feb 16 06:25:37 2006
> > New Revision:
On 2/17/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Tue, Feb 14, 2006 at 09:24:57PM -0800, Neal Norwitz wrote:
> > http://www.python.org/peps/pep-0356.html
>
> There is at least one SF bug, namely "#1333982 Bugs of the new AST
> compiler", that
On 2/17/06, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>
> I'm very sorry for my silliness. I do see the problem I was having now.
>Thank you for helping me out. I was assuming that PY_SSIZE_T_MAX
> could be used in a pre-processor statement like LONG_MAX and INT_MAX.
>
> In other words
>
http://www.python.org/dev/buildbot/
Whoever is first to break the build, buys a round of drinks at PyCon!
That's over 400 people and counting:
http://www.python.org/pycon/2006/pycon-attendees.txt
Remember to run the tests *before* checkin. :-)
n
___
On 2/17/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> >
> > I don't have a strong opinion. Any one else have an opinion about
> > removing --with-wctype-functions from configure?
>
> FWIW, I announced this plan in Dec 2004:
>
>
On 2/19/06, Benji York <[EMAIL PROTECTED]> wrote:
> Walter Dörwald wrote:
> > I'd like to see vertical lines between the column.
>
> I've done a version like that (still at http://www.benjiyork.com/pybb).
I liked your current version better so I installed it.
n
___
On 2/20/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Speaking as a PSF director, I might not vote for that :-) Fact is
> I've been keeping the build & tests 100% healthy on WinXP Pro, and
> that requires more than just running the tests (it also requires
> repairing compiler warnings and Unixisms
On 2/20/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> Perhaps a more informative message would be nice.
> Here's an easy way to trigger it:
>
> >>> compile("#-*- coding: ascii -*-\nprint 'ab%c'\n"%0x80, '','exec')
> Traceback (most recent call last):
>File "", line 1, in ?
> MemoryError
Th
On 2/21/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
>
> On 21-feb-2006, at 9:09, Neal Norwitz wrote:
>
> > Unfortunately, there are a ton of
> > warnings on OS X right now.
>
> How many of those do you see when you ignore the warnings you get
> while b
On 2/21/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Since the most fruitful variations (IME) for finding code errors are
> using -r and running a debug build too, I'd change the current
> run-all-the-time recipes to:
>
> - Stop doing the second "without deleting .py[co]" run.
> - Do one run with
On 2/21/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Neal> IMO compiler warnings should generate emails from buildbot.
> >
> > It doesn't generate emails for any other condition. I think it should just
> > turn the compilation section yellow.
>
> It would be
On 2/21/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>
> I agree with this, but don't know a clean way to do 2 builds. I
> modified buildbot to:
>
> - Stop doing the second "without deleting .py[co]" run.
> - Do one run with a debug build.
> - Use -ual
Martin and I were talking about dropping support for older versions of
Windows (of the non-NT flavor). We both thought that it was
reasonable to stop supporting Win9x (including WinME) in Python 2.6.
I updated PEP 11 to reflect this.
The Python 2.5 installer will present a warning message on the
On 2/20/06, Jiwon Seo <[EMAIL PROTECTED]> wrote:
> Regarding this Grammar change; (last October)
> from argument: [test '=' ] test [gen_for]
> to argument: test [gen_for] | test '=' test ['(' gen_for ')']
>
> - to raise error for "bar(a = i for i in range(10)) )"
>
> I think we sh
PEP 263 states that in Phase 2 the default encoding will be set to
ASCII. Although the PEP is marked final, this isn't actually
implemented. The warning about using non-ASCII characters started in
2.3. Does anyone think we shouldn't enforce the default being ASCII?
This means if an # -*- coding
On 1/24/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > I ran Fredrik's listmodules script in my current sandbox and got a
> > deprecation warning for the regex module. According to PEP 4 it is already
> > obsolete. I saw nothing
The following code leaks a reference. Original test case from
Lib/test/test_sys.py in test_original_excepthook.
import sys, StringIO
eh = sys.__excepthook__
try:
raise ValueError(42)
except ValueError, exc:
exc_type, exc_value, exc_tb = sys.exc_info()
eh(exc_type, None, None)
__
Yup. It's fixed.
n
--
On 3/3/06, Matthew Fleming <[EMAIL PROTECTED]> wrote:
> testCompileLibrary (__main__.CompilerTest) ... compiling
> /home/splitscreen/src/python/python/Lib/dircache.py
> compiling
> /home/splitscreen/src/python/python/Lib/smtplib.py
> compiling /home/splitscreen/src/python/py
On 2/27/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Neal plugged another hole later, but-- alas --I have seen the same shy
> failure since then on WinXP. One of the most recent buildbot test
> runs saw it too, on a non-Windows box:
>
> http://www.python.org/dev/buildbot/trunk/g5%20osx.3%20trunk/
On 3/10/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>
> BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine:
>
> http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0
>
> Is there a way to get the actual failures somehow? Running the tests i
On 3/13/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
>
> > > But I'm wondering if the actual "bugs" list was transmitted to Python
> > > developers,
> > > and verified / acted upon.
> >
> > and in case it wasn't clear from my previous post, the answer to
> > your specific quest
On 3/9/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Would it be a solution to move the 'official' ctypes development into
> Python SVN external/ctypes, or would this be considered abuse? Another
> location in SVN could be used as well, if external is though to contain
> only vendor drops...
Tho
On 3/13/06, Hye-Shik Chang <[EMAIL PROTECTED]> wrote:
> On 3/14/06, Jeff Epler <[EMAIL PROTECTED]> wrote:
> > After the recent discussion about Coverity, I took a look at one of the
> > checkins made, apparently based on output from their tool.
> >
> > http://svn.python.org/view/python/branches/rel
Unless I hear shouts *soon*, the following modules will be removed in 2.5:
reconvert.py
regex # regexmodule.c
regex_syntax.py
regsub.py
lib-old/* # these are the modules under lib-old
Para.py codehack.py fmt.py ni.pystatcache.py whatsound.py
addpack.py dircmp.pygrep.py
On 3/14/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Neal Norwitz]
> > ...
> > The public report says 15, but the current developer report shows 12.
> > I'm not sure why there is a discrepancy. All 12 are in ctypes which
> > was recently imported.
>
> I
Attached is an image from a coverity report for ctypes.
Here is the text:
3866val = Simple_get_value(self);
3867if (val == NULL)
3868return NULL;
3869
3870name = PyString_FromString(self->ob_type->tp_name);
Event var_compare_op: Added "
On 3/15/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> [Neal Norwitz]
> > This isn't exactly correct. On a 64-bit system, the value will be
> > cast into a 32-bit integer. This is true for both Win64 and Unix. If
> > you change the cast to a long and use %ld
I posted a message to c.l.p about the upcoming alpha 1.
Just in case anybody here's been snoozing, 2.5 alpha 1 is coming up
real quick, hopefully within a couple of weeks. If you have any
*major* features (particularly implemented in C) that you want to see
in 2.5, bring it up now. I want to str
On 3/18/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> svn got confused trying to incorporate updates to the email pkg. Slaves
>
> sparc solaris10 gcc trunk
> and
> x86 gentoo trunk
>
> got stuck in their trunk "updating" steps for 7 hours, presumably as a result.
>
> I killed those builds, a
On 3/18/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Christos Georgiou wrote:
> > I would like to know if supplying a patch for it sometime in the next couple
> > of weeks would be considered a patch (since the widget currently is not
> > working at all, its class in Tix.py contains just a pa
On 3/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> FYI, I have several non-major C components to go in but not in time for alpha
> 1.
> They include some minor fix-ups in the sets module, the str.partition
> function,
> add gc to itertools.tee, a couple of functions in binascii, add
> i
On 3/19/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> > If anyone sees spurious failures with the buildbot (one time failures,
> > crashes, etc), please report the problems to python-dev. It would be
> > great to see if you can reproduce the results with the same tests that
> > failed. We need to
On 3/22/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg wrote:
> > For the Snake-Farm we had a separate mailing list, so I'd prefer
> > that if possible. This lets you opt-in to the messages and also
> > makes it easier to search via the python.org search facility.
>
> I'll wait fo
On 3/23/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > M.-A. Lemburg wrote:
> >>> And we still have someone actively interested in maintaining the OS2
> >>> port, it seems.
> >>
> >> Dito for BeOS, now under the name Zeta OS.
> >
> > Who is the one interested in maintaini
On 3/23/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I have been looking into the (seemingly random) test_popen2
> failures today, and found that it fails when the tests
I played with this some last night and found the same ordering. I
have a different patch that also fixes the problem. It
[bcc python-dev to move to python-3000]
On 3/22/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
> "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
>
> > neal.norwitz wrote:
> >
> >> +Outstanding Issues
> >> +==
> >> +
> >> +* Require C99, so we can use // comments, named initializers, dec
Now that the buildbot is in place and seems to be running relatively
smoothly, maybe should consider making daily (or periodic) builds and
releasing them. We've got a system in place to build on many
platforms automatically. How much more difficult would it be to
package up the results and make t
http://python.org/sf/1458927 asks if -Q warn option should become the
default in 2.5. PEP 238 (http://www.python.org/dev/peps/pep-0238/)
says:
"""
The -Q command line option takes a string argument that can take four
values: "old", "warn", "warnall", or "new". The default is "old" in
Python 2.2
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, 10] references
test_pkgimport leaked [2, 2, 2] references
test_traceback leaked
201 - 300 of 523 matches
Mail list logo
