Phillip J. Eby wrote:
> At 06:13 PM 7/9/2007 +0300, Guido van Rossum wrote:
>> On 7/9/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> > At 09:03 PM 7/9/2007 +1000, Nick Coghlan wrote:
>> > >However, I will point out that setting class attributes via
>> locals() is
>> > >formally undefined (it hap
One of the most daunting tasks remaining for Python 3.0a1 (to be
released by the end of August) is fixing the remaining failing unit
tests in the py3k-struni branch
(http://svn.python.org/view/python/branches/py3k-struni/).
This is the branch where I have started the work on the
string/unification
Guido van Rossum wrote:
> Please help!
I've made a meta patch that makes debugging the bugs a lot easier. It
replaces assert_(foo == bar) and failUnless(foo == bar) with
failUnlessEqual(foo, bar). failUnlessEqual shows the value of foo and
bar when they are not equal.
http://www.python.org/sf/175
On 7/10/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Please help!
>
> I've made a meta patch that makes debugging the bugs a lot easier. It
> replaces assert_(foo == bar) and failUnless(foo == bar) with
> failUnlessEqual(foo, bar). failUnlessEqual shows the value of
Steven Bethard wrote:
> I'd probably go with something a little more restrictive, maybe:
>
> r'self.assert_\(\S+ == \S+\)'
>
> Something like that ought to have fewer false positives.
Woops! You are right. Even your pattern has caused some false positives
but I've reread the patch and remove
I found a bug in the str type that may affect a lot of tests.
In the py3k-struni branch the str() constructor doesn't use __str__ when
the argument is an instance of a subclass of str. A user defined string
can't change __str__(). The __repr__ method isn't affected.
It works in Python 2.5 and in
Please use self.assertEqual() instead of self.failUnlessEqual() -- the
assertEqual() form is much more common. Otherwise, good idea!
On 7/11/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > I'd probably go with something a little more restrictive, maybe:
> >
> > r'se
