Thinking about this some more, the io module isn't thread-safe. It
probably should be (the old file objects were more-or-less
thread-safe, although I believe there might've been corner cases if
one thread were to close a file).
--Guido
2007/10/27, Bill Janssen <[EMAIL PROTECTED]>:
> No, not unles
__index__() converts an "int-like" object to an int. This is needed to
make sure that e.g. numpy integral scalars can be used for indexing.
For a regular int it doesn't matter, so here it's a red herring.
I'm asking about b because the error message "TypeError: 'slice'
object does not support item
2007/10/28, Brett Cannon <[EMAIL PROTECTED]>:
> On 10/28/07, James Thiele <[EMAIL PROTECTED]> wrote:
> > PEP 361 lists __bool__ support as being possible for 2.6 backporting.
> > As of today the trunk build uses __nonzero__ like 2.5 but 3.0 alpha
> > uses __bool__. Has a decision been made on wheth
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
> during the build process, on OS X. That way you'd be sure to ge
2007/10/29, Fred Drake <[EMAIL PROTECTED]>:
> On Oct 29, 2007, at 2:40 PM, James Thiele wrote:
> > So just to clarify:
> > 2.6 __nonzero__ first, then __bool__ (if patch submitted)
> > 3.x __bool__ first, then __nonzero__
>
> I'd expect switching the order for this to be a bug magnet. I'd much
> r
2007/10/28, Bill Janssen <[EMAIL PROTECTED]>:
> > Bill Janssen wrote:
> > > that whole mess of code is a good argument for *not* exposing the
> > > fileno in Python
> >
> > Seems to me that a socket should already *be* a file,
> > so it shouldn't need a makefile() method and you
> > shouldn't have
On Oct 29, 2007, at 2:40 PM, James Thiele wrote:
> So just to clarify:
> 2.6 __nonzero__ first, then __bool__ (if patch submitted)
> 3.x __bool__ first, then __nonzero__
I'd expect switching the order for this to be a bug magnet. I'd much
rather see:
2.5 __nonzero__ only
2.6 __bool__ first, th
So just to clarify:
2.5 __nonzero__ only
2.6 __nonzero__ first, then __bool__ (if patch submitted)
3.x __bool__ first, then __nonzero__
Is this correct?
On 10/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 2007/10/28, Brett Cannon <[EMAIL PROTECTED]>:
> > On 10/28/07, James Thiele <[EMAIL P
I think several postings have explained better than I have on why __cmp__ is
still very valuable. (See below.)
Guido van Rossum posted earlier that he was willing to entertain a PEP to
restore __cmp__, so I've attempted to create a draft PEP, posted here:
http://www.dwheeler.com/misc/pep-cmp.
2007/10/29, James Thiele <[EMAIL PROTECTED]>:
> So just to clarify:
> 2.5 __nonzero__ only
> 2.6 __nonzero__ first, then __bool__ (if patch submitted)
> 3.x __bool__ first, then __nonzero__
>
> Is this correct?
No. 3.x tests __bool__ only.
> On 10/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote
On Oct 29, 2007, at 2:51 PM, Guido van Rossum wrote:
> Makes sense, if you change the 3.x rule to
>
> 3.x __bool__ only.
Even better! I think I'm going to like 3.0 if I ever get a chance to
use it. ;-)
-Fred
--
Fred Drake
___
Python-3000
> I'm asking about b because the error message "TypeError: 'slice'
> object does not support item deletion" would suggest that b is a slice
> object. I agree that doesn't sound very likely given the code
> though... :-( Could you step through this using pdb and investigate
> some more? Perhaps ther
> The SocketCloser class wasn't written with
> the SSL use case in mind.
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 g
On 10/29/07, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> I think several postings have explained better than I have on why __cmp__ is
> still very valuable. (See below.)
>
> Guido van Rossum posted earlier that he was willing to entertain a PEP to
> restore __cmp__, so I've attempted to create
> Actually, I'm still up for tweaks to the I/O model if it solves a real
> problem, as long as most of the high-level APIs stay the same (there
> simply is too much code that expects those to behave a certain way).
>
> I don't quite understand what you mean by inverted though.
I'm actually thinkin
2007/10/29, Bill Janssen <[EMAIL PROTECTED]>:
> > Actually, I'm still up for tweaks to the I/O model if it solves a real
> > problem, as long as most of the high-level APIs stay the same (there
> > simply is too much code that expects those to behave a certain way).
> >
> > I don't quite understand
2007/10/29, Bill Janssen <[EMAIL PROTECTED]>:
> > The SocketCloser class wasn't written with
> > the SSL use case in mind.
>
> 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 calle
I'm a bit too busy to look into this right now; I hope one or two more
rounds of feedback on the PEP will get it into a state where I can
review it more easily. Having a patch to go with it would be immensely
helpful as well (in fact I'd say that without a patch it's unlikely to
happen).
--Guido
On 10/29/07, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> I think several postings have explained better than I have on why __cmp__ is
> still very valuable. (See below.)
>
> Guido van Rossum posted earlier that he was willing to entertain a PEP to
> restore __cmp__, so I've attempted to create
> Really? AFAIK everyone who opens a socket calls it.
Sorry, I meant only a handful (10?) in the standard library.
> I'd be okay with calling the class Socket and having a factory
> function named socket though.
Ah, good idea.
Bill
___
Python-3000 mai
And for non-unicode inputs the code should use the PEP 3118 buffer API
rather than PyBytes_ or PyString_ or whatnot.
On 10/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> 2007/10/26, Bill Janssen <[EMAIL PROTECTED]>:
> > I'm looking at the Py3K SSL code, and have a question:
> >
> > What's
David A. Wheeler wrote:
> Greg Ewing stated "Why not provide a __richcmp__ method that directly connects
> with the corresponding type slot?
> It _seems_ to me that this is the same as "__cmp__",
No, it's not -- a __richcmp__ method would take an extra
argument specifying which of the six compari
James Thiele wrote:
> 3.x __bool__ first, then __nonzero__
Does 3.x need __nonzero__ at all?
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/opt
2007/10/29, Greg Ewing <[EMAIL PROTECTED]>:
> I wrote:
>
> > Seems to me that a socket should already *be* a file,
> > so it shouldn't need a makefile() method and you
> > shouldn't have to mess around with filenos.
>
> Guido van Rossum wrote:
>
> > That model fits TCP/IP streams just fine, but
I wrote:
> Seems to me that a socket should already *be* a file,
> so it shouldn't need a makefile() method and you
> shouldn't have to mess around with filenos.
Guido van Rossum wrote:
> That model fits TCP/IP streams just fine, but doesn't work so well for
> UDP and other odd socket types.
2007/10/29, Greg Ewing <[EMAIL PROTECTED]>:
> David A. Wheeler wrote:
> > Greg Ewing stated "Why not provide a __richcmp__ method that
> > directly connects with the corresponding type slot?
>
> > It _seems_ to me that this is the same as "__cmp__",
>
> No, it's not -- a __richcmp__ method would ta
Adam Olsen wrote:
> It's not clear to me how many distinct operations you'd need though,
> or how acceptable reflections would be.
My intention was just to directly expose the tp_richcmp
slot, so there would be six.
To make things easier in the common case, there could
perhaps be a utility functi
Guido van Rossum wrote:
> having read()
> and write() methods on the _socket object is not the solution.
It's not a necessary part of the solution, I agree.
I just don't see what purpose is served by requiring
an extra layer of wrapper between a socket and the
other I/O layers. That's not a necess
Guido van Rossum wrote:
> That's because I don't find the synonyms a good idea.
Even if it means that stream sockets then have the
same interface as all other stream-like objects in
the I/O system, so buffering layers can be used on
them, etc.? That seems like a rather good reason to
me.
If you
2007/10/29, Greg Ewing <[EMAIL PROTECTED]>:
> Guido van Rossum wrote:
>
> > That's because I don't find the synonyms a good idea.
>
> Even if it means that stream sockets then have the
> same interface as all other stream-like objects in
> the I/O system, so buffering layers can be used on
> them,
On 10/29/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > It's not clear to me how many distinct operations you'd need though,
> > or how acceptable reflections would be.
>
> My intention was just to directly expose the tp_richcmp
> slot, so there would be six.
>
> To make things e
On 10/29/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 10/29/07, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> > I think several postings have explained better than I have on why __cmp__
> > is still very valuable. (See below.)
> >
> > Guido van Rossum posted earlier that he was willing to e
32 matches
Mail list logo
