Latest comments

In response to: How Python wins on the Web

massimo [Visitor] ·

I agree that we need to make it easier for developers to deploy applications, so why not do it through a web application as Gluon does?

Gluon is a free open source framework for agile development of secure database driven web applications, written in Python, programmable in Python. Stable API and supported since October 1st 2007. Gluon requires no installation and includes a ticketing system and a web based database administrative interface.

PermalinkPermalink 12/25/07 @ 13:14

In response to: How Python wins on the Web

slipkid [Member]

I have to agree with noob, python could in theory be useful as a web framework but why.That is not where it belongs I believe php does its job there, and having toyed with rails I just dont think that python should try to compete with those two.I know it is a great way to become a "popular" language,at last check popular was for the teenagers with ipods and zwinkys. I believe that python is well suited for programming and will only find continued success if it focuses in that direction. If you need scripts use perl or php, need a good framework join the rails bandwagon! One more thing I just have to laugh when I read about how java is developing some new piece of mind numbing coma inducing crap that is going to revolutionize the web ah bullstein! Java blows, and python rocks I just dont want to see it turn into another huge hack.Python is a happy thing :-) unlike the little shop of java beast that sucks the life out of a coder and spits out a lifeless carcass of a once contented and prosperous individual!Just my opinion oh and by the way I just read that I could have used mark-up Dang I could have really got my point across that way..Remember if you cant laugh at yourself then make fun of other people!

PermalinkPermalink 12/20/07 @ 17:14

In response to: Subway's new Ajax framework

mikes apartment [Visitor] ·

Nice website

PermalinkPermalink 07/19/07 @ 14:50

In response to: How Python wins on the Web

Paul [Visitor] ·

Always looking for more info and comments on Python. Every time I think I've learned something, I keep finding out how much of a newb I am. Oh well.

PermalinkPermalink 04/21/07 @ 06:14

In response to: Templating languages, and YAPTL

Terrence Brannon [Visitor] ·

I do not like ElementTree. You can't even search for nodes based on element attributes. The Perl module of similar functionality, HTML::TreeBuilder, has had such functionality forever.

PermalinkPermalink 03/13/07 @ 09:59

In response to: Getting ready for Subway 0.2

Ummoe [Visitor] ·

Ummoewhereas a single link will not.

PermalinkPermalink 03/09/07 @ 06:15

In response to: How Python wins on the Web

joeldg [Visitor] ·

as a note.
Cpanel IS written in python. (I know, I run five cpanel servers and have used it for years)
Eve-Online, one of the big MMORPG's is written in Python. (
Google uses Python all over.

We have a lot of successes. Rails is currently more buzz and a lot of larger companies don't want to touch it because it is not mature yet.

PermalinkPermalink 02/07/07 @ 08:15

In response to: How Python wins on the Web


PermalinkPermalink 01/29/07 @ 07:32

In response to: Subway's new Ajax framework

P-Y Delens [Visitor]

Where can I find the CrackAjax library?
Thanks on forward

PermalinkPermalink 10/05/06 @ 07:13

In response to: Templating languages, and YAPTL

peter Hunt's ur personal blog is quite interesting.
Data entry

PermalinkPermalink 09/28/06 @ 00:10

In response to: How Python wins on the Web

Oliver [Visitor]

for an incredibly small and smart Python web toolkit check out

PermalinkPermalink 08/03/06 @ 01:53

In response to: How Python wins on the Web

someguy [Visitor]

You're fogetting, I think, the largest problem facing python + web: deployment. Until cheap hosts and sysadmins can just as easily run PHP on apache side by side w mod_python (or some new thing) python + web won't catch on. Plone and Zope are miserably complex. Focus should be on creating an easy method of stable deployment, and that would be mod_python without prohibitive dependencies and without the security concerns those cheap hosts may have about users being able to "touch" more of the apache process. You can code as many blogging systems as you like, but until you can pack it and hand it off to Joe blogger for his $10 a month server, have him click intall it like Wordpress, you haven't even got a foothold on the mountain.

PermalinkPermalink 04/29/06 @ 21:37

In response to: Templating languages, and YAPTL

us flags [Visitor] ·

I am thinking about starting a blog on my hobbie. I have been collecting flags for many years and have a lot of great information. At first, I was going to start a website, but that looked to hard. Your blog helped. Thanks.

PermalinkPermalink 04/26/06 @ 12:09

In response to: How Python wins on the Web

rainman [Visitor] ·

I miss a benchmark on the web. I saw such thing for programming languages. There are to main critteria: performance vs. development. It would be nice to see the same functionality application to be programmed in various web frameworks with measured performance.

Maybe, this would be to much simplified.

PermalinkPermalink 04/04/06 @ 05:35

In response to: How Python wins on the Web

veridicus [Visitor] ·

I try to use Python everywhere possible. For most web apps I end up using PHP, but when I need a more robust framework I always think of Python next.

PermalinkPermalink 01/31/06 @ 12:48

In response to: Subway's new Ajax framework

Nathen Hinson [Visitor]

I would agree with Peter's negative comments about AJAX, however I think that this issue revolves around people looking at AJAX methodologies supplanting traditional web pages ( in the case of CGI I would eagerly agree to this supplating ). I tend to look to AJAX related pages as great replacements for RADs. I think AJAX pages would make a great replacement for things along the lines of 4D, Filemaker, Access etc. As Google has shown, AJAX apps are a breeze to distribute and update. This alone makes me a big fan. I personally see the se two things ( the traditional web-page, and AJAX apps ) living side-by-side, perhaps literally in the case of tabbed browsing. I think CrackAJAX is certainly going in the right direction, a library,framework , etc should make your life easier by giving you LESS to learn not more in the form of Javascript, DHTML,HTML,XML,DOM etc. I really look forward to trying it out on some sample projects of my own. The sample in SVN worked swimmingly hot off the download.

Thanks very much

PermalinkPermalink 01/31/06 @ 10:04

In response to: Templating languages, and YAPTL

A good comparison is to the View and Controller layers in Apple-style MVC.

In Apple MVC, the View layer consists solely of graphical widget objects, assembled live and stored in serialized form (.nib) using Interface Builder, and the Controller layer contains the glue code that pulls data from the Model layer and inserts it into the View objects.

With DOM-style templating engines, the tagged HTML file is analogous to the .nib file, the templating engine the AppKit framework that turns this data back into live objects, and the Python code that manipulates these objects the Controller layer.

Incidentally, I do think there's something to be said for stuff like automatic interpolation of dictionary values or instance variables to reduce the amount of tedious glue code developers need to write in common situations (c.f. Cocoa Bindings). Though I'd suggest you allow for that by ensuring your basic API is sufficiently open and flexible (i.e. supports introspection) that such functionality can be built on top of it, rather than trying to include such convenience features in the core engine. Otherwise you'll end up in the same bind as the traditional macro-style engines of endless feature creep and API complexity as it tries to be all things to all men.

PermalinkPermalink 01/28/06 @ 13:01

In response to: Templating languages, and YAPTL

Chris McDonough [Visitor] ·

Doh... the above blockquote demonstrating structure should have tags around the "some stuff" (implying that what you pass in is html).

PermalinkPermalink 01/28/06 @ 08:24

In response to: Templating languages, and YAPTL

Chris McDonough [Visitor] ·

Yes. Every meld3 node has a 'parent' attribute, and this attribute is maintained as you move nodes around via the elementtree/meld3 API. You can delete a node from its parent by calling 'node.deparent()'.

The closest equivalent to viewing the equivalent of PyMeld's ._content is to call 'node.shortrepr()'.

The equivalent to the concept of assigning to ._content is done via "node.content('some stuff')". If the content is another node as opposed to text, you need to do a multiline thing which deletes the children of the node andthe nodes. This could be made easier if meld3 allowed its "content" method to accept another node too instead of only allowing text (which is simple and is probably a good idea). The 'content' method accepts an optional second argument named 'structure' which if it's true will turn off HTML escaping of the text passed in, which allows you to do things like:

node.replace('some suff', structure=True)

Replacing a node is done via "node.replace('some stuff')". This also accepts the structure flag and could also accept a node instead of text (it doesn't now).

"You can also use the elementtree API against all nodes, and do node.text = 'foo' or node._children = [] to clear all child nodes, node.find('bar') to find the first bar node beneath this node, and so on.

Anyway, it'd be great if you could take a closer look at meld3 and see what you don't like about it; it can obviously be changed to make things easier as necessary.

PermalinkPermalink 01/28/06 @ 08:23

In response to: SQLComp, an experimental LINQ-in-Python

fumanchu [Member]

Please note that SQLComp is experimental, and I intended for someone to perhaps pick it up, hack on it, and make something cool.

I decided to pick it up, hack on it, and make something cool--two years ago. It's called Dejavu. ;) See the logic* and codewalk*** modules, which "do the same thing" (only putting the iteration outside the lambda). I used logic.Expression instead of "make_query", and **kwargs instead of ctx.

I would also note that I found using the ast to be far too slow, and went with decompiling co_code entirely for speed reasons. You might want to do some speed tests of your own soon.




PermalinkPermalink 01/27/06 @ 22:32