Yes, this was previously "inheriting basic types more efficiently" but
now I want something different ;)
I looked at the array type and found it quite C-ish. It is also not
suited for arithmetics because it's a sequence type like a constrained
list and not efficiently (and comfortably) usable like
On Thu, 27 Apr 2006 07:20:47 +0200
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Dennis Heuer wrote:
> > The reason why I'd like to use the long type as the base of my bitarray
> > type is that the long type is already implemented as an array and
> > work
ues and pass them on to the called method/attribute.
Do you now understand the case?
Dennis
On Wed, 26 Apr 2006 10:47:55 -0700
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> I doubt you'll get many answers. I have no idea what you're talking
> about. How about
To bring the real problem more upfront. Up to now, inheriting classes
is all about processing (the output channel) but not about retrieving
(the input channel). However, though a new type can advance from an
existing type if it just needs to provide some few more methods, it can
not advance from an
Have never seen such an answer before. Please excuse if I read it
wrong. The method would just return the new values, for shure. That is
what it shall do. The interpreter calls that method for receiving the
new (to be used) values to pass them on to the real target (the called
attribute). The metho
There's also a difflib though the module doesn't look like a wrapper
for diff. The math module is not called mathlib though. Python is
quite inconsistent here. On the one hand it tries to use
human-understandable terms and on the other hand it takes the easy
approach, which means it falls back to c
I often experiment with touring machine algorithms and play around with
alternative arithmetics. I'd like to do that with python but it offers
only the standard bitwise operators. They're fine if one wants to do
manipulations on the full integer. However, I'd like to have direct
(single) bit access
I read the python 2.5alpha release notes and found that some module and
class names should not make it into the official release. For example,
the name of the ctypes module is ok because the module is only of
special interest, but calls like py_object or create_string_buffer
should definetly be cha
