We've made a lot of progress with the tests. Several buildbots are
green. http://python.org/dev/buildbot/3.0/
There are some tests that are unstable, at least:
test_asynchat test_urllib2net test_xmlrpc
http://python.org/dev/buildbot/3.0/g4%20osx.4%203.0/builds/170/step-test/0
http://python.or
On 10/30/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > for a, b in zip(self.data, other.data):
> > result = richcmp(a, b, ordered)
> > if result:
> > return result
>
> That can't be right, because there are *three*
Steven Bethard wrote:
> If a class defines only __cmp__, Python will do the appropriate
> dance to make <, >, ==, etc. work right. If a class defines only
> __eq__, __lt__, etc. Python will do the appropriate dance to make
> cmp() work right.
With a four-way __cmp__, I wouldn't actually mind if
t
Adam Olsen wrote:
> for a, b in zip(self.data, other.data):
> result = richcmp(a, b, ordered)
> if result:
> return result
That can't be right, because there are *three* possible
results you need to be able to distinguish from compari
Steven Bethard wrote:
> class C(object):
> def __cmp__(self, other):
> if self.foo < other.foo:
> return -1
> elif self.foo < other.foo:
> return 1
> else:
> return 0
With __cmp__, in cases like that yo
On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > I'm actually currently in favor of keeping __cmp__ as it is in Python
> > 2.5. If a class defines only __cmp__, Python will do the appropriate
> > dance to make <, >, ==, etc. work right. If a class defines only
> > __eq__, __lt__, etc. Pytho
On 10/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On 10/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > > On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > > cmp and __cmp__ are doomed, due to unorderable types now raising
>
On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 10/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > cmp and __cmp__ are doomed, due to unorderable types now raising
> > > exceptions:
> > >
> > > >>> cmp(3, 'hello')
> > > Tracebac
On 10/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > cmp and __cmp__ are doomed, due to unorderable types now raising exceptions:
> >
> > >>> cmp(3, 'hello')
> > Traceback (most recent call last):
> > File "", line 1, in
> > TypeError: u
On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> cmp and __cmp__ are doomed, due to unorderable types now raising exceptions:
>
> >>> cmp(3, 'hello')
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: unorderable types: int() < str()
> >>> 3 == 'hello'
> False
>
> A mixi
On 10/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > It's clear to me that the opposition to removing __cmp__ comes down to
> > "make the common things easy and the rare things possible". Removing
> > __cmp__ means one of the common things
On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> It's clear to me that the opposition to removing __cmp__ comes down to
> "make the common things easy and the rare things possible". Removing
> __cmp__ means one of the common things (total ordering) becomes hard.
I don't really think that's it
On 10/30/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > It'd be simpler still if we only had __cmp__ and __eq__. I just don't
> > understand the use cases where that's not sufficient.
> >
> > Hrm. I guess set's subset checking requires more relationships than
> > __cmp__ provid
Adam Olsen wrote:
> It'd be simpler still if we only had __cmp__ and __eq__. I just don't
> understand the use cases where that's not sufficient.
>
> Hrm. I guess set's subset checking requires more relationships than
> __cmp__ provides.
Also, you might want to give the comparison operators mea
> Also, IMO the Mac-specific stuff was a lot more important before OSX.
>
> The really interesting Mac stuff is the ObjC bridge which is not
> maintained here anyway.
I'm not so sure about that. The IC module, for instance, plugs into
the Internet Config on the Mac, so you can read things like p
> But if we remove SocketCloser, there's no need for the cyclic GC to be
> involved. If the count (of the number of outstanding SocketIO
> instances pointing to this socket.socket) is just moved into the
> socket.socket object itself, there's no cyclic reference, and normal
> refcounting should wo
Also, IMO the Mac-specific stuff was a lot more important before OSX.
The really interesting Mac stuff is the ObjC bridge which is not
maintained here anyway.
--Guido
2007/10/30, Brett Cannon <[EMAIL PROTECTED]>:
> On 10/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > 2007/10/27, Bill Jan
On 10/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 2007/10/27, Bill Janssen <[EMAIL PROTECTED]>:
> > > ISTR much of the plat-mac stuff was generated by Tools/bgen. If so, that
> > > would be the place to fix things.
> >
> > Sure looks like generated code. Be nice if that generator was run
> > I don't think it's just SSL. The problem is that it explicitly counts
> > calls to "close()". So if you let the GC sweep up after you, that
> > close() just doesn't get called, the circular refs persist, and the
> > resource doesn't get collected till the backup GC runs (if it does).
> > Wait
2007/10/30, Bill Janssen <[EMAIL PROTECTED]>:
> Indeed. The httplib code is relying on the fact that close(), under
> certain circumstances, has no effect. It's just that the
> circumstances have changed, in Python 3K. I think that the close() in
> HTTPConnection should be removed.
I'd like to
> Bill Janssen wrote:
>
> > Back to your initial mail (which is
> > more relevant than Greg Ewing's snipe!):
Actually, Bill Janssen didn't write that, but did write this:
> > then in some
> > cases *closes* the socket (thereby reasonably rendering the socket
> > *dead*), *then* returns the "file
21 matches
Mail list logo
