Home
FAQ
Feedback
Departments
Discussions
(new topic)
Language Evaluation
PL Courses
Research Papers
Design Docs
Quotations
Genealogical Diagrams
|
|
|
|
python
| EuroPython'2004 Slides |
|
Mostly technical presentations that are uninteresting from our perspective. However two presentations may be of interest.
Guido's presentation outlines the future of Python as he sees it. It includes a discussion of generator expressions.
How Python is developed by Marc-Andre Lemburg provides a nice overview of the Python design process.
Posted to Python by Ehud Lamm on 6/14/04; 1:06:07 PM
Discuss (1 response)
|
|
| Static Type Inference (for Python) with Starkiller |
|
Michael Salib. PyCon DC 2004
Removing dynamic dispatch and binding leads to large performance
benefits since their existence precludes many traditional optimization techniques,such
as inlining. I have built a static type inferencer for Python called Starkiller. Given a
Python source file, it can deduce the types of all expressions in the program without
actually running it. Starkiller’s primary goal is to take a Python source program as
input and deduce the information needed to make native code compilation of that
program easy. This paper is describes Starkiller’s design and operation. It is partially
adapted from a draft of my Master’s thesis.
Seems like a nice piece of work. Starkiller even goes as far as providing a mini-language that allows non-Python extension type authors to describe the type behavior of their extensions. These descriptions are used during inference to model the run time data flow.
Posted to Python by Ehud Lamm on 3/25/04; 2:44:33 AM
Discuss (1 response)
|
|
| Two impromptus--or how Python helped us design our kitchen |
|
Andrew Koenig's PyCon contribution is rather amusing. This isn't really a programming languages paper per se, but it provides a nice example of choosing the right tools for a job (where "right" obviously depends on many factors, including the list of conferences one wants to attend).
Andrew demonstrates the mix and match approach to getting things done, something we hackers know all about. Like I said, an amusing little article...
Posted to Python by Ehud Lamm on 3/24/04; 4:05:39 AM
Discuss (1 response)
|
|
| PyCon Papers |
|
Many PyCon papers and presentations are now online.
I will try to post about specific presentations later, and the other editors are invited to post about their favorites.
Posted to Python by Ehud Lamm on 3/24/04; 2:55:18 AM
Discuss (1 response)
|
|
| Scope, generators and list comprehensions (Python) |
|
The standard scoping rules are inconvenient for the lazy evaluation of generator expressions, but it's very strange for a list comprehension and an apparently identical generator expression to produce different results.
Try to guess the output from these expressions:
>>> lst = [lambda x:x+y for y in range(3)]
>>> for f in lst:print f(0)
???
>>> gen = (lambda x:x+y for y in range(3))
>>> for f in gen:print f(0)
???
I just love this sort of thing. Maybe this should go in the fun department...
P.S
The URL given at the Daily Python-URL is wrong.
Posted to Python by Ehud Lamm on 2/5/04; 8:36:13 AM
Discuss (2 responses)
|
|
| Lython |
Miles Egan's lython puts a lisp-like sexpr syntax on top of python:
(def foo (a)
(print "one")
(print "two")
(* a 5))
(From lemonodor)
Posted to Python by Patrick Logan on 12/29/03; 10:29:50 PM
Discuss (2 responses)
|
|
| PEP 323: Copyable Iterators |
|
Yet another language design discussion concerning a simple looking, and rather isolated, language construct.
In Python up to 2.3, most built-in iterator types don't let the user
copy their instances. User-coded iterators that do let their clients
call copy.copy on their instances may, or may not, happen to return,
as a result of the copy, a separate iterator object that may be
iterated upon independently from the original.
As more and more languages offer container libraries supporting iterators, and quite a few even support iterator expressions and generators, issues like this one are likely to arise more often.
Strangely, it's quite hard to define the state of the art regarding this and similar issues.
The discussion is more interesting than the PEP itself, and is fairly self contained.
Posted to Python by Ehud Lamm on 12/28/03; 2:18:43 PM
Discuss (1 response)
|
|
| python - spidermonkey |
|
(via Daily Python-URL)
Python/JavaScript bridge module, making use of Mozilla's spidermonkey JavaScript implementation. Allows implementation of JavaScript classes, objects and functions in Python, and evaluation and calling of JavaScript scripts and functions respectively. Borrows heavily from Claes Jacobssen's Javascript Perl module, in turn based on Mozilla's 'PerlConnect' Perl binding.
Cross-language hacks are always worth a look.
Might even get our Javascript gurus excited... (You know, BeyondPython kind of thing...)
Posted to Python by Ehud Lamm on 12/28/03; 8:33:37 AM
Discuss (3 responses)
|
|
| Twisted Matrix Networking for Python |
|
Twisted Matrix is a Python framework for networking. The best summary is the paper quoted below. Twisted offers tantalizing extras which reflect inspirations from E and vague similarities to Oz: the Perspective Broker and Deferred objects ("A Deferred instance is a promise that a function will at some point in the future have a result...").
Twisted is a high-level networking framework that is built around event-driven asynchronous I/O. It supports TCP, SSL, UDP and other network transports. Twisted supports a wide variety of network protocols (including IMAP, SSH, HTTP, DNS). It is designed in a way that makes it easy to use with other event-driven toolkits such as GTK+, Qt, Tk, wxPython and Win32. Implemented mostly in Python, Twisted makes it possible to create networked applications without having to worry about low-level platform specific details. However, unlike many other network toolkits, Twisted still allows developers to access platform specific features if necessary.
There is a large amount of freely-available networking code on the internet today.... However, few frameworks endeavor to Twisted's scope and generality, and none that they authors are aware of provide as much integrated functionality as it does.
Posted to Python by Mark Evans on 12/18/03; 6:45:02 PM
Discuss (8 responses)
|
|
| Hugunin's IronPython |
|
Jim Hugunin has a new project, named IronPython, which is an implementation of Python for the Microsoft Common Language Runtime environment. The remarkable thing is that IronPython runs faster than the Python implementation in C according to the pystone benchmark. (See Hugunin's original message for full details.)
Miguel de Icaza, lead developer of the Mono framework, also comments on Hugunin's remark with delight and says that this might "stop the meme of '.NET is slow for scripting languages'".
I don't think it should be a surprise that Python compiled to CIL and then translated to native instructions is faster than CPython interpreted byte code.
What's unclear to me so far is how much time is taken to compile IronPython in the first place. That is, is IronPython an interactive environment or a compile ahead environment?
I think Sharp Smalltalk already demonstrates that compile ahead works well. I am betting IronPython operates similarly. To my knowledge, no one has implemented an interactive environment yet for a dynamic language that is compiled to CIL.
Posted to Python by Patrick Logan on 12/12/03; 7:26:03 PM
Discuss (4 responses)
|
|
| Python Scripting Everywhere |
|
(via Daily Python-URL ==> Jeremy Hylton)
Here are some software projects for which I'm prepared to pay a bounty... My budget for these bounties in 2004 is USD 100,000...
I'm open to requests for funding work that needs to be done to make Python the most widespread common scripting language on the net.
And they say LtU links are of no practical use?! $100,000 - now that's real money!
Among the systems mentioned are OpenOffice, Blender, AbiWord, Gnumeric and The GIMP.
Now, personally, I prefer DSLs, but no one seems to be funding those...
I have a feeling that any work towards a Python object-model for scripting a given appilcation could be directly translated into a Javascript object-model. What do you guys think?
Posted to Python by Ehud Lamm on 12/4/03; 1:34:52 PM
Discuss (14 responses)
|
|
| PEP 289: Generator Expressions - Accepted for Py2.4 |
|
Experience with list comprehensions has shown their wide-spread utility throughout Python. However, many of the use cases do not need to have a full list created in memory. Instead, they only need to iterate over the elements one at a time...
Generator expressions are especially useful with functions like sum(), min(), and max() that reduce an iterable input to a single value.
Surely a step in the right direction, though I suspect Haskell mavens will find this document a bit amusing, especially as regards Python's struglling with scope and the fact that the word 'lazy' doesn't appear anywhere in this document.
I guess the only real conclusion we can draw from this PEP is that Python programmers love catamorphisms...
Posted to Python by Ehud Lamm on 11/5/03; 2:33:39 PM
Discuss (3 responses)
|
|
| Ideas for a master's thesis related to Python |
|
Lest we become a Microsoft-only blog...
Not all the ideas seem very interesting, and I am not sure all would be appropriate for a master thesis, but at least the list includes some valuable links.
Those still trying to recover from the macros discussion will be happy(?) to find some more macro related ideas...
Posted to Python by Ehud Lamm on 11/1/03; 11:54:21 AM
Discuss (2 responses)
|
|
| Metaclass programming in Python, Part 2 |
|
Michele [Simionato] and David [Mertz]'s initial developerWorks article on metaclass programming prompted quite a bit of feedback, some of it from perplexed readers trying to grasp the subtleties of Python metaclasses. This article revisits the working of metaclasses and their relation to other OOP concepts. It contrasts class instantiation with inheritance, distinguishes classmethods and metamethods, and explains and solves metaclass conflicts.
Somehow I think most readers will be as perplexed by this article as they were by its predecessor. The lucky ones will find a friendly LtU reader to help them out...
Posted to Python by Ehud Lamm on 9/10/03; 8:26:16 AM
Discuss (8 responses)
|
|
| Charming Python: Using combinatorial functions in the itertools module |
Functional programming in Python becomes lazy
From dive into mark
Python 2.2 introduced simple generators to the Python language and reconceived standard loops in terms of underlying iterators. With Python 2.3, generators become standard (no need for _future_), and the new module itertools is introduced to work flexibly with iterators. The itertools module is essentially a set of combinatorial higher-order functions, but ones that work with lazy iterators rather than with finite lists. In this installment, David explores the new module, and gives you a sense of the new expressive power available with combinatorial iterators.
Here is an interesting quote from the article:
There is something schizophrenic in Python's attitudes towards functional programming (FP). On the one hand, many Python developers disparage the traditional FP functions map(), filter(), and reduce(), usually recommending using list comprehensions in their place. But the whole of the itertools module is composed of functions of the very same sort, merely operating on "lazy sequences" (iterators) rather than on completed sequences (lists, tuples). Furthermore, there is no syntax in Python 2.3 for "iterator comprehensions," which would seem to have to same motivation as list comprehensions.
Also, perhaps indicative is this remark by Mark (an author of a book on "Python for experienced programmers"):
What David Mertz says: Functional programming in Python becomes lazy: using combinatorial functions in the itertools module. What I understand: "Blah blah blah, Python, blah blah blah blah."
Posted to Python by Dan Shappir on 6/23/03; 12:19:09 AM
Discuss (22 responses)
|
|
| How-To Guide for Descriptors |
Learning about descriptors not only provides access to a larger toolset, it creates a deeper understanding of how Python works and an appreciation for the elegance of its design.
Python tends to tie syntax to special methods. For example, array assignment can be considered sugar for the method __setitem(...)__. Descriptors extend this to instance variables - accessing foo.bar can be tied to a method on bar (which receives foo as an argument).
This is a draft, picked up from python-dev - I believe it will move into the main Python docs eventually
Posted to Python by andrew cooke on 6/1/03; 5:17:39 PM
Discuss (2 responses)
|
|
| David Mertz: Multimethods |
|
(via Daily Python-URL)
This article continues a review of advanced object-oriented programming concepts. In this installment I examine multiple dispatch, which is also called multimethods. Most object oriented languages--including Python, Perl, Ruby, C++, and Java--are intellectually descended from Smalltalk's idea of message passing, albeit with syntax and semantics only loosely related to this source. Another option, however, is to implement polymorphism in terms of generic functions; this has the advantage of enabling code dispatch based on the types of multiple objects. In contrast, the native method calling style of common OOP languages only uses a single object for dispatch switching.
A very readable and simple explanation of what multimethods are. Far too basic to interest the experts, but a good introduction if you always found the term mysterious.
Once more we see that if Scheme is not an option, Python can serve as a nice tool to explore language design ideas.
Posted to Python by Ehud Lamm on 5/31/03; 3:44:05 AM
Discuss (6 responses)
|
|
| Python Metaclass Programming |
|
as ordinary instances (objects) are built out of classes, classes themselves are built out of metaclasses. Most of the time, you do not need to worry about the implicit metaclass (named type in Python) that is used in class construction, but occasionally, deliberate control of a class' metaclass can produce powerful effects. For example, metaclasses allow "aspect oriented programming," meaning you can enhance classes with features like tracing capabilities, object persistence, exception logging, and more.
Python remains the language techniques laboratory for the masses.
Other approaches for experimenting with this sort of thing would be implementing an object system in Scheme/Lisp, using CLOS, or playing with Smalltalk MOP.
Posted to Python by Ehud Lamm on 4/22/03; 10:31:31 AM
Discuss (16 responses)
|
|
| PyCon 2003 Papers |
|
Mainly straight Python and incomplete, but some contributions possibly of more general interest, including .net for Python and Traits (strongly typed object attributes).
And, oh look, Paul Graham gave a keynote speech...
Posted to Python by andrew cooke on 4/14/03; 7:13:30 AM
Discuss (5 responses)
|
|
| A Custom Image Viewing Game for an Autistic Child |
|
Aside from being an inspiring story, this Python success story is about building a DSEL.
As such, the language is essentially a set python routines and classes. The article talks about using the __call__ method (to overload the function call operator), using keyword parameters etc.
Posted to Python by Ehud Lamm on 1/16/03; 8:31:49 AM
Discuss (1 response)
|
|
| Guide to Python introspection |
|
(via Daily Python-URL)
Python, a dynamic, object-oriented programming language, provides tremendous introspection support. This article showcases many of its capabilities, from the most basic forms of help to the more advanced forms of inquisition.
A nice tutorial on the various introspection facilities in Python.
Dynamic interpreted languages can easily support introspection. Until a few years ago it was usually considered bad style to use introspection or similar facilities (e.g., RTTI, tag fields in records etc.). It seems like the climate is changing.
Posted to Python by Ehud Lamm on 12/16/02; 8:48:59 AM
Discuss (4 responses)
|
|
| Python 2.3 Release Schedule |
|
(via GIGO)
Some things that may be of special interest to LtU readers:
- Add a new concept, "pending deprecation". Is this good language design?
- Adding a Built-In Set Object Type
- An iterator tools module featuring goodies from SML and Haskell?
- Add support for the long-awaited Python catalog.
- Pgen Module for Python. This PEP proposes that the parser generator used to create the Python parser, pgen, be exposed as a module in Python.
Posted to Python by Ehud Lamm on 10/12/02; 8:29:15 AM
Discuss (3 responses)
|
|
| Make Python run as fast as C with Psyco |
|
(via Daily Python-URL)
I find bringing running time down from more than 1/2 hour to about 10 minutes with two lines of new code to be quite remarkable. This speedup is still probably less than the speed of a similar application in C, and it is certainly less than the 100x speedup that a few isolated Psyco test cases exhibit. But this application is fairly "real life" and the improvements are enough to be significant in many contexts.
A short intro to Psyco, the Python specializing compiler.
Posted to Python by Ehud Lamm on 10/11/02; 7:34:55 AM
Discuss
|
|
| Python list.sort() now stable and faster |
|
Since programming languages are abstraction mechanisms, there are cases when you can improve a language, without making visible changes.
This story is also a nice example of open source language development.
Posted to Python by Ehud Lamm on 8/4/02; 6:43:04 AM
Discuss (1 response)
|
|
| Generator-based state machines |
|
(via Daily Python-URL)
Coroutines are an "exotic" flow mechanism that few widely-used languages allow (not even non-Stackless Python). Python's new generators, however, get you almost all the way to coroutines, and the extra few steps can be faked.
Another instalment of the useful IBM developerWorks Charming Python series.
Generators and coroutines can be compared to a programming model based threarding.
Posted to Python by Ehud Lamm on 7/16/02; 2:54:10 PM
Discuss (3 responses)
|
|
| Guido van Rossum, Linux Magazine interview |
|
(via Daily Python-URL)
I'm not a very moral person in the sense that I don't have very strong views. I'm not religious. I tend to see the value of everybody's point of view. I like to listen to different people and say, "Well yes, that's a reasonable position. That's also a reasonable position." Or, "Yeah, I can understand where you're coming from and why you think this way about it and why you think that way about it." So I don't have absolute morals. I probably have some, but it's pretty difficult to tease them out of me, and I haven't succeeded myself.
An interesting interview (for a change!)
Guido talks about his approach to designing Python, and a bit about its present (Zope) and future.
Should language designers try to be as flexible as possible (see quote above) or should they have strong views, and stick to them no matter what?
Are these really contradictory goals? Are these two approaches the only possible options?
Posted to Python by Ehud Lamm on 6/10/02; 5:24:52 AM
Discuss (1 response)
|
|
| Implementing "weightless threads" with Python generators |
|
(via Daily Python-URL)
In a way, weightless threads recall the cooperative multitasking of older Windows and MacOS versions (but within a single application). In another sense, however, weightless threads are merely another way of expressing flow in a program; everything that weightless threads do could, at least in principle, be accomplished with the "really big if/elif block" technique (the last resort of the brute-force programmer).
Essentially a trampoline that passes control from generator to generator.
The technique should be well-known to anyone who has seen how you implement multi-threading using continuations.
Still, a nice demonstration of the power of Python, and a way to familiarize youself (or a friend) with continuations.
Posted to Python by Ehud Lamm on 6/10/02; 5:08:42 AM
Discuss
|
|
| Generators and Abstraction |
|
(via Keith Devens)
If you are reading LtU, you obviously know that programming languages are first and foremost abstraction mechanisms. They provide us with ways to express our algorithmic intent.
If your software is built from useful abstractions, it is easier to replace a component with a plugin compatible - but different - component. This can help you improve efficiency, enhance relaiblity and so on, simply by replacing and evolving components, without the need to change the design of the application.
In this sense, abstractions simply express a behaves-like property. For example, in some software systems a web page abstaction behaves-like a file object.
This is mostly a software design issue (think coupling) - but the kinds of abstractons you can express depends on the features of the programming language. This short example shows how a list of strings and a generator can be plugin compatible. This allows the programmer to gain some of the advnatages of lazy evaluation.
Nothing very exciting here. Except perhaps that the support for important languages features in Python may lead to their adoption by more mainstream languages.
One more thing. Building abstractions is nice, but in order to build a working system you must also be concerned with the kinds of glue the language provides for connecting the various components. In fact, this glue ultimately controls what abstractions are going to be useful. Generators are obviously a kind of glue.
Posted to Python by Ehud Lamm on 5/6/02; 12:19:34 AM
Discuss (2 responses)
|
|
| Syntax Checking the Scripting Way |
|
(via Daily Python-URL)
A simple example hints at Pychecker's utility. Suppose you have written
the following fragment of Python source code:
status = 3
if some_rare_condition:
statuss = 15
log_result(status)
Is the issue clear? Often, when one encounters source resembling this,
there's been a mistake; the programmer intended status =
15.
Python accepts statuss as syntactically well formed, though.
This fact anguishes many developers who come to "scripting" languages
from C and Java, for example.
My recent Python adventures brought me exactly this anguish. My scripts would connect to the web server, get the web page over a slow link, only to die because of some silly spelling mistake.
I have always liked strongly and statically typed languages (with expressive type systems  ), but I have recently started to think that this was just bias. Now I am back to my old convictions (though for now, Python is my language of choice for scripting).
The reason I like tools like Pychecker is that one can imagine them providing varied kinds of analysis, ranging from 'spelling checks' to grammer checks and culminating in checks for proper use of idioms and so on.
Posted to Python by Ehud Lamm on 4/30/02; 9:44:23 AM
Discuss (7 responses)
|
|
| Pyrex - A language for writing Python extension modules |
|
Pyrex is a language specially designed for writing Python extension modules. It's designed to bridge the gap between the nice, high-level, easy-to-use world of Python and the messy, low-level world of C...
Pyrex deals with the basic types just as easily as SWIG, but it also lets you write code to convert between arbitrary Python data structures and arbitrary C data structures, in a simple and natural way, without knowing anything about the Python/C API. That's right -- nothing at all! Nor do you have to worry about reference counting or error checking -- it's all taken care of automatically, behind the scenes, just as it is in interpreted Python code. And when fully implemented, Pyrex will let you define new built-in Python types just as easily as you can define new classes in Python.
The way this works is that you write code in a Python-like language (Pyrex), which allows you to access C data types directly, as well as standard Python data. The Pyrex code is then compiled into C.
Seems like a nice way to extend a language. Better than having to use a different language completely, as when writing extension modules in C or C++.
In some sense this is reminiscent of inlining and macros.
Posted to Python by Ehud Lamm on 4/20/02; 9:14:15 AM
Discuss (3 responses)
|
|
| The Sociology of Language Evolution |
|
From time to time I feel the need to mention the sociological dimension of language design and evolution.
The discussion on addding a boolean type to Python is a good example.
Small and some would say unimportant changes generate emotional responses, and this is no exception. A good starting point for investigating how this issue is effecting the Python community is a comp.lang.python entitled What has PEP 285 done to us? Also check out the thread True/False story...
I don't want to comment on the specific issue (though you are welcome to let us know what you think...) I am more interested in seeing how the role of language designer (== language god?) changes, as he takes on roles of educator, mediator etc.
Posted to Python by Ehud Lamm on 4/10/02; 2:24:45 PM
Discuss (6 responses)
|
|
| Guido van Rossum: An Optimization Anecdote |
|
If you are fond of high level languages you find yourself all too often irritated by naive remarks about the speed and size of programs. Common misconceptions include confusing executable size and space efficiency, premature optimization, and misunderstanding of modern computing architecture (RISC, cache efficiency, branch predication etc.) Often these are the result of not knowing what a compiler does, and how optimizations work. Sometimes people used to lower level language like C assume that the compiler simply translates source statements into equivalent blocks of machine code.
On top of this many programmers exaggerate the importance of efficiency. They'll go to amazing lengths to eliminate one source statement (often declaring a constant value), making the code less readable - while writing code that will be executed once or twice on fairly small data sets.
So we often simply tell people to forget about speed (or space) and let the compiler worry about it. Optimize only if measurement and profiling shows your code is problematic. If we are honest we emphasize using good algorithms and data structures, since they have the largest impact on speed and space. All the while we know deep down that this is not the whole truth. Sometimes small source level changes can have quite a large impact on speed.
A language designer/implementor is often the one most qualified to discuss such isues.
Posted to Python by Ehud Lamm on 4/5/02; 6:40:35 AM
Discuss (4 responses)
|
|
| COM support in Python |
|
A very detailed presentation about the design and use of the COM framework in Python. A PPT file is also available.
Anyone built an interesting Microsoft Scripting Engine in Python? Sounds like a fun idea.
A bit off topic: I've been playing with Python recently, and really liked the experience (I am not talking language-designer/lawyer here; just average Joe programmer). I needed to grab some web pages (with some nasty authorization/redirection tricks), analyze them, and generate and post an RSS feed. Pretty simple stuff, really. But Python's regular expressions were easy to use, and when I wanted to post the RSS file to xmlStorageSystem, Python's xmlrpclib was real handy. In the process I made use of Mark Pilgrim's Dive Into Python which I also recommend. It is not really a textbook, but if you are an exprienced programmer it can be handy. One problem with writing good programming texts is finding good examples. The examples in the book are both fun and insightful.
Posted to Python by Ehud Lamm on 3/23/02; 3:12:47 PM
Discuss
|
|
| Guido van Rossum: Parade of the PEPs |
|
(via Daily Python-URL)
...a brief overview of all open PEPs, where I gave my highly personal and subjective opinion for each PEP.
Another language design/language designer point of view kind of thing. As you all know by now, I really like this sort of thing.
Of the PEPs discussed I find 215, 243, 245, 246, 274, and 279 to be the most interesting. 279 and 245/246 both deserve special attention (the former from functional programming fans, the latter from OOP zealots )
Posted to Python by Ehud Lamm on 3/10/02; 11:16:21 AM
Discuss (2 responses)
|
|
| Aspect-oriented programming for Python |
|
(via Daily Python-URL)
TransWarp is a general purpose Aspect-Oriented Programming, Generative Programming, and CASE toolkit for Python.
We haven't mentioned AOP is a long time. Maybe a Python implementation will remind people of AOP, an interesting idea that didn't really catch on in the real world.
Posted to Python by Ehud Lamm on 1/20/02; 8:17:30 AM
Discuss (4 responses)
|
|
| HAP Python Remote Debugger |
|
(via Daily Python-URL)
The debugger is made up of two applications: DbgRemote is the editor and IDE, ConsoleEmbed is the remote debugging host - it runs the python script and communicates to the IDE via a network socket. The idea was that the ConsoleEmbed application would be ported to any platforms that we needed to support while the DbgRemote app would be maintained only on the windows platform. This way we could use a single debugging interface to debug our python applications regardless of what platform we were running them on. This two piece approach also allowed us to break into running python code in a more elegant way than possible in the standard python debuggers.
As you may recall I was looking for information on implementing debuggers. Naturally, this link caught my attention.
I was hoping for a bit more documentation, but at least this debugger is open source.
Posted to Python by Ehud Lamm on 1/17/02; 8:19:54 AM
Discuss (3 responses)
|
|
| Cheetah, the Python-Powered Template Engine |
|
(via Daily Python-URL)
Cheetah is a Python-powered template engine and code generator. It can be used as a standalone utility or it can be combined with other tools. Cheetah has many potential uses, but web developers looking for a viable alternative to ASP, JSP, PHP and PSP are expected to be its principle user group.
Yet another tool for separating graphic design and program logic.
Cheetah attempts to make code reuse easy by providing an object-orientated interface to templates that is accessible from Python code or other Cheetah templates. One template can subclass another and selectively reimplement sections of it.
Cheetah integrates tightly with Webware for Python: a Python-powered application server and persistent servlet framework.
Posted to Python by Ehud Lamm on 1/8/02; 8:15:30 AM
Discuss (1 response)
|
|
| Thinking in Python |
|
(via Daily Python-URL)
A Python version of Bruce Eckel's Thinking in Patterns with Java.
I am a bit sad that we have book versions for different languages (I have the same issue with the Modern Compiler books). Somehow I think that if the languages are close enough for straightforward translation, we don't need separate versions (I am reluctant to use the term editions), and if the languages are not so close, whole concepts need to be reconsidered.
Since most programmers don't share my extreme view, I guess some LtU readers may enjoy this
Posted to Python by Ehud Lamm on 12/26/01; 12:48:08 PM
Discuss
|
|
| VPython |
|
VPython includes:
- the Python programming language
- an enhanced version of the Idle interactive development environment
- "Visual", a Python module that offers real-time 3D output, and
is easily usable by novice programmers
VPython is free and open-source.
Check out the Matter&Interactions textbooks which use Vpython in teaching Physics.
Posted to Python by Ehud Lamm on 12/3/01; 12:42:36 AM
Discuss
|
|
| Python Compared to Other Languages |
|
Some readers may have concluded from a recent discussion that LtU has an anti-Python bias. Nothing can be further from the truth. In fact, Python has a dedicated LtU department: even Java didn't get this honor.
On the other hand, this site is dedicated to programming languages, and many of us have experience in many languages, on top of a theoretical knowledge of programming languages. This means that we like to form our own opinions. I think this is a great thing, and I try to learn from all the viewpoints heard on LtU.
The link above is to a Python.org page listing documents comparing Python to other languages. In general, I am no great fan of language comparisons, agreeing with Stroustrup that language comparisons are rarely meaningful and even less often fair. This is why I try not to post them here, leaving them to comp.lang.misc.
Still, even if only to give a more balanced view, I thought I'd link to this page.
I for one would be happy to hear reasoned discussion on topics like readability - including the readability of Python as compared to other languages.
Posted to Python by Ehud Lamm on 9/29/01; 10:55:55 AM
Discuss (4 responses)
|
|
| Charming Python : Iterators and simple generators |
|
Python 2.2 introduces a new construct accompanied by a new keyword. The construct is generators; the keyword is yield. Generators make possible several new, powerful, and expressive programming idioms, but are also a little bit hard to get one's mind around at first glance. In this article, David provides a gentle introduction to generators, and also to the related topic of iterators.
Not that these ideas are extremely new: iterators are from CLU (check out our prevous discussions of this landmark language), and gnererators are, among other things, the basis for goal directed evaluation in Icon. Still, this is a nice intro.
Posted to Python by Ehud Lamm on 9/27/01; 12:38:34 PM
Discuss (17 responses)
|
|
| Computer Programming for Everybody |
|
Finding a good end-user programming apporach is hard. We might as well make eveybody into programmers...
While I find the vision interesting and worth while, I am not sure I'd choose Python. I agree, however, that the IDE is an important part of this crusade:
It is interesting to note, however, that one of the key parts of the TeachScheme project is a development environment. While the audiences and approach are different, our project and TeachScheme share a sense that the development environment is a crucial component. There is a need for an interactive read-eval-print loop, a powerful debugger, and tools to understand how programs work.
I think that in order to achieve the desrided goal the IDE has to be revolutionary. It must, for example, encourage reuse.
Another link: Edu-sig -- Python in education
Posted to Python by Ehud Lamm on 8/30/01; 5:50:12 AM
Discuss (2 responses)
|
|
| PythonCard |
|
(via Daily Python-URL)
This is a project to build a HyperCard like tool in, and using, the Python language. PythonCard is a software construction kit.
PythonCard is for you if you want to develop graphical applications quickly and easily with a minimum of effort or coding.
HyperCard was quite revolutionary when it first came out. A classic example of end-user programming.
Posted to Python by Ehud Lamm on 8/17/01; 6:20:37 AM
Discuss (2 responses)
|
|
| PySTL |
|
The PySTL is a Python extension that exposes the C++ STL for use from Python. It brings the speed, the flexibility, and the extensive resources of the STL to a language that is clear, interactive, and dynamic.
The most ineteresting aspect of this is that PySTL is based exposing the STL classes to Python.
The site claims that the PySTL brings together the best of the C++ STL and Python, with a library that is very fast and powerful, and yet easy and quick to use, if anybody used it and has any comments, please share your experience.
Posted to Python by Ehud Lamm on 7/16/01; 2:16:09 PM
Discuss (1 response)
|
|
| Python 9: Interview with Bruce Eckel |
|
Still wasting time on DDJ Technetcast
Interesting interview about Python's success. Touches on many issues we talked about here in the past.
One interesting issue is the relation between programming languages and productivity. I read some studies on this (obviously written before Python existed), but I still find most productivity claims to be hard to believe. Sure: buliding from scracth takes more time, compared to using a language with builtin features (think Perl and regexps). But for most purposes you can find approriate libraries. When it comes to the notion of expressiveness, I find the data much harder to interpret. Is Scheme really more expressive than C?
Eckel mentions that Python is especially good for solving messy problems. Seems like we are coming back to the idea of prototypig, RAD, and stratified designs. I guess it is pretty well known that dynamic languages are a Good Thing for this kind of processes. Directly related to scripting and glueing.
Another topic that comes up is the importance of the availability of reusable libraries of code. We talked about this in the past. Not just cookbooks! CPAN like stuff, or comprehensive standard libraries (like Smalltalk's?).
One notion Eckel uses to explains Pythons success is that of the benevolent dictator. I am not sure how invented this term, but I like it.
(Check this, more dense discussion, too.)
Posted to Python by Ehud Lamm on 5/28/01; 4:59:31 AM
Discuss (1 response)
|
|
| Python Cookbook |
|
I like this idea - a repository of code snippets. Maybe I'm too straight-laced, but I prefer this to Wikis (see links at the bottom of lambda's pages). Does anything similar exist for other languages?
(Incidentally, the similar - although flatfile - Python Snippets seems to have disappeared).
Posted to Python by andrew cooke on 5/23/01; 8:45:00 AM
Discuss (4 responses)
|
|
| Python, Redux |
Martin Heller discusses some of the Python 2.1 changes in his latest Byte column. Nothing too involved here, but it gives an overview for those not familiar with the latest Python version.
Posted to Python by Chris Rathman on 5/14/01; 6:22:06 PM
Discuss
|
|
| FP in Python |
|
This article discusses general concepts of functional programming, and illustrates ways of implementing functional techniques in Python.
There's also Part 2.
Uses the Xoltar functional.py module (there's also a lazy.py at the same link).
Thanks to Manuel M T Chakravarty on the haskell-cafe list.
Posted to Python by andrew cooke on 5/8/01; 1:07:00 PM
Discuss
|
|
| Python Iterators (proposal) |
|
(via Daily Python-URL)
This document proposes an iteration interface that objects can
provide to control the behaviour of 'for' loops. Looping is
customized by providing a method that produces an iterator object. The iterator provides a 'get next value' operation that produces the next item in the sequence each time it is called, raising an exception when no more items are available.
We discussed iterators here in the past.
This proposal doesn't seem to be very innovative or sexy. Maybe another design iteration is needed
Posted to Python by Ehud Lamm on 5/2/01; 6:14:06 AM
Discuss
|
|
| Free Zope Hosting |
|
For a limited time ZopeSite.com is offering free Zope-Driven websites.
Sign up now and receive a free ZopeSite.com website as in yoursitename.zopesite.com. Note: You must provide a valid email address, otherwise you will not recieve your password to login.
What is Zope? Zope is an open-source web application platform for developing high-performance, dynamic, database-driven websites. Or as the O'Reilly Draft Zope Book puts it, "Zope is an Open Source application server, focusing on content management, portals, and custom services. Zope specializes in rapid deployment of rich network services to diverse audiences."
Should be fun to play with. The programming language connection? You can extend Zope with so called Zope products using Python.
Posted to Python by Ehud Lamm on 4/21/01; 12:53:11 PM
Discuss
|
|
| pyAda |
|
pyAda enables programmers to write Python extensions in Ada 95 or extend Ada 95 programs with a Python interpreter. The goal is to make it possible to use Python in any way that you can use it from or with C.
Does the word scripting ring any bells?
The comparisons page discusses some other options for connecting Python and Ada, including COM and SOAP. Alas, there is no real comparsion of the different techniques.
Posted to Python by Ehud Lamm on 4/15/01; 12:55:43 PM
Discuss
|
|
| A Perl Hacker in the Land of Python |
|
By Jon Udell.
I'm a big fan of Perl, have done nearly all my Web programming in that language, and have attended all three annual Perl conferences. So it was a real change of pace to attend IPC8, the Eighth International Python Conference
A nice comparison of Perl's and Pythons's different language philosophies.
Posted to Python by Ehud Lamm on 4/9/01; 2:28:38 PM
Discuss
|
|
| Using Mix-ins with Python |
|
Multiple inheritance seems to be out of fashion in some places (Java, C#) - this article shows when it can be useful (there's a story that mixin was a way of specifying toppings for ice-cream near where they developed Lisp/CLOS).
Seen at QubeCorner, which has some good info.
Posted to Python by andrew cooke on 3/22/01; 12:05:16 AM
Discuss (1 response)
|
|
| Python Helps Disney Write a New Script |
|
(via Daily Python-URL).
Describes an animation production system built using Python.
The article contains some interesting observations comparing Python to Perl, and discussing language integration.
Perhaps that most interesting issue, the article focuses on the scriptability capabilities of the application. It should come as no surprise to LtU readers that scriptability adds a lot of power to an application.
Posted to Python by Ehud Lamm on 3/7/01; 3:12:57 AM
Discuss (1 response)
|
|
| Functional Programming in Python |
|
Seen on Daily Python but their link seems to access a broken cgi program at the moment.
This is part a larger work by David Mertz. The chapter gives kind of an introduction to FP and some of the facilities within Python. Aimed at Python programmers who have little familiarity with the functional programming aspects of the language.
Posted to Python by Chris Rathman on 2/21/01; 8:09:51 PM
Discuss (2 responses)
|
|
| Sociology of Language Development (Python) |
|
I think this thread shows how tricky it can be to keep the balance between developers and users of a language. IMHO Python has got it just about right, with PEPs describing new features and (until now) regular updates on the development process posted to the c.l.python.
Even so, there's clearly some friction. If anyone can compare this with Perl development, I'd like to know if they do any better.
Posted to Python by andrew cooke on 2/9/01; 6:30:26 AM
Discuss (4 responses)
|
|
| Closures in Python |
|
Python is one of my favorite languages but the lack of proper closures is an obvious sore point. NeelK says they are coming and cites a proposal for Statically Nested Scopes.
Ok, it's too late for Santa to deliver this year, but I'm hoping that the New Year brings true closures to Python (and contrary to a recent thread in comp.lang.python, the language does not have a proper notion of closures).
Posted to Python by Chris Rathman on 12/25/00; 8:00:13 PM
Discuss
|
|
|
