Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Pythonic Nirvana - towards a true Object Oriented Environment [visionary rambling, long] (http://www.velocityreviews.com/forums/t332682-pythonic-nirvana-towards-a-true-object-oriented-environment-visionary-rambling-long.html)

Ville Vainio 06-29-2004 02:03 PM

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

IPython (by Francois Pinard) recently (next release - changes are
still in CVS) got the basic abilities of a system shell (like
bash). Actually, using it as a shell is rather comfortable. This all
made me think...

Why do we write simple scripts to do simple things? Why do we
serialize data to flat text files in order to process them? Everything
could be so much simpler and immensely more powerful if we operated on
data *directly* - we should operate on objects, lists, dictionaries,
functions, not files. We shouldn't write scripts to perform our
routines - and way too often, we don't even try, because moving the
data between scripts is too troublesome, involving file formats, argv
parsing and other tedious stuff.

If we use a shell with full Python capabilities, we can introduce new
funtionality for integrating our environments very easily. Consider a
project framework for managing a software project::

>> import pf
>> pf.projects


--> [<project 'foo'>, <project 'bar'>]

>> p = pf.projects[0] # we want to work with project 'foo'
>> headers = Set([f for f in p.files() if f.endswith(".h")])
>> srcs = p.files - headers
>> found = Set([f for f in srcs if find_any(f, headers)])


>> r = findradio("kazoo classics")[0] # some diversion needed
>> music.play # manipulates our music player
>> music.vol 100


# back to work...
>> notfound = srcs - found


# who has made a header that is not used?
>> jackasses = Set([p.author(file) for file in notfound])



Now we have the names of our victims in 'jackasses' variable. We want
to make that variable accessible to all in our project team, in a
persistent store. We use tab completion to find the databases::

>> export jackasses <TAB>


Completions: "fooproject_db" "barproject_db" "private"

Note how tab completions for "export" notices that we are trying to
enter the second parameter. It knows that it is the database name, and
the completion mechanism (written for export) dynamically queries the
list of databases for which we are allowed to export data. After
seeing the choices we choose one of them::

>> export jackasses "fooproject_db" name="slackers"


Now the list of guys is accessible to everybody. We also compose a
volatile email to everybody::

>> xemacs tmp


>> for m in [Mail(to=name, bodyfile="tmp") for name in jackasses]: m.send


And rat the guys to the management::

>> xemacs tmp2


# mail contents
# The following guys have not been doing their jobs:
# @("\n".join(jackasses))

>> cont = open(tmp2).read().expand() # runs it through EmPy template expansion system.


>> Mail(to=p.boss, body=cont).send


Notice how jackasses variable was used inside the mail. We can also
schedule some extra hours for the guys to check if their headers are
needed, create a cron script to monitor that they have fixed the bugs,
etc.

The boss might want to fire them at once:

>> l = import "slackers"
>> [e.fire() for e in Employee(l)]


Or the boss might want to do some more extensive firing to invigorate
the company::

>> ent = MyEnterprise()


Auth needed!
Password: ******

>> st = stats(ent.allemployees())
>> avgperf = st.average_performance



>> def dead_weight(emp):

.. if emp.performance() < avgperf: return True
.. return False

>> ent.fire_if(dead_weight)


Typing all that might seem like a lot of work. However, a lot of it
will probably be implemented as functions aggregating the
functionality. Most of the lines here could be factored out to
a function (note that I didn't say script)::

def unused_headers(prj):
""" returns the header files that are not used in the project """
... implementation ...


With conventional scripting techniques, nobody would want to do all
this. With the pythonic approach, creating this kind of business
intelligence is a breeze, eliminating tons of tedious routine!

Obviously this all can be done in specific scripts, which start doing
the thing "from the start" - open database connections, ask the user
to select the project, etc. However, writing such scripts is a lot of
work. With the interactive, much more dynamic approach, pieces of
functionality can be implemented one by one, and they become usable
immediately.

I can imagine that for power users and "knowledge workers", this type
of system would yield immense power. The payback is also incremental -
the whole system grows and gets refactored, streamlining the
process. In the end most of it will probably be driven by a simple
GUI. Especially the "fire below average employees" function, which
should not be run in a yearly cron job - only when needed. Various GUI
threads could be running in the same Python process, manipulating the
same namespace

What needs to be done
---------------------

Not surprisingly, "we're not there yet".

- IPython needs some refactoring (the codebase isn't quite scalable
and extensible enough yet). Francois can use some help.

- Flexible persistence system needs to be itengrated. ZODB, perhaps?

- Domain specific modules (like project / "employee management"
systems) need to be implemented. This luckily mostly writes itself.

- Flexible, but easy to use protocols need to be specified for
documenting the functions, argument expansion, gui interaction etc. A
gui module should display the documentation for the "current" function
and possible arguments, so there's no need to press tab at all times.

Still, all in all, we're almost there. This has the perhaps same
"feel" of tight integration that I imagine the Lisp Macine guys were
experiencing, but Python is much more scripting-friendly, community
driven and easier to learn.

Ergo, world domination.

--
Ville Vainio http://tinyurl.com/2prnb

Ville Vainio 06-29-2004 02:41 PM

Re: Pythonic Nirvana - towards a true Object Oriented Environment [visionary rambling, long]
 
>>>>> "Ville" == Ville Vainio (yes, that's me) writes:

Ville> IPython (by Francois Pinard) recently (next release - changes are

Minor correction - it's Fernando Perez, not Francois Pinard. I
apologize.

IPython web page is at http://ipython.scipy.org/, for the googlically
challenged.

--
Ville Vainio http://tinyurl.com/2prnb

Jacek Generowicz 06-29-2004 03:04 PM

Re: Pythonic Nirvana - towards a true Object Oriented Environment [visionary rambling, long]
 
Ville Vainio <ville@spammers.com> writes:

> Why do we write simple scripts to do simple things? Why do we
> serialize data to flat text files in order to process them? Everything
> could be so much simpler and immensely more powerful if we operated on
> data *directly* - we should operate on objects, lists, dictionaries,
> functions, not files. We shouldn't write scripts to perform our
> routines - and way too often, we don't even try, because moving the
> data between scripts is too troublesome, involving file formats, argv
> parsing and other tedious stuff.


http://www.scsh.net/

Ville Vainio 06-29-2004 03:54 PM

Re: Pythonic Nirvana - towards a true Object Oriented Environment [visionary rambling, long]
 
>>>>> "Jacek" == Jacek Generowicz <jacek.generowicz@cern.ch> writes:

Jacek> http://www.scsh.net/

Yes, scsh appears to be doing the same thing as ipython now (though
ipython doesn't yet do job control or other "lower level"
stuff). However, it *is* in Scheme, which kinda muddens the
integration / universality / user acceptance aspects ;-).

Still, scsh appears is a good place to look for further development,
especially as far as process control/redirection goes.

--
Ville Vainio http://tinyurl.com/2prnb

Phil Frost 06-29-2004 05:37 PM

Re: Pythonic Nirvana - towards a true Object Oriented Environment[visionary rambling, long]
 
I'm forwarding this to the Unununium <http://unununium.org/> mailing
list. I think the two projects are solving the same problem from
opposite ends.

On Tue, Jun 29, 2004 at 05:03:18PM +0300, Ville Vainio wrote:
> Pythonic Nirvana - towards a true Object Oriented Environment
> ================================================== ===========
>
> IPython (by Francois Pinard) recently (next release - changes are
> still in CVS) got the basic abilities of a system shell (like
> bash). Actually, using it as a shell is rather comfortable. This all
> made me think...
>
> ...



Ville Vainio 06-29-2004 08:47 PM

Re: Pythonic Nirvana - towards a true Object Oriented Environment [visionary rambling, long]
 
>>>>> "Phil" == Phil Frost <indigo@bitglue.com> writes:

Phil> I'm forwarding this to the Unununium <http://unununium.org/> mailing
Phil> list. I think the two projects are solving the same problem from
Phil> opposite ends.

Very interesting link :-).

Actually, IPython is so far not actively solving the problem Ununium
is solving, and I wasn't really talking on behalf of IPython the
project, more like visions of what I might want it to be (and
Fernando, the author, probably too, but his time resources are
limited). If you Ununium guys have developer resources to throw at
IPython's direction, I would bet Fernando wouldn't mind a little help
at all - just join the ipython-dev mailing list, IPython is in need of
refactoring :-).

And if you want to check ipython out, do a cvs checkout as instructed
on the webpage and start ipython by "ipython -p pysh", which starts it
in shell mode.

--
Ville Vainio http://tinyurl.com/2prnb

mjt 06-30-2004 01:36 AM

Re: Pythonic Nirvana - towards a true Object Oriented Environment [visionary rambling, long]
 
Ville Vainio wrote:

> Pythonic Nirvana - towards a true Object Oriented Environment


.... with every new language/scripting language,
we are supposed to discover nirvana

as my 13 YO daughter would say: "what--*EVER*..."
..
--
<< http://michaeljtobler.homelinux.com/ >>
I don't need to compromise my principles, because they don't have the
slightest bearing on what happens to me anyway. -- Calvin


Ville Vainio 06-30-2004 08:02 AM

Re: Pythonic Nirvana - towards a true Object Oriented Environment [visionary rambling, long]
 
>>>>> "mjt" == mjt <mjtobler@removethis_mail.ru> writes:

mjt> Ville Vainio wrote:
>> Pythonic Nirvana - towards a true Object Oriented Environment


mjt> ... with every new language/scripting language, we are
mjt> supposed to discover nirvana

Nirvana is not discovered - Nirvana just is ;-).

The point was not liberation-through-Python, it was
liberation-through-interactive-integration-at-deeper-level.

--
Ville Vainio http://tinyurl.com/2prnb

has 06-30-2004 05:19 PM

Re: Pythonic Nirvana - towards a true Object Oriented Environment [visionary rambling, long]
 
Ville Vainio <ville@spammers.com> wrote in message news:<du7brj2mpg9.fsf@mozart.cc.tut.fi>...
> Pythonic Nirvana - towards a true Object Oriented Environment


Try Squeak for ideas: http://www.squeak.org/

Corey Coughlin 06-30-2004 06:55 PM

Re: Pythonic Nirvana - towards a true Object Oriented Environment [visionary rambling, long]
 
Actually, the last time somebody propsed writing a python based OS, I
had pretty much the same idea. The idea you have currently looks good
for a pure text environment, but you may want to think about what
enhancements would look like as people add things like GUIs in the mix
and see how that works. I suppose it could wind up looking something
like a Naked Object framework, but it could go a lot of different
ways. But in general, putting together an interactive object based
interface will probably lead you down the OS optimization path. As
main memory gets cluttered with objects, you'll want to swap some back
to disk, so you'll need some kind of virtual memory system, and some
way to store those objects on disk, which implies an object file
system, and once you start screwing with file systems, you may as well
get right into the OS level. And that sounds like a vaguely good
idea, although the top down approach seems like a different way of
doing it, start with a basic linux kernel, then start modifying what
you need to, rewriting parts in python as needed, until you get down
to a core and the python object space.

But to take another tack, you may also want to think about the user
experience. Generally, if the system works on a text level, you'll
definitely want to bring it into a gui framework, and when people see
a gui, they'll want to start doing all the things they can do on other
systems, like creating documents, spreadsheets, databases, listening
to mp3s, looking at pictures and movies, and so on. So you may want
to start thinking about more complicated standard types above list and
dict, like Picture, Document, Sound, Table, and so on. Then make sure
that creating these basic objects is fairly easy, then think about how
scripting data flow in and around these objects can be done, object
casting (for instance, casting a picture to a document would seem to
require an OCR engine) and so on, and then you can begin to see how a
whole framework could work, and act somewhat as expected in a normal
setting.

Of course, this has certain implications, for a system like this to
interoperate with other normal file based systems, you'll need
automatic conversion of incoming and outgoing files into your base
object types, so it would probably help to pick current standards as
the basis for your object models (like jpeg for pictures and so on) so
that they can easily be cast as files to the outside world. So I
wouldn't go too crazy coloring outside the lines with this. But it
could be a great thing.

And yes, I have thought about this before.





Ville Vainio <ville@spammers.com> wrote in message news:<du7d63hwk0x.fsf@mozart.cc.tut.fi>...
> >>>>> "mjt" == mjt <mjtobler@removethis_mail.ru> writes:

>
> mjt> Ville Vainio wrote:
> >> Pythonic Nirvana - towards a true Object Oriented Environment

>
> mjt> ... with every new language/scripting language, we are
> mjt> supposed to discover nirvana
>
> Nirvana is not discovered - Nirvana just is ;-).
>
> The point was not liberation-through-Python, it was
> liberation-through-interactive-integration-at-deeper-level.



All times are GMT. The time now is 04:51 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.