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

[Corey Coughlin]

Yeah, you bring up some good points, but at the very least, object
browsing and hierarchy will be a key feature in the system, so that
should be thought out pretty thoroughly.  I suspect it could get kind
of confusing for people switching between the object system and the
file system. If all objects wind up becoming files in the back end,
then people will start operating on the outside of the framework, and
that probably wouldn't be good, and if they're all in a database (like
ZODB), then people will complain about interoperability, so it makes
sense to define that line pretty strictly before you get too far into
it.   It sounds like you're leaning towards making every
file-to-object and back transition explicit, which might make sense,
as long as you can keep the conversion overhead fairly low.  I suppose
you could set it up so that all data objects that get brought in from
a file get saved back to a file, and all the extra objects created in
the python shell get stored in the database, with explicit hooks for
taking certain objects and transforming them into external files.  I'd
hate to see the system try to save every object out to a file
somewhere (imagine every string in a typical program having it's own
separate file, ugh) but it does seem like you'd want certain objects
sent out to disk, without a lot of explicit object saving overhead, if
you really want full interoperability.  It's probably going to wind up
even more confusing than this,
but I guess there will be issues like this in any system that bridges
the two worlds.  That's why it's often easier to imagine a full os,
where you don't have the interoperability issues to deal with.  Ah
well, it's a step in the right direction, anyway.

Ville Vainio <ville at spammers.com> wrote in message news:<du7eknvhjqz.fsf at mozart.cc.tut.fi>...
> >>>>> "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.