On 9/6/05, Steven Bethard [EMAIL PROTECTED] wrote:
I'd also prefer something along the lines of Fredrik's suggestion, but
I don't write enough C code to understand Paul's last point. Could
someone briefly explain why mixins wouldn't work in C code?
I had in mind it would be complicated and
Fredrik Lundh wrote:
(you completely missed the point -- today's print mechanism works on *any*
object
that implements a write method, no just file objects. saying that oh, all
you need is
to add a method or here's a nice mixin doesn't give you a print
replacement)
While we're on the
Greg Ewing wrote:
(you completely missed the point -- today's print mechanism works on *any*
object
that implements a write method, no just file objects. saying that oh,
all you need is
to add a method or here's a nice mixin doesn't give you a print
replacement)
While we're on the
On 9/6/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
Greg Ewing wrote:
While we're on the subject, in Py3k I'd like to see
readline(), readlines(), etc. removed from file objects
and made builtin functions instead. It should only
be necessary to implement read() and write() to get
a
Fredrik Lundh wrote:
maybe some variation of
http://www.python.org/peps/pep-0246.html
combined with default adapters could come in handy here ?
I really hope we can get by with something much less
heavyweight than that. I'm far from convinced that
something like PEP 246 proposes is
[Greg Ewing]
While we're on the subject, in Py3k I'd like to see
readline(), readlines(), etc. removed from file objects
and made builtin functions instead. It should only
be necessary to implement read() and write() to get
a file-like object having equal status with all
others.
[Fredrik
Steven Bethard wrote:
Could
someone briefly explain why mixins wouldn't work in C code?
Depends on what you mean by work in C code. It's only
possible for a type object to inherit C struct members
from one base class, since the struct has to be an
extension of the base C struct. Dynamic
