Home Original page

Pythonic Nirvana - towards a true Object Oriented Environment [visionary rambling, long]

Ville Vainio ville at spammers.com
Thu Jul 1 10:42:12 EDT 2004 
>>>>> "Corey" == Corey Coughlin <corey.coughlin at attbi.com> writes:

    Corey> Actually, the last time somebody propsed writing a python
    Corey> based OS, I had pretty much the same idea.  The idea you
    Corey> have currently looks good for a pure text environment, but
    Corey> you may want to think about what enhancements would look
    Corey> like as people add things like GUIs in the mix and see how
    Corey> that works.  I suppose it could wind up looking something
    Corey> like a Naked Object framework, but it could go a lot of
    Corey> different

Yes, the Naked Objects thing (now that I know about it ;-) looks quite
similar to what I had in mind, but I get the feel that it's too
"heavyweight" to be used as general purpose operating environment
(a'la shell / file manager / bunch of scripts). It seems to be geared
towards focused cathedral style development, as opposed to the user
developing the system as he goes about using it (which is much more
realistic w/ Python than Java).

    Corey> ways.  But in general, putting together an interactive
    Corey> object based interface will probably lead you down the OS
    Corey> optimization path.  As

I tend to think that Linux / Windows is the base to build on, and that
the software should work happily with the limitations of such systems
(file system & all). Without integration with the platform people
won't even try it, and it couldn't grow independent of the core
developers.

    Corey> main memory gets cluttered with objects, you'll want to
    Corey> swap some back to disk, so you'll need some kind of virtual
    Corey> memory system, and some way to store those objects on disk,
    Corey> which implies an object file system, and once you start
    Corey> screwing with file systems, you may as well get right into
    Corey> the OS level.  And that sounds like a vaguely good idea,

Explicit persistence is IMO not a bad idea. If an object is in the
main memory, it's in the main memory (until paged out normally by the
OS). I'm not sure considering the object oriented nature of the data
would yield significant payoffs compared to typical paged virtual
memory implementations.

Temporary data should be just that, temporary, so there would not be
that much in-memory objects. Mostly the objects you are working with
currently. Also, the actual valuable data should be stored in standard
files in sensible places. a Music object, for example, is probably
just an interface to manipulating an underlying .ogg file.

    Corey> experience.  Generally, if the system works on a text
    Corey> level, you'll definitely want to bring it into a gui
    Corey> framework, and when people see a gui, they'll want to start

Yes, GUI framework would definitely be cool. I'm thinking of a
nautilus-like view of the python in-memory namespace, where the
objects are shown in their natural representations. All the in-memory
objects could be dragged to another window, representing a persistent
object database, where they would be, well, persisted.

    Corey> to start thinking about more complicated standard types
    Corey> above list and dict, like Picture, Document, Sound, Table,
    Corey> and so on.  Then make sure that creating these basic

Things like Picture, Document etc. would be rather easy to implement -
just make sure that Path objects work (file names should be Path objs,
not strings), and create an object/system that autoconverts the path
to an object via which the file can offer richer operations (play,
print, etc).

    Corey> objects is fairly easy, then think about how scripting data
    Corey> flow in and around these objects can be done, object

Well, since they are Python objects, using Python to script the data
flow would seem optimal ;-).


    Corey> Of course, this has certain implications, for a system like
    Corey> this to interoperate with other normal file based systems,
    Corey> you'll need automatic conversion of incoming and outgoing
    Corey> files into your base

As I said previously, I don't think files should be converted - all
the valuable data (i.e. data that can't be trivially derived from
other data) should still be as normal files.

What is needed is

1. Have a global python "system image", consisting of objects in
   memory and ones in persistent store.

2. Implement a special file type for file managers (which will then
   act as object managers). Let's call it .object. Example contents of
   .object files follows:


5236253625362512.object:  #  (the name need not make any sense, user never sees it)
--------------------
memobject at 0x2326561 core version 675 class = 3274892347.object
--------------------

3274892347.object:   # this is the class object, in persistent store
--------------------
persistentobject #5612 database /srv/coredb1 version 34
--------------------

475847845.object
--------------------
instantiate myutils.OCREngine version 432   # or perhaps version HEAD?
--------------------


When the file manager starts to render the directory, it sees the
.object file and reads the contents, rendering the object as
appropriate (reading it either from the memory or object
database). Version numbers would guarantee that no objects in core
which is dead (after reboot) would be rendered.

This all would of course mean that Nautilus/whatever would be in the
same address space as the python core.

    Corey> wouldn't go too crazy coloring outside the lines with this.
    Corey> But it could be a great thing.

Yes, it would be absolutely brilliant. And entirely within the realm
of doable. Less than a year of work, I'd estimate.

    Corey> And yes, I have thought about this before.

The whole concept, esp. as far as object oriented desktop goes, has
been rehashed several times over. All these projects tend to fail
because programmability has not been there. You have always needed a
professional to implement some of the objects for the desktop, and as
a result there really hasn't been many of such objects around. With
the programmability of python, it will be trivial for a 13-year old to
do the following:

class MyOggEncoder:
  def __init__(self):
    self.files = []
    self.encoded = []

  [accepts(WavFile)]
  def accept(self,wav):
    self.files.append(file)

  [tooltip("Starts encoding the files"),
   needthread]
  def go(self):
    for f in self.files:
      oggname = getuniquefilename()
      os.system("oggenc -o %s %s" % (oggname, f.filename()))
      self.encoded.append(OggFile(oggname))

    # show a pretty balloon on the object
    desktop.notify(self, "I've completed encoding!")
    


Then the user can just drag the wav files to an instantiated
MyOggEncoder, select "go" from popup menu, and the encoding will start
in its own thread.

After the encoding is done, you just double click the object, double
click the "encoded" attribute, to see the contents of "encoded" list
which is a bunch of ogg files. Then they are just dragged to the
target folder, selecting an "move as normal files" option which copies
the ogg files to the target folder, stripping all objectness.

-- 
Ville Vainio   http://tinyurl.com/2prnb
More information about the Python-list mailing list