We Keep Coding

Is there a reason I should be dissuaded from using an alternative templating engine in my Django app?

I've done a few small-ish Django projects, and each time I've been struck by the apparent limitations of Django's templating language. Just as a random example, I was shocked to learn that if, in the context of a template, I had a variable bar and a dict foo, I couldn't access foo[bar] unless I wrote my own filter to do it.
I've read that the reason for this is because Django was created for environments where the people designing the pages were not programmers. I understand that.
But let's say that's not a problem for me. Is there a reason why I should stick with Django's templating language, rather than switching over to something with a lot more power, like Mako (where you can even execute arbitrary Python expressions)?
I had the opportunity to use Mako for a school project a while back, and I really loved the power of it. For example, as part of the project, we had to make a big table, where building each row and cell was fairly complex. Yet, I could make my template look something like:
<table>
% for foo in foos:
${makerow(row)}
% endfor
</table>
<%def name="makerow(row)">
<tr>
# Blah blah blah (possibly a call to makecell somewhere)
</tr>
</%def>
Maybe this is a violation of separation of presentation and logic, but boy is it nice and clean. Subroutines! Abstraction! Good stuff.
And a follow-up question: If using an alternative templating language isn't frowned upon by the Django community, does anyone have any to suggest? Like I said, I really like Mako, but it's literally the only one I've used other than Django's.

I'll be honest, I didn't thoroughly read the responses. But I'm guessing it's a lot of "no python in your templates" and "your view shouldn't have much logic" type stuff.
If you put idealism aside and opt for pragmatism then I think Mako is a fine choice. I'm using it in a production capacity (mainly for speed, power and dynamic inheritance) for 3+ years now. It hasn't failed or been otherwise annoying in any way.
The idealists are correct, but sometimes you have to go for what's doable vs what's right. If you are not limited by the Django templating engine use it. If you need more power, Mako and Jinja are fine choices.
Django makes it very easy to swap out templating engines and keep most things working as before:
http://docs.djangoproject.com/en/dev/ref/templates/api/#using-an-alternative-template-language

Executing arbitrary code in templates should not be considered an inherently good thing. Taking advantage of such functionality is usually a sign that your architecture is broken.
That said, if you read the Django documentation, it explicitly says that you should feel free to use, discard, and replace any components you wish. Django is intentionally modular, and in fact, the two most trivially-replaceable components are the templating engine and the ORM.
If you want to use Mako instead of the Django templating engine, just use Mako.

The one reason I'd refrain from using jinja, Mako or anything else is that it may not make your app future proof with django enhancements.
There was a GSoc project proposal last year, by Alex Gaynor to make the template loading fast. - It was then retracted in favor of NoSQL project.
But with many more core developers and faster clearing of tickets, I'd stick to django full stack, knowing fully well, that components have to be changed to by home grown ones eventually.
If you are really looking for a glue framework on awesome python libraries, including the ones you choose, Flask is out there.

addons.mozilla.org is using Django + Jinga: https://github.com/jbalogh/zamboni
Not sure whether or not the community frowns on Jinga, but many people like it, as an example.

If you did mean "app", rather than "project", and it's not for entirely private use, I would recommend that you not change the template engine; it will make the app much less likely to ever be used by anyone else as it'll require them to alter some core settings, and it may break interaction between it and other apps or the project as a whole.

Your example reminds me of the old PHP days when people would mix PHP with html all over the place. Felt really powerful. Until one day people realized that the mess is unmaintainable.
If the design is chopped up into "functions", will a designer understand it then? It will probably annoy him.

Form generation/validation libraries in Python

I'm a developer in Python coming from a PHP background. In PHP most frameworks included a decent form generation/validation API (Zend and CakePHP come to mind). At my new company we try to stay away from Django and use Werkzeug extensively.
I've looked at FormEncode and Formular. Formular seems better to me, but there must be stuff my noobish brain is not aware of. Please enlighten me.

There's also WTForms, which is a fairly minimal forms library that integrates well with Werkzeug in my experience.

FormEncode is more a validation library and not very good at generating forms.
Personally, I don't like to intermix output generation (forms) and validation. As I see some shortcomings in FormEncode, which tried to remove in my own implementation called pycerberus. However it doesn't do any form generation at all.
The reason why I don't like to have html generation + validation together is that because:
I need validation also in non-ui contexts like server applications, libraries and I don't want to switch libraries but maintain one toolset.
There are very good tools for output generation and I'd like to choose the one that suits me best. In case I need extra functionality there, the choice is really limited.

PHP Frameworks (CodeIgniter, Yii, CakePHP) vs. Django

I have to develop a site which has to accomodate around 2000 users a day and speed is a criterion for it. Moreover, the site is a user oriented one where the user will be able to log in and check his profile, register for specific events he/she wants to participate in. The site is to be hosted on a VPS server.Although I have pretty good experience with python and PHP but I have no idea how to use either of the framework. We have plenty of time to experiment and learn one of the above frameworks.Could you please specify which one would be preferred for such a scenario considering speed, features, and security of the site.
Thanks,
niting

This is a very subjective question but personally I'd recommend Django. Python is a very nice language to use and the Django framework is small, easy to use, well documented and also has a pretty active community.
This choice was made partly because of my dislike for PHP though, so take the recommendation with a pinch of salt.

Most of the frameworks out there nowadays are fast enough to serve whatever needs you will have. It really depends on in which environment you feel most comfortable. Though there are nuances here and there, MVC frameworks share a lot of the same principles, so whichever you choose to use is really a matter of which you most enjoy using.
So, if you like Python more, there's your answer. Use a Python framework, and Django is the best. If you like PHP more (which I personally don't), you've got some more decisions to make. But any of the PHP frameworks are fine. They really are. Just pick one that looks nice with comprehensive documentation and get to work.

I've worked with CakePHP and Django and I really recommend Django. I don't know too much about CodeIgniter, but I remember ruling it out when I was evaluating frameworks myself about a year ago. CakePHP seemed much more developed at the time.
First of all, the Django community is much bigger and has spent a lot of time focusing on reusable apps. This means that you get a lot of functionality for free. Pair this with the django admin, and you have a lot of things already done for you. I haven't kept up with the PHP frameworks much, but I'm pretty sure Django is also more developed.
This is more of a personal thing, but I just like Python over PHP. Compare the way models are done in CakePHP and Django: http://book.cakephp.org/view/67/Understanding-Models, http://docs.djangoproject.com/en/dev/topics/db/models/#topics-db-models. The python is clearly more readable.
Keep in mind that Django gives you an awesome ORM and builds your schema for you, i.e. you never have to touch the database if you don't want to. With the PHP frameworks, you have to do your own db design, which just slows me down at this point. You can always go in and add indexes for speed later.
This is probably the most biased, but if you are starting a new application - seriously - just stick with Django or Ruby on Rails. There is a reason everyone talks about them and they have the biggest communities and best developers behind them.
You can also check out Pinax for a lot of Django goodies.

Codeigniter it's fast and very documented also has a large community to and finaly friendly with the programmer.

CodeIgniter is a great PHP framework that is fast and has excellent documentation. Start reading through their user guide and it will give you a good idea how to work with the framework.

Extending Matchu:
Or, -If you like PHP more- its time to learn/growup about other things like Python. Its not hard to learn, and when you get started it gets very enjoyable.
Many people has done the PHPtoPython/Django port, like Mozilla, Netgeo, Nasa, TheOnion, etc.

If for the PHP part I would choose CodeIgniter - it doesn't get too much into your way. But it doesn't have any code/view/model generators out of the box, you need to type a bit.
But languages other than PHP appear to be more sexy.

I am using CodeIgniter 1.7.2 and for complex websites it's very good and powerfull, but it definitely is missing some kind of code generator which will allow for example to build an IT application in one click.
I had the impression (from watching a tutorial) that Django has it.

Can anyone point out the pros and cons of TG2 over Django?

Django is my favorite python web framework. I've tried out others like pylons, web2py, nevow and others.
But I've never looked into TurboGears with much enthusiasm.
Now with TG2 out of beta I may give it a try. I'd like to know what are some of the pros and cons compared to Django.

TG2 has several advantages that I think are important:
Multi-database support
sharding/data partitioning support
longstanding support for aggregates, multi-column primary keys
a transaction system that handles multi-database transactions for you
an admin system that works with all of the above
out of the box support for reusable template snipits
an easy method for creating reusable template tag-libraries
more flexibility in using non-standard components
There are more, but I think it's also important to know that Django has some advantages over TG2:
Larger, community, more active IRC channel
more re-usable app-components
a bit more developed documentation
All of this means that it's a bit easier to get started in Django than TG2, but I personally think the added power and flexibility that you get is worth it. But your needs may always be different.

TG2 takes Pylons and changes some defaults - object dispatching instead of Routes, and Genshi instead of Mako. They believe there's only one way to do it, so apps can rely on the same API for any TurboGears website.
Similarities
TG2 and Django both distinguish between websites and components, so you'll eventually see reusable building blocks for TurboGears, too.
Differences
Django uses its own handlers for HTTP, routing, templating, and persistence. Django also has stellar documentation and an established community.
TurboGears defaults to best-of-breed libraries, which apparently are Paste, object dispatching, Genshi, and SqlAlchemy. This philosophy produces a better all-round toolset, but at the risk of instability - because it means throwing away backwards compatibility if and when better libraries appear.

Pros.
SQLAlchemy > django ORM
Multiple template languages out of the box (genshi,mako,jinja2)
more WSGI friendly
Object Dispatch > routes > regexp routing. You can get the first 2 with TG2
Almost all components are optional you can keep the core and use any ORM, template, auth library, etc.
Sprox > django forms
Cons.
- Admin is more basic (no inline objects yet!)
- less third party apps
- "app" system still in the making.
- given it's modularity you need to read documentation from different sources (SQLAlchemy, Genshi or Mako, repoze.who, Pylons, etc.)

I was struggling with the same question months ago and decided for Turbogears 2, and my reasoning was simple. "I'm new to python, I want to learn it not just for web-projects but as a substitute to php for scripting small helpers"
What I didn't like about Django, to me looks like a "close platform". ORM, Template system, sessions, etc they all are Django's
On the other hand, Turbogears 2 uses already known open platforms and just glued them, just like Appfuse does it for Java
With TurboGears 2 I learn SQLAlchemy that I can use later for small python scripts, or from the python shell to solve common tasks.
Main drawbacks are the lack of complete documentation and error messages.
Sometimes you have to search very deep to find simple solutions, the learning curve is steep, but it pays long term. The error messages where to me very confusing (coming from more than 10 years in Java development). I had lost many hours trying to find an "ascii encode error" when the real problem was a module not being imported.
That's my opinion, just remember I'm new to python and I could be wrong about many things stated here.

Besides what Nikhil gave in his answer, I think another minor difference is that Turbogears provdes some support for javascript widgets and integration with Mochikit.
Whereas Django steadfastly remains javascript framework neutral.
(At least this was true with older versions of Turbogears... this might have changed with TG2)
Edit: I just went over TG2 documentation and see that it did indeed change. Turbogears now uses ToscaWidgets which can use jQuery, ExtJS, Dojo, etc. underneath. This nicely makes it more framework neutral while still providing nice javascript widgets.
This strikes me as a pro for Turbogears if you don't have any javascript experience and a pro for Django if you are writing a lot of specialized javascript.

One of the most important questions is not just what technical features this platform provides or that platform provides, but the driving philosophy of the open source project and the nature of the community supporting it.
I've got no dog in this fight myself, but I found Mark Ramm's talk at DjangoCon 2008 to be very interesting on this point (Google will yield no end of subsequent discussion, no doubt).

Because Django uses its own ORM it limits you to learn that ORM for that specific web framework. I think using an web framework with a more popular ORM (like SqlAlchemy which TG uses) increases your employability chances. Just my 2 cents ..

Last I checked, django has a very poor data implementation. And that's a huge weakness in my book. Django's orm doesn't allow me to use the power of the underlying database. For example I can't use compound primary keys, which are important to good db design. It also doesn't support more than a single database, which is not a big deal until you really need it and find that you can't do it without resorting to doing it manually. Lastly if you have to make changes to your database structure in a team-friendly way, you have to try to choose between a set of 3rd party migration tools.
Turbogears seems to be more architecturally sound, doing its best to integrate individual tools that are awesome in their own right. And because TG is more of an integrator, you're able to switch out pieces to suit your preferences. Don't like SQL Alchemy? You can use SQLObject. Don't like Genshi templates? You can use Mako or even django's, although you're not exactly stuck with the default on django either.
Time for tg2's cons:
TG has a much smaller community, and community usually has its benefit.
Django has a much better name. I really like that name ;-)
Django seems simpler for the beginning web developer, with pretty cool admin tools.
TG has decent documentation, but you also need to go to Genshi's site to learn Genshi, SQL Alchemy's site to learn that, etc. Django has great docs.
My 2 cents.

Pros and Cons of different approaches to web programming in Python

I'd like to do some server-side scripting using Python. But I'm kind of lost with the number of ways to do that.
It starts with the do-it-yourself CGI approach and it seems to end with some pretty robust frameworks that would basically do all the job themselves. And a huge lot of stuff in between, like web.py, Pyroxide and Django.
What are the pros and cons of the frameworks or approaches that you've worked on?
What trade-offs are there?
For what kind of projects they do well and for what they don't?
Edit: I haven't got much experience with web programing yet.
I would like to avoid the basic and tedious things like parsing the URL for parameters, etc.
On the other hand, while the video of blog created in 15 minutes with Ruby on Rails left me impressed, I realized that there were hundreds of things hidden from me - which is cool if you need to write a working webapp in no time, but not that great for really understanding the magic - and that's what I seek now.

CGI is great for low-traffic websites, but it has some performance problems for anything else. This is because every time a request comes in, the server starts the CGI application in its own process. This is bad for two reasons: 1) Starting and stopping a process can take time and 2) you can't cache anything in memory. You can go with FastCGI, but I would argue that you'd be better off just writing a straight WSGI app if you're going to go that route (the way WSGI works really isn't a whole heck of a lot different from CGI).
Other than that, your choices are for the most part how much you want the framework to do. You can go with an all singing, all dancing framework like Django or Pylons. Or you can go with a mix-and-match approach (use something like CherryPy for the HTTP stuff, SQLAlchemy for the database stuff, paste for deployment, etc). I should also point out that most frameworks will also let you switch different components out for others, so these two approaches aren't necessarily mutually exclusive.
Personally, I dislike frameworks that do too much magic for me and prefer the mix-and-match technique, but I've been told that I'm also completely insane. :)
How much web programming experience do you have? If you're a beginner, I say go with Django. If you're more experienced, I say to play around with the different approaches and techniques until you find the right one.

The simplest web program is a CGI script, which is basically just a program whose standard output is redirected to the web browser making the request. In this approach, every page has its own executable file, which must be loaded and parsed on every request. This makes it really simple to get something up and running, but scales badly both in terms of performance and organization. So when I need a very dynamic page very quickly that won't grow into a larger system, I use a CGI script.
One step up from this is embedding your Python code in your HTML code, such as with PSP. I don't think many people use this nowadays, since modern template systems have made this pretty obsolete. I worked with PSP for awhile and found that it had basically the same organizational limits as CGI scripts (every page has its own file) plus some whitespace-related annoyances from trying to mix whitespace-ignorant HTML with whitespace-sensitive Python.
The next step up is very simple web frameworks such as web.py, which I've also used. Like CGI scripts, it's very simple to get something up and running, and you don't need any complex configuration or automatically generated code. Your own code will be pretty simple to understand, so you can see what's happening. However, it's not as feature-rich as other web frameworks; last time I used it, there was no session tracking, so I had to roll my own. It also has "too much magic behavior" to quote Guido ("upvars(), bah").
Finally, you have feature-rich web frameworks such as Django. These will require a bit of work to get simple Hello World programs working, but every major one has a great, well-written tutorial (especially Django) to walk you through it. I highly recommend using one of these web frameworks for any real project because of the convenience and features and documentation, etc.
Ultimately you'll have to decide what you prefer. For example, frameworks all use template languages (special code/tags) to generate HTML files. Some of them such as Cheetah templates let you write arbitrary Python code so that you can do anything in a template. Others such as Django templates are more restrictive and force you to separate your presentation code from your program logic. It's all about what you personally prefer.
Another example is URL handling; some frameworks such as Django have you define the URLs in your application through regular expressions. Others such as CherryPy automatically map your functions to urls by your function names. Again, this is a personal preference.
I personally use a mix of web frameworks by using CherryPy for my web server stuff (form parameters, session handling, url mapping, etc) and Django for my object-relational mapping and templates. My recommendation is to start with a high level web framework, work your way through its tutorial, then start on a small personal project. I've done this with all of the technologies I've mentioned and it's been really beneficial. Eventually you'll get a feel for what you prefer and become a better web programmer (and a better programmer in general) in the process.

If you decide to go with a framework that is WSGI-based (for instance TurboGears), I would recommend you go through the excellent article Another Do-It-Yourself Framework by Ian Bicking.
In the article, he builds a simple web application framework from scratch.
Also, check out the video Creating a web framework with WSGI by Kevin Dangoor. Dangoor is the founder of the TurboGears project.

If you want to go big, choose Django and you are set. But if you want just to learn, roll your own framework using already mentioned WebOb - this can be really fun and I am sure you'll learn much more (plus you can use components you like: template system, url dispatcher, database layer, sessions, et caetera).
In last 2 years I built few large sites using Django and all I can say, Django will fill 80% of your needs in 20% of time. Remaining 20% of work will take 80% of the time, no matter which framework you'd use.

It's always worth doing something the hard way - once - as a learning exercise. Once you understand how it works, pick a framework that suits your application, and use that. You don't need to reinvent the wheel once you understand angular velocity. :-)
It's also worth making sure that you have a fairly robust understanding of the programming language behind the framework before you jump in -- trying to learn both Django and Python at the same time (or Ruby and Rails, or X and Y), can lead to even more confusion. Write some code in the language first, then add the framework.
We learn to develop, not by using tools, but by solving problems. Run into a few walls, climb over, and find some higher walls!

If you've never done any CGI programming before I think it would be worth doing one project - perhaps just a sample play site just for yourself - using the DIY approach. You'll learn a lot more about how all the various parts work than you would by using a framework. This will help in you design and debug and so on all your future web applications however you write them.
Personally I now use Django. The real benefit is very fast application deployment. The object relational mapping gets things moving fast and the template library is a joy to use. Also the admin interface gives you basic CRUD screens for all your objects so you don't need to write any of the "boring" stuff.
The downside of using an ORM based solution is that if you do want to handcraft some SQL, say for performance reasons, it much harder than it would have been otherwise, although still very possible.

If you are using Python you should not start with CGI, instead start with WSGI (and you can use wsgiref.handlers.CGIHandler to run your WSGI script as a CGI script. The result is something that is basically as low-level as CGI (which might be useful in an educational sense, but will also be somewhat annoying), but without having to write to an entirely outdated interface (and binding your application to a single process model).
If you want a less annoying, but similarly low-level interface, using WebOb would provide that. You would be implementing all the logic, and there will be few dark corners that you won't understand, but you won't have to spend time figuring out how to parse HTTP dates (they are weird!) or parse POST bodies. I write applications this way (without any other framework) and it is entirely workable. As a beginner, I'd advise this if you were interested in understanding what frameworks do, because it is inevitable you will be writing your own mini framework. OTOH, a real framework will probably teach you good practices of application design and structure. To be a really good web programmer, I believe you need to try both seriously; you should understand everything a framework does and not be afraid of its internals, but you should also spend time in a thoughtful environment someone else designed (i.e., an existing framework) and understand how that structure helps you.

OK, rails is actually pretty good, but there is just a little bit too much magic going on in there (from the Ruby world I would much prefer merb to rails). I personally use Pylons, and am pretty darn happy. I'd say (compared to django), that pylons allows you to interchange ints internal parts easier than django does. The downside is that you will have to write more stuff all by youself (like the basic CRUD).
Pros of using a framework:
get stuff done quickly (and I mean lighning fast once you know the framework)
everything is compying to standards (which is probably not that easy to achieve when rolling your own)
easier to get something working (lots of tutorials) without reading gazillion articles and docs
Cons:
you learn less
harder to replace parts (not that much of an issue in pylons, more so with django)
harder to tweak some low-level stuff (like the above mentioned SQLs)
From that you can probably devise what they are good for :-) Since you get all the code it is possible to tweak it to fit even the most bizzare situations (pylons supposedly work on the Google app engine now...).

For smaller projects, rolling your own is fairly easy. Especially as you can simply import a templating engine like Genshi and get alot happening quite quickly and easily. Sometimes it's just quicker to use a screwdriver than to go looking for the power drill.
Full blown frameworks provide alot more power, but do have to be installed and setup first before you can leverage that power. For larger projects, this is a negligible concern, but for smaller projects this might wind up taking most of your time - especially if the framework is unfamiliar.