Pythonic Nirvana - 走向真正的面向对象的环境[有远见的漫无边际的漫长] [英] Pythonic Nirvana - towards a true Object Oriented Environment [visionary rambling, long]
问题描述
Pythonic Nirvana - 走向真正的面向对象的环境
============================== ==================== ===========
IPython（由Francois Pinard）最近（下一个版本 - 更改是
仍然在CVS中）获得了系统shell的基本功能（比如
bash）。实际上，将它用作外壳相当舒服。这一切都让我觉得......
为什么我们编写简单的脚本来做简单的事情？为什么我们将
序列化为平面文本文件以便处理它们？如果我们直接操作
数据*，那么
可能会更加简单和强大得多* - 我们应该操作对象，列表，词典，
函数，而不是文件。我们不应该编写脚本来执行我们的
例程 - 而且我们甚至不会尝试，因为在脚本之间移动
数据太麻烦了，涉及文件格式，argv
解析和其他繁琐的东西。
如果我们使用具有完整Python功能的shell，我们可以介绍新的
非常容易整合我们环境的功能。考虑用于管理软件项目的
项目框架::
import pf
pf.projects
- > [< project''foo''>，< project''bar''>]
p = pf.projects [0]＃我们想要使用项目''foo''
headers = Set（[f表示f.files（）中的f如果f.endswith（.h）]）
srcs = p.files - headers
found = Set（ [f如果是srcs，如果是find_any（f，header）]）
r = findradio（" kazoo classics"）[0]＃需要一些转移
music.play＃操纵我们的音乐播放器
music.vol 100
＃重新开始工作... notfound = srcs - 发现
＃谁制作了一个不是标头用过的？ jackasses = Set（[p.author（file）for notfound中的文件]）
现在我们在''jackasses'变量中有我们受害者的名字。我们想要
来让我们的项目团队中的所有人都可以访问这个变量，在
持久性商店中。我们使用制表符完成来查找数据库::
export jackasses< TAB>
完成次数：fooproject_db " barproject_db" private
请注意导出选项卡的完成方式通知我们正在尝试
输入第二个参数。它知道它是数据库名称，并且
完成机制（为导出编写）动态查询我们被允许导出数据的数据库列表。
看到选择后我们选择其中一个::
export jackasses" fooproject_db"名称= QUOT;懒虫"
现在每个人都可以访问这些人员名单。我们还在[Mail（to = name，bodyfile =" tmp"）中为每个人撰写了一封
易失性电子邮件::
xemacs tmp
名字在jackasses]：m.send
然后把这些人交给管理层::
xemacs tmp2
＃邮件内容
＃以下人员没有做好自己的工作：
＃@（" \ n" .join（jackasses））
cont = open（tmp2）.read（）。expand（）＃通过EmPy模板扩展系统运行它。
Mail（to = p.boss，body = cont）.send
注意邮件中如何使用jackasses变量。我们还可以为b / b $ b安排一些额外的时间让他们检查他们的标题是否需要
，创建一个cron脚本来监控他们已经修复了错误，
等
老板可能想立刻解雇他们：
l = import" slackers"
[e。雇员（l）中的e的火（）]
或者老板可能想要更广泛的解雇来激活
公司::
ent = MyEnterprise（）
需要Auth！
密码：******
st = stats（ent.allemployees（））
avgperf = st.average_performance
def dead_weight（emp）：
..如果是emp.performance（）< ; avgperf：返回True
..返回False
ent.fire_if（dead_weight）
打字所有可能看起来很多工作。但是，其中很多
可能会被实现为聚合
功能的函数。这里的大多数行都可以用来计算
a函数（注意我没说脚本）::
def unused_headers（prj）：
"""返回项目中未使用的头文件">
...实现...
使用传统的脚本技术，没人会想要做所有
这个。使用pythonic方法，创建这种业务
智能是轻而易举的，消除了大量繁琐的例程！
显然这一切都可以在特定的脚本中完成，从一开始就开始做b $ b的事情。 - 打开数据库连接，询问用户
选择项目等。但是，写这样的脚本是很多工作的b $ b。通过交互式，更加动态的方法，可以逐个实现
功能，并且它们可以立即使用
。
我可以想象，对于高级用户和知识工作者来说，这种类型的系统会产生巨大的力量。投资回报也是递增的 -
整个系统的增长和重构，简化了
流程。最后，大部分内容可能会由一个简单的
GUI驱动。特别是火力低于平均水平的员工
不应该在每年的cron工作中运行 - 仅在需要时。各种GUI
线程可以在同一个Python进程中运行，操作
相同的命名空间
需要做什么< br $>
---------------------
毫不奇怪，我们不是还有。
- IPython需要一些重构（代码库不太可扩展
且可扩展性足够）。 Francois可以使用一些帮助。
- 需要灵活的持久性系统。也许是ZODB？
- 需要实施域特定模块（如项目/员工管理和b $ b系统）。幸运的是，这主要是写自己的。
- 需要指定灵活但易于使用的协议
记录函数，参数扩展，gui交互等。一个
gui模块应该显示当前的文档。功能
和可能的参数，所以没有必要一直按Tab键。
尽管如此，总而言之，我们差不多了那里。这或许相同
感觉紧密集成，我想Lisp Macine的人们经历了很多，但是Python对脚本更友好，社区
驱动且更容易学习。
Ergo，世界统治。
-
Ville Vainio http://tinyurl.com/2prnb
>> >>> "威乐" == Ville Vainio（是的，那是我）写道：
Ville> IPython（由Francois Pinard）最近（下一个版本 - 更改是
小修正 - 它是费尔南多佩雷斯，而不是弗朗索瓦皮纳德。我
道歉。
IPython网页位于 http：// ipython。 scipy.org/ ，googlically
挑战。
-
Ville Vainio http://tinyurl.com/2prnb
Ville Vainio< vi *** @ spammers.com>写道：
为什么我们编写简单的脚本来做简单的事情？为什么我们要将数据序列化为平面文本文件是为了处理它们？如果我们直接操作
数据*，一切都可以简单得多，而且非常强大* - 我们应该操作对象，列表，字典，
函数，不是文件。我们不应该编写脚本来执行我们的
例程 - 而且常常，我们甚至都不会尝试，因为在脚本之间移动数据太麻烦了，包括文件格式，解析和其他繁琐的东西。
>>>>> "亚切克" == Jacek Generowicz< ja ************** @ cern.ch>写道：
Jacek> http://www.scsh.net/
是的，scsh似乎与ipython现在做同样的事情（虽然
ipython还没有做工作控制或其他更低级别
东西）。但是，它*是*在Scheme中，它有点混淆了
集成/普遍性/用户接受方面;-)。
仍然，scsh出现是一个寻找进一步发展的好地方，
特别是在过程控制/重定向方面。
-
Ville Vainio http://tinyurl.com/2prnb
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" == 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
Ville Vainio <vi***@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.
>>>>> "Jacek" == Jacek Generowicz <ja**************@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
这篇关于Pythonic Nirvana - 走向真正的面向对象的环境[有远见的漫无边际的漫长]的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
