Mailman 3 August 2001 - Edu-sig

Re: [Edu-sig] Simple frame buffer module
by Chris Meyers 27 Aug '01

27 Aug '01

Hi Dave, I played around with this a bit over the weekend. I'd like to use it in my class this fall. We're (unfortunately) on a win32 setup but I got it going with a couple of hacks. If you don't already have one, I could clean it up and send you a "cfb" binary download for windows folks that don't have a C compiler or want to mess with it. One little thing. The window does not repaint when moved or uncovered. Is it possible to remedy this easily? I don't know anything about SDL programming, although this is helping me to start learning. Thanks Chris Meyers BTW it took me a bit to figure out what in the world you were doing with the exclusive OR stuff in your line generation code. When I did it took me back to the machine code daze. 08/24/2001 9:42:19 PM, David Pettersson <dave(a)whatever.nu> wrote: >Hi, > >I'd like to announce the simple frame buffer module that I wacked >together after being fed up with having to create a GUI every time I >wanted to illustrate something simple in Python (such as the iterative >improvement of some problem). A short sample: > > import fb # import module > f = fb.FrameBuffer() # create an instance > f.open(200, 200, "demo") # open a window named "demo" > for i in range(10, 190): # simple loop > f.fg = (i, i, i) # set fg colour > f.plot(i, i) # plot > f.flip() # flip buffers > raw_input('enter to quit') # wait for keypress > f.close() # close window > >Could be useful if you want students to be able to create simple >graphics without having to teach them a GUI. The extension uses SDL to >manage the graphics. The extension is available at > > http://dave.whatever.nu/python/fb/ > >Comments, suggestions and bug reports are all very welcome :). > >Sincerely, >-- >David Pettersson >dave(a)whatever.nu > >_______________________________________________ >Edu-sig mailing list >Edu-sig(a)python.org >http://mail.python.org/mailman/listinfo/edu-sig >

2 1

Class methods in 2.2a2
by Kirby Urner 27 Aug '01

27 Aug '01

Self-less classes: it's now possible to define methods with no self argument. The methods may be invoked even with no instance of the class being created: >>> class foo: ... def add(a,b): ... return a+b ... add = staticmethod(add) ... >>> foo.add(3,4) 7 >>> g = foo() >>> g.add(1,2) 3 Yes, I've been reading the PEPs -- obviously. E.g.: http://python.sourceforge.net/peps/pep-0253.html Kirby

2 1

More introspection w/ Python 2.2a2
by Kirby Urner 26 Aug '01

26 Aug '01

More introspection in Python 2.2a2: >>> t = type(3) >>> t <type 'int'> t is a metaclass, the type of 3, i.e. an integer. You can create a new instance of an integer by calling the integer type: >>> t() 0 >>> t(1) 1 These instances are type integer: >>> type(t(1)) <type 'int'> But the type object that gets returned as <type 'int'> is an instance of type, a metaclass: >>> t.__class__ <type 'type'> Using the introspection function from the last post: >>> ls(t) ['__module__', '__bases__', '__itemsize__', '__dynamic__', '__hash__', '__str__', '__weakrefoffset__', '__dict__', '__name__', '__cmp__', '__init__', '__setattr__', '__basicsize__', '__new__', '__base__', '__flags__', '__class__', '__getattr__', '__mro__', '__delattr__', 'mro', '__repr__', '__dictoffset__', '__call__', '__defined__', '__doc__'] These are the methods of the type metaclass -- nothing to do with integers per se. >>> t.__module__ '__builtin__' The type metaclass is itself a subclass of a yet more generic type object. >>> t.__bases__ (<type 'object'>,) >>> z = t.__bases__[0] >>> ls(z) ['__module__', '__bases__', '__itemsize__', '__dynamic__', '__hash__', '__str__', '__weakrefoffset__', '__dict__', '__name__', '__cmp__', '__init__', '__setattr__', '__basicsize__', '__new__', '__base__', '__flags__', '__class__', '__getattr__', '__mro__', '__delattr__', 'mro', '__repr__', '__dictoffset__', '__call__', '__defined__', '__doc__'] Seems to be the same basic animal. What are __flags__ ? Hell if I know: >>> t.__flags__ 4603 >>> t.__new__ <built-in method __new__ of type object at 0x80e3620> I've been hearing about this __new__ thingy. Anyone want to elucidate? All ears. Kirby

1 0

Introspective Python
by Kirby Urner 26 Aug '01

26 Aug '01

Here's some Python demonstrating introspection: the function ls takes and object and spits out the keys from its class dictionary, containing a list of methods for that object. Below: list and string objects spill their guts: >>> def ls(obj): ... return getattr(obj.__class__,'__dict__').keys() ... >>> ls([]) ['sort', '__ne__', '__getattr__', '__getslice__', '__delitem__', '__mul__', '__str__', '__getitem__', 'pop', '__class__', '__setitem__', '__iadd__', '__add__', '__gt__', '__rmul__', '__lt__', '__ge__', '__eq__', 'append', '__imul__', 'extend', 'insert', '__setattr__', 'reverse', '__contains__', 'index', '__setslice__', 'count', 'remove', '__delattr__', '__le__', '__init__', '__hash__', '__new__', '__len__', '__repr__'] >>> ls('s') ['upper', '__getslice__', '__ne__', 'lstrip', '__str__', 'replace', 'isdigit', 'endswith', 'splitlines', 'rfind', 'strip', '__rmul__', '__lt__', 'ljust', 'find', '__init__', 'index', '__setattr__', '__new__', 'isalnum', '__contains__', 'rindex', '__eq__', '__class__', '__getattr__', 'decode', 'isalpha', 'split', 'rstrip', 'encode', 'translate', 'istitle', '__len__', '__mul__', 'startswith', '__getitem__', 'rjust', 'swapcase', 'islower', '__add__', '__gt__', 'capitalize', 'count', 'lower', 'join', 'center', 'title', 'expandtabs', 'isspace', '__delattr__', '__le__', '__repr__', '__hash__', 'isupper', '__ge__'] Kirby

1 0

Simple frame buffer module
by David Pettersson 24 Aug '01

24 Aug '01

Hi, I'd like to announce the simple frame buffer module that I wacked together after being fed up with having to create a GUI every time I wanted to illustrate something simple in Python (such as the iterative improvement of some problem). A short sample: import fb # import module f = fb.FrameBuffer() # create an instance f.open(200, 200, "demo") # open a window named "demo" for i in range(10, 190): # simple loop f.fg = (i, i, i) # set fg colour f.plot(i, i) # plot f.flip() # flip buffers raw_input('enter to quit') # wait for keypress f.close() # close window Could be useful if you want students to be able to create simple graphics without having to teach them a GUI. The extension uses SDL to manage the graphics. The extension is available at http://dave.whatever.nu/python/fb/ Comments, suggestions and bug reports are all very welcome :). Sincerely, -- David Pettersson dave(a)whatever.nu

3 2

RE: [Edu-sig] RE: [Tutor] Off topic musings
by Morris, Steve 22 Aug '01

22 Aug '01

> On 20 Aug 01, at 22:06, Morris, Steve wrote: > > Maybe. Really I'm just interested in what exactly a > > theoretical basis for software engineering would look like. I think my problem with this discussion, and the cause of the different approaches, is that you ask your question in ambiguous terms. You ask for a "theory of everything" in the generic category of software engineering. Software engineering is not a science but a discipline, or perhaps a skill, or maybe just programming. The term 'software engineering" usually refers to the process of writing programs with the imputation that these programs match some standard; whether it be correctness, or matching the specs, or merely being useful. It is thus not suprising that we keep getting lost in the process and techniques of programming. That statement is almost a tautology. What else would a theory of "software engineering" address. I would like you to restate your query with a better idea of the specific questions you are trying to answer. I know what specific questions a "unified field theory" is trying to answer. What question are you trying to answer?

3 4

RE: [Edu-sig] RE: [Tutor] Off topic musings
by Morris, Steve 21 Aug '01

21 Aug '01

> > Maybe. Really I'm just interested in what exactly a theoretical > > basis for software engineering would look like. The papes I was > > reading suggested that we may be reaching the point in CS > > research where we cannot progress further without an underlying > > theoretical base (like electrical theory underpins > > electronics which > > is in turn underpinned by atomic/molecular/ionic theory). I think you are comparing apples and oranges here. I think your vision of software engineering is too narrow. Electrical theory explains a finite set of observed electrical properties. Software is a language that can express too much to be stated in a single theory. It is too expressive. You might as well try to make a general theory of communication which covers all possible communication, speech, evocation, persuasion, poetry, art and expression. Software engineering would then be a substantial subset of this general theory. In order to have a meaningful theoretical discussion you must break down the subject into a finite set of rational observable components with observable relations between them. You then attempt theories to explain what you observe. The problem with communication (of which software engineering is a subset) is that it is infinitely extensible. As long as there are new areas of software problems to solve we can't put a bound on it. It is not even clear what you mean when you ask what a "theoretical basis of software engineering would look like." Engineering doesn't have theories. Science has theories; engineers apply these theories to solve specific problems. You would do better to think of a specific aspect of software engineering that you think needs explaination. Without specific questions you will never have useful theories. When you narrow your self to specific questions you will likely find plenty of literature that discuss them. Be careful or you will fall down the rabbit hole that has swallowed literary criticism, chasing meaningless but pretty ideas that go nowhere, lost in endless reflections of ideas that seem like they must mean something but can't be nailed down. This is the curse of language, many more things can be said than have meaning. You don't start with a theory, you start with specific questions and observations that need explaination. Theories provide possible and hopefully testable explainations. The results suggested by these theories, once validated as useful and predictive, can be the basis for the next level of theories. Let me give a specific example. You don't ask for a theory of physics. Physics is too general a thing to have one theory. On the other hand we have a set of theories which describe various fields; gravitation, electromagnetic, strong and weak forces. These theories are pretty mature and usefully and predidictively explain the specific fields. These field theories have a lot in common and now that they are well developed and tested it is worthwhile looking for a unified field theory in which the specific fields are merely special cases. Physicists have been hoping for this one for 80 years. You try to build a general theory when the specific theories are well understood. This does not describe the condition of software engineering or even of so called "computer science."

5 5

Re: Off topic musings
by Matthias Felleisen 20 Aug '01

20 Aug '01

Hi Alan -- you are basically promoting the idea of driving program design via data descriptions. That is, since a program processes information, the laws of designing programs should be connected to the laws of describing information. In my terminology, information is what you find in the real world. Data is something in your language of choice that represents information. For example, in Fortran you may use 5 to represent 5cm, 5C, or $5. Over the past 30 years or so, PL designers have developed a basic language of data composition. It comes with a set of primitive operations (creation of data, extraction of values from compound data, mutation of data, recognition). The ideas (in pure form) are more or less based on the interpretation of set theory by the designer, and are thus more or less independent of the actual language (if it avoids connection between values and machine notions). One can indeed use a data description to derive programs, step by step. Our book for the TeachScheme! project (programming for high school students) is based on exactly this idea. Take a look, we distribute the book over the Web: http://www.htdp.org/ but you can also buy it :-) See the design recipes. They carry over to other FP-like languages, such as Python. I have worked with the idea for 15 years. They were developed in the functional programming community (starting with Burge's book in the early 70s). The community wasn't so much interested in correctness but in the systematic construction of programs. The layering of the idea was expounded in great detail in Abelson-and-Sussman's famous SICP. It's also on-line now. In contrast, the Hoare-Dijkstra-Gries school of thought was interested in correct algorithms. When you work in their (wp or sp) logic, you write the program first -- in an ad hoc manner, w/o any underlying laws -- in an extremely low-level quasi-functional language of logic. Then you derive the program again, by hand. One could some of that via machine. In any case, their work never truly scaled beyond procedure bodies, because they couldn't get anythig but :=, begin, while, and if to work completely. [Okay, I know there is more, but don't bother me with details. That's the gist of it.] -- Matthias

1 0

RE: [Tutor] Off topic musings
by alan.gauld＠bt.com 20 Aug '01

20 Aug '01

> > One recurring theme in these "State of the Practice" papers > > was the lack of a fundamental theoretical basis for computing. > > i.e. there's nothing comparable to the laws of physics in > > software engineering. > > David Gries has written a book called "The Science of > Programming" which states a framework for writing mathematicaly correct > programs. Yes, there are many books and papers on programming correctness but few on the nature of information. Specifically I am intereted in any work on layering of information structures. Looking at how information itself is structured and operated upon. This is different to programming which is only one very narrow subset ofg information processing. Alan g.

4 5

Off topic musings
by alan.gauld＠bt.com 20 Aug '01

20 Aug '01

Some time ago I posted the following musings to my work colleagues and a few of us chased it around for a while. I came across it recently and thought the ideas might be of some interest to the members of these lists. If anyone knows of resources please let me know... ----------- Included text --------------- I read a collection of papers on Software Engineering recently published by the IEEE and edited by Professor Richard Thayer (and his friend). One recurring theme in these "State of the Practice" papers was the lack of a fundamental theoretical basis for computing. i.e. there's nothing comparable to the laws of physics in software engineering. I started thinking and doodling about what the fundamentals are and came up with several notions (ideas would imply something far too well formed!) These are based around the concept that software manipulates data or more correctly "information"(no surprises there! :). However most information theory (Shannon et al) relates to bits. Far too low level to be useful. That started me thinking about levels of information and I came up with 3 layers of information - rather like an OSI comms model: 1/ Physical - bits/bytes, defined by the machine architecture operations are CPU specific, include bitwise OR/AND/NOT and binary arithmetic... 2/ Implementation/Environment - data types defined by the programming environment - object in Smallktalk; int, float, char in C etc... Operations include built in operators for arithmetic, boolean logic and I/O. [Question: Where do collections: arrays, lists etc fit into the layer proposal?] 3/ Application - User defined data types - records, files, RDBMS Tables etc Operations are user defined functions/procedures etc. Other candidate layers include "Standard libraries" etc, but I rejected these as a subset of either Implementation or Application layers. To be useful any fundamental basis of software would have to express concepts which applied with equal validity across all layers. - ie not be dependant on data format, or semantics but simply relate to *relative* information content. Operations would need to be expressable in terms of data transforms across and within layers. I could go on (onto the nature of operations!) but that's probably enough for now. Now the big question is: Since I am sure this isn't original, who has done this stuff before? - Where can I get papers or books on fundamental information representation/transformation theory? I assume there must be something? somewhere? [ Note: I am not talking about Knowledge Engineering which has more to do with how information is stored and processed than what information is, its empirical qualities etc... ] Alan Gauld BT computing partners Tel : 0141 220 8795 Fax : 0141 248 1284

3 3