At 01:43 2003-01-24 +0100, Christian Tismer wrote:
Scott Fenton wrote:
Hello all. While trying to mix up some more stuff for __builtin__, I came up with an interesting problem. The solution I found for classmethod (using google on c.l.python, since I couldn't figure it out myself) requires that classes that use it must derive from object.
No, this is not true. classmethod works for every kind of class, may it be a newstyle class, triggered by - deriving from object - using __slots__ - deriving from a builtin type or a descendant - did I forget something? or a "classic" class, it always works. For reference, see http://www.python.org/2.2/descrintro.html
That made me wonder, could we just automatically derive everything from object in Minimal? The big problem with doing this in CPython, as I understand it, is extensions that need to be converted, but we don't have that problem here, obviously. So would it be alright if I went ahead and used this code as if everything derived from object?
No, sorry. object is just a special case for deriving a new-style class, see above. They can also be created by deriving from builtin types, or by using __slots__.
Furthermore, I'm going to propose an extension to the new class system (at least for the MiniPy prototype) that goes a bit further: - __slots__ should get the ability to denote the type of a slot to be generated, especially ctypes types - it should be possible to derive a class from nothing, not even from object or classic, but I'd like to describe a plain C structure by classes.
The latter will allow to define the object class and all builtin types with the same machinery.
I have some thoughts for decribing C structures (and anything else digital) in a canonical abstract way. I'll call such a decription a meta-representation, and a function that produces it from a Python object is meta_repr(python_object) => meta_rep_obj. The reverse operation is meta_eval ;-) The basis for meta_repr is that it capture and meta-represent (type, id, value) for an object in a pure abstract form. The abstract basis for storing the information is a bitvector object with attribute names that specify slices of the bitvector. I.e., there is an effective dict like {'slicename':(lo,hi)} and __getattr__ uses it so that bvec.slicename refers to bvec[lo:hi] etc. This is pure and abstract data, but you can see that interpreted little-endianly you can very straightforwardly lay out a C struct with whatever field widths and alignments you want. I also want to make a way to create subclasses of the base bitvector class that can have specified size and named slices as class variable info shared by instances. This is very analogous to a C struct definition, and BTW also permits union by just defining overlapping named slices. BTW2, there is also a natural way to iterate based on a slice name -- i.e., just walk successive contiguous same-size slices to some limit, starting with the one defined by a name (which doesn't have to start at bit 0 of the whole, of course, so you can get embedded arrays of bit fields starting anywhere). Hence a giant bitvector with a slice defined by byte=(16,24) could iterate in 8-bit bytes starting at bit 16. meta_eval-ing such a byte sequence meta-representation together with type and id would produce a Python character or string. If Psyco could deal with these meta_representations in a fine-tuned way, it might be possible to have very abstract representations of things and yet generate efficient bit-twiddling assembler level stuff, and, as you said, one consistent mechanism. One nice thing would be to be able to define machine instructions in terms of a few classes for different basic formats, with particular bit fields named right out of the book. Same for floating point doubles, etc. Packing code would be appending bit vectors, etc. Fortunately intel is little-endian, so there is a simple mapping to the most common machine stuff, but even if that were not so, the correspondence between an abstract bit list and an abstract integer represented as an ordered set of binary coefficients for powers of 2 just naturally sums little- endianly by sum=0; for i in range(len(bitvec)): sum += bitvec[i]*2**i Though of course that's not the most efficient way to compute it. Anyway, this meta-repr/meta_eval idea is only half baked, but in case you wanted to consider it, I wanted to offer it before you are all finished ;-) There is a bitvec.py in an old demo directory that I think I will cannibalize for a good deal of bit vector stuff, though I think I would want to base the data in a final version on arrays of ints that would map more naturally to arrays of machine ints instead of using Python longs. But for prototyping it doesn't matter. I still have to mull the class factory or perhaps metaclass stuff for creating classes whose instances will share bit slice name definitions. Also the best way to capture nested composition and naming or whole and sub-parts, when it's done by composition instead of one flat definition. BTW, it seems pickling and marshalling are also quite related, but I haven't thought about that. Interestingly, meta_repr produces a python object, so what does, e.g., meta_repr(meta_repr(123)) produce? It has to make sense ;-) I am mulling the encoding of type and id along with value into some composite meta_repr representation to represent a full object... Also the meaning of mixed structures, like an ordinary Python list of objects produced by meta_repr. It should be legal, but you have to keep the tin foil in good repair ;-) Please use what might further the project, and ignore the rest. But besides the possible use PyPython, would named-slice abstract bit vectors have a chance as a PEP as a way to express fine grain abstract digital info? Best, Bengt