Develop Reference

Python/Django for an enterprise large scale web based system?

My company is highly dependent on Java and jsf; All projects since I was hired are implemented using them. But most of those projects are facing problems related to performance and availability. So am finally considering a shift to other technologies and I have tried to research in the net, and im about to decide to try python. But before i start i would like to hear ur answer that Python would solve me the performance problems we are facing.
To make things clear the performance problems we mostly face are related to glassfish server and page loading. We are currently using ice faces and have tried wood stock back then. Additionally I can't use .net for some policy related issues. And PHP is also out of question due to some security leaks experienced in earlier projects.
So am expecting to read the pros and cons related with performance and availability in trying to convince my boss and customers in to python.

I have some doubts that you will gain performance by using Django or a Python based solution. I don't know the Glassfish server nor how it scales up but unless badly designed I don't see why it should perform badly.
From the explanation of your performance issues, it doesn't seem to be a problem of language speed but instead, server configuration and availability.
Assuming that your Java code is reasonably optimal (i.e. efficient and acceptably fast), you won't solve the problem by using some Python solution. Instead you should invest some time into studying caching mechanisms and/or proxy solutions.
Depending on how your server is setup, an additional advice would be to let all the static content be served by a dedicated server such as Apache, nginx or similar and only leave the the dynamic content on to be interpreted by your glassfish server.
Since your projects are written in Java you are in theory using a language that can potentially be faster than Python, I don't see why a Python solution would perform better unless there is something wrong with the framework you are using.
If you want to talk about prototyping or faster development, then that's a different subject discussed multiple times on stackoverflow.

What's the next steps for moving from appengine to full django?

I'm super new to programming and I've been using appengine to help me learn python and general coding. I'm getting better quickly and I'm loving it all the way :)
Appengine was awesome for allowing me to just dive into writing my app and getting something live that works (see http://www.7bks.com/). But I'm realising that the longer I continue to learn on appengine the more I'm constraining myself and locking myself into a single system.
I'd like to move to developing on full django (since django looks super cool!). What are my next steps? To give you a feel for my level of knowledge:
I'm not a unix user
I'm not familiar with command line controls (I still use appengine/python completely via the appengine SDK)
I've never programmed in anything other than python, anywhere other than appengine
I know the word SQL, but don't know what MySQL is really or how to use it.
So, specifically:
What are the skills I need to learn to get up and running with full django/python?
If I'm going to host somewhere else I suppose I'll need to learn some sysadmin type skills (maybe even unix?). Is there anywhere that offers easy hosting (like appengine) but that supports django?
I hear such great things about heroku I'm considering switching to RoR and going there
I appreciate that I'm likely not quite ready to move away from appengine just yet but I'm a fiercely passionate learner (http://www.7bks.com/blog/179001) and would love it if I knew all the steps I needed to learn so I could set about learning them. At the moment, I don't even know what the steps are I need to learn!
Thank you very much. Sorry this isn't a specific programming question but I've looked around and haven't found a good how-to for someone of my level of experience and I think others would appreciate a good roadmap for the things we need to learn to get up and running.
Thanks,
Tom
PS - if anyone is in London and fancies showing me the ropes in person that would be super awesome :)

First up, you can benefit by doing some RoR work by learning a new language. However, I don't know if that'll be entirely beneficial to you right now since you still are learning. I'd stick with Python and Django (or AppEngine) for the moment, until you can grasp some of the more advance concepts. Then, by all means, learning new languages will be fantastic.
As for moving to Django from AppEngine. There isn't a whole lot that's different. The way you define models is similar, but has different types for the definition. As you mentioned, hosting is another consideration.
There should be plenty of hosting options (mod_wsgi is what you're after) based on Apache. Django in particular has seen quite a bit of popularity, and hosting usually springs up for popular frameworks.
I don't think you'll need to know too much sysadmin stuff. This will all depend on the kind of hosting you can find. Same goes for the database. Hosting providers usually offer databases preconfigured so you shouldn't need to worry about that too much.
Django, along with many other frameworks, provide an ORM (Object Relational Mapper) which abstracts away having to write SQL, by calling methods on objects and accessing their properties. I'd advise learning a little bit of SQL to understand it at a bare minimum though.
The Django tutorial is excellent! If you decide to go the Django route, I'd highly recommend working through the entire thing. A development server comes bundled, so you can try out your work instantly without worrying about a provider. Once you have something you want to share with the world, you can worry about hosting then.
I started off using Windows for Django development and it was quite easy. The amount of command line work you need to do is minimal. Really. Not something you need to worry about, as the tutorial covers all 4 or so commands you need to know.
Django hosting provides links to hosting providers, though I'm not sure how up to date that list is.
Getting started in Django is pretty simple. Once you want to host it, there's a bit more work involved - but that can come later. The friction is minimal. Follow the tutorial, it will take you through running the server, setting up the database (a free one comes bundled), and coding your first app.

What makes you think you're being locked into a single platform? Did you know that Google's App Engine SDK is open source? Also, there are universities and other organizations who are working on building platforms that will use the App Engine SDK outside of the context of Google? Amazon EC2 is also capable of running App Engine's SDK in a limited capacity. I'd say lock-in is perhaps not the right word to use.
Additionally, I believe AppEngine is going to continue to improve as time goes on. Google is the leader of the Internet; they've done great things and will continue to do so. I believe that anyone who sticks with their platform as a service will experience these great benefits in the years to come.
If your reasoning for moving is purely academic, I'd suggest starting a new project. Moving off of AppEngine's SDK is similar to switching from one framework to another on an already-built application. Like with any framework or platform, there are dependencies that must be dealt with in order to successfully migrate the app from platform A to platform B.

django-nonrel makes it possible to run Django on Google AppEngine: http://www.allbuttonspressed.com/projects/django-nonrel
Beside that there exists a couple of cloud offers like djangy https://www.djangy.com/
With both options you can focus on Django and Python programming and don't have to care about the sysadmin stuff.
On the django homepage there is a very good tutorial to get started with django development: http://docs.djangoproject.com/en/1.2/intro/tutorial01/

What are the skills I need to learn to get up and running with full django/python?
The question can't easily be answered because you haven't described the app. You have to actually write down the technology stack -- in detail -- or you'll never know what skills you need.
The skill list mostly comes from your technology choices. So write down your technology choices. (That's part of configuration management, an important skill you'll need if you move away from GAE.)
Since you've chosen to talk about yourself and not your technology choices, I can only guess what technologies you're using and what skills you'll need.
Here's a common technology stack.
Technically, the OS doesn't matter. Most hosting environments use open source GNU/Linux because the licensing is inexpensive. You, too, can do this. You can start with VMWare and download a nice Linux distro. Or, you can buy a very cheap PC and install Linux directly from a DVD image that you can download and burn.
My company demands that I use the Windows PC they give me. So I develop in Windows and test in VMWare Linux (Fedora 14, actually)
To learn Linux, start with a download and install. Then find a tutorial. Then stop using Windows and learn by doing. Flipping back and forth between Windows and Linux is difficult. I can do it because I don't know Windows very well. I treat Windows as a hyper-complex IDE with all kinds of non-standard, non-POSIX quirks that I try to ignore.
RDBMS. Python comes with SQLite. For a lot of applications, it works fine. It works because web sites tend to be heavy on queries and light on updates/inserts, so SQLite works well. MySQL is nice. It's easy to install and runs on Windows as well as other OS's.
The good thing about Django is you need to know very little SQL. Very little.
However, you do need to know a tiny bit about the "Data Control Language" (Grant, Revoke and Create User) to work with MySQL. You won't create a lot of users. But you do need to create a few to get things running. Also, as your database matures, you'll often need to know a little bit about the "Data Definition Language" (Drop Table).
You will need to know how to backup and restore your database. That's absolutely critical.
So find Database Administrator tutorials to get started.
If your application really uses a lot of sophisticated data, you'll need to buy real books on database design so you can understand how the Django models really work. You don't need to become a SQL guru, but it does help to know what's really going on inside the database.
Application Server. We use Apache with the mod_wsgi module. There are numerous choices. Hosting services vary in what they require and what they permit. Some have Apache, mod_wsgi and Django pre-configured. Some don't. Some do not permit tinkering with the Apache configuration. Some do. You probably don't need to know much about this, because you can probably find a hosting service that will handle the details.
Apache tutorials are all over the place. mod_wsgi is very simple; once you understand how Apache works, mod_wsgi is obvious.
Since you have stuff working, presumably you know about HTML and CSS. Those are important skills, but you probably already have them.
Since you have stuff working, you also might know a lot about Configuration Management and how to control change. This isn't obvious and many people do it wrong. If you don't know about CM, you should find some books or articles on configuration management and change control.
Since you have stuff working, you also might know a lot about quality assurance, unit testing and related topics. If you don't have a complete suite of unit tests, you should probably start learning about unit testing before you start any serious coding for the next release of your product.
Bug Tracking, Problem Reporting, Feature Requests and other management skills are also essential. I can't tell if you have them or don't have them. Or what tools you're using for this. If you're working by yourself, you don't need a lot of formality. However, these are critical skills even if you're a one-person developer. Sticky-Notes on your workstation can work. What's important is the skills to manage bugs and features.

Hey Tom,
I suggest the reasonable evaluation you can make is carefully list the advantages and disadvantages of the choices.
The way I don't regret taking was physical rack server (2006-07), moved to virtual hosting (2008) and now moved to GAE (2009-current). Seeing the rate new features get added to GAE and the costeffectiveness are more reasons to stay. I agree more stuff django can are needed like in my case form preview and form validation with GAE are difficult or too difficult to set up.
I tried RoR and soon thought RoR requires more code to do the same GAE can with less code.
Also with GAE you have absolutely no hardware that can break. If you move to a rack server or a virtual hosting where there are places you can get 5 GB hosting for free but you don't have a plan when you run out of 5 GB and may need to migrate again which you don't want.
MySQL has been around for over 10 years and is quite a different kind of system. It's possible to save blobs in MySQL but don't you think the blobstore GAE has is much better?
If you choose to migrate to a solution with MySQL you can export you data from GAE and import it to MySQL with a tool such as approcket.
Kind regards/Niklas R

Architecting from scratch in Python: what to use?

I'm lucky enough to have full control over the architecture of my company's app, and I've decided to scrap our prototype written in Ruby/Rails and start afresh in Python. This is for a few reasons: I want to learn Python, I prefer the syntax and I've basically said "F**k it, let's do it."
So, baring in mind this is going to be a pretty intensive app, I'd like to hear your opinions on the following:
Generic web frameworks
ORM/Database Layer (perhaps to work with MongoDB)
RESTful API w/ oAuth/xAuth authentication
Testing/BDD support
Message queue (I'd like to keep this in Python if possible)
The API is going to need to interface with a Clojure app to handle some internal data stuff, and interface with the message queue, so if it's not Python it'd be great to have some libraries to it.
TDD/BDD is very important to me, so the more tested, the better!
It'll be really interesting to read your thoughts on this. Much appreciated.
My best,
Jamie

Frameworks
OK, so I'm a little biased here as I currently make extensive use of Django and organise the Django User Group in London so bear that in mind when reading the following.
Start with Django because it's a great gateway drug. Lots of documentation and literature, a very active community of people to talk to and lots of example code around the web.
That's a completely non-technical reason. Pylons is probably purer in terms of Python philosophy (being much more a collection of discrete bits and pieces) but lots of the technical stuff is personal preference, at least until you get into Python more. Compare the very active Django tag on Stack Overflow with that of pylons or turbogears though and I'd argue getting started is simply easier with Django irrespective of anything to do with code.
Personally I default to Django, but find that an increasing amount of time I actually opt for writing using simpler micro frameworks (think Sinatra rather than Rails). Lots of things to choose from (good list here, http://fewagainstmany.com/blog/python-micro-frameworks-are-all-the-rage). I tend to use MNML (because I wrote parts of it and it's tiny) but others are actively developed. I tend to do this for small, stupid web services which are then strung together with a Django project in the middle serving people.
Worth noting here is appengine. You have to work within it's limitations and it's not designed for everything but it's a great way to just play with Python and get something up and working quickly. It makes a great testbed for learning and experimentation.
Mongo/ORM
On the MongoDB front you'll likely want to look at the basic python mongo library ( http://api.mongodb.org/python/ ) first to see if it has everything you need. If you really do want something a little more ORM like then mongoengine (http://hmarr.com/mongoengine/) might be what you're looking for. A bunch of folks are also working on making Django specifically integrate more seamlessly with nosql backends. Some of that is for future Django releases, but django-norel ( http://www.allbuttonspressed.com/projects/django-nonrel) has code now.
For relational data SQLAlchemy ( http://www.sqlalchemy.org/) is good if you want something standalone. Django's ORM is also excellent if you're using Django.
API
The most official Oauth library is python-oauth2 ( http://github.com/simplegeo/python-oauth2), which handily has a Django example as part of it's docs.
Piston ( http://bitbucket.org/jespern/django-piston/wiki/Home) is a Django app which provides lots of tools for building APIs. It has the advantage of being pretty active and well maintained and in production all over the place. Other projects exist too, including Dagny ( http://zacharyvoase.github.com/dagny/) which is an early attempt to create something akin to RESTful resources in Rails.
In reality any Python framework (or even just raw WSGI code) should be reasonably good for this sort of task.
Testing
Python has unittest as part of it's standard library, and unittest2 is in python 2.7 (but backported to previous versions too http://pypi.python.org/pypi/unittest2/0.1.4). Some people also like Nose ( http://code.google.com/p/python-nose/), which is an alternative test runner with some additional features. Twill ( http://twill.idyll.org/) is also nice, it's a "a simple scripting language for Web browsing", so handy for some functional testing. Freshen ( http://github.com/rlisagor/freshen) is a port of cucumber to Python. I haven't yet gotten round to using this in anger, but a quick look now suggests it's much better than when I last looked.
I actually also use Ruby for high level testing of Python apps and apis because I love the combination of celerity and cucumber. But I'm weird and get funny looks from other Python people for this.
Message Queues
For a message queue, whatever language I'm using, I now always use RabbitMQ. I've had some success with stompserver in the past but Rabbit is awesome. Don't worry that it's not itself written in Python, neither is PostgresSQL, Nginx or MongoDB - all for good reason. What you care about are the libraries available. What you're looking for here is py-amqplib ( http://barryp.org/software/py-amqplib/) which is a low level library for talking amqp (the protocol for talking to rabbit as well as other message queues). I've also used Carrot ( http://github.com/ask/carrot/), which is easier to get started with and provides a nicer API. Think bunny in Ruby if you're familiar with that.
Environment
Whatever bits and pieces you decide to use from the Python ecosystem I'd recommend getting to who pip and virtualenv ( http://clemesha.org/blog/2009/jul/05/modern-python-hacker-tools-virtualenv-fabric-pip/ - note that fabric is also cool, but not essential and these docs are out of date on that tool). Think about using Ruby without gem, bundler or rvm and you'll be in the right direction.

Ok, you might be making a mistake, the same one I made when I started with python.
Before you decide on a thing like django, which is an excellent, yet atypical python web framework, spend an night cuddled up with:
This, is a good start. Make sure you do A little Werkzeug watching , Then check out
some classic WebOb. Maybe, if you feel the fire in the blood, and you might, wsgi is a bit flawed, but only to the gods, check out Flask
I'm not saying use it, Django is beautiful too, but if you don't know python, and you go through django, you run the risk of learning a framework.
WSGI is super straightforward. You'll find out about Paste, and Pastescript, and Pylons.
Then, make your decision. It'll be much easier learning stuff doing bare bones wsgi or Flask, stuff like variable assignment, using the interpreter, style concerns, testing, on 3 files for a couple of nights, instead of django. Take 2 nights. Then you'll see the great similarity between python web frameworks, instead of the differences. Hell, you might even roll with Flask.
Just some advice, I did the same thing with ruby, going in through Rails, and... well, strong words were said.
Language, then basic wsgi and testing, then pick your framework and roll

I'm new to python myself, and plan to get more in depth with it this year. I've had a few false starts at this, but always professional needs bring me back to PHP. The few times I've done some development, I've had really good experiences with web2py as a python framework. It's quite well done, and complete in features, while still being extremely lightweight. The database layer seems to be very flexible and mature.
As for TDD/BDD and the rest of your questions, I don't have any experience with python options, but would be interested to hear what others say.

I am using Twisted Framework based Nevow library for python based web app.
All your criteria fit into this single framework.

I need a really good reason to use Python

I have been trying to make a case for using Python at my work. We use C# and ASP.NET for basically all of our development. 80% or more of our projects are web applications. It seems natural that we would look at some of the nice dynamic web languages (Ruby, Python, etc), and with things like IronRuby and IronPython, I started seriously investigating.
I love Python. It's a beautiful, expressive language. It's a joy to code in, for sure. The multitude of python modules and frameworks make it very appealing. Problem is, I cannot think of any specific problems, any specific hurdles that would require a language like Python. ASP.NET gives us RAD, it gives us a full-featured framework and all that good stuff. Also, we all already know C# and have lots of projects in C#, learning a new language just because doesn't quite work.
Can you guys help me think of something to finally convince my boss to really learn Python and start using it on projects?
Edit: I know that no problem requires only one language, I just meant, are there any specific problems in which dynamic languages excel over static languages.
Edit again: Let me also mention that my boss prompted ME to investigate this. He has put aside hours to research these languages, find a good one, learn it, and then figure out how we can use it. I'm at the last step here, I do not need a lecture on why I should consider my motivation for changing something my company does because they do it for a reason.

"Can you guys help me think of something to finally convince my boss to really learn Python and start using it on projects?"
Nope.
Nothing succeeds like success. Use Python. Be successful. Make people jealous.
When asked why you're successful, you can talk about Python. Not before.
Choose projects wisely: things where a dynamic language has significant advantages. Things where the requirements are not nailed down in detail. Things like data transformations, log-file scraping, and super-sophisticated replacements for BAT files.
Use Python to get started doing something useful while everyone else is standing around trying to get enough business and domain information to launch a project to develop a complicated MVC design.
Edit: Some Python to the Rescue stories.
Exploratory Programming
Tooling to build test cases
What's Central Here?
Control-Break Reporting
One More Cool Thing About Python Is...
In Praise of Serialization
And that's just me.
Edit: "boss prompted ME to investigate", "figure out how we can use it" changes everything.
The "finally convince my boss to really learn Python" is misleading. You aren't swimming upstream. See How Do I Make the Business Case for Python for the "convince my boss" problem. The edit says you're past this phase.
Dynamic languages offer flexibility. Exploit that. My two sets of examples above are two areas where flexibility matters.
Requirements aren't totally nailed down. With a dynamic language, you can get started. Rework won't be a deal-breaker. With Java (and C++ and C#) you are reluctant to tackle devastating design changes because it's hard to break everything and get it to compile and work again. In Python, devastating changes aren't as expensive.
Design is in flux because you can't pick components. You can write Wrappers and Facades very easily in Python. It's a scripting language. And, Python modules compose into larger aggregates very simply.
Coding is in flux because requirements and design keep changing. It's scripted -- not compiled. You just make a change to the code and you're off and running. Testing is easier because the work cycle is shorter. It isn't code-compile-build-test it's code-test.
Testing is in flux because the requirements keep changing. Same as above. The work cycle is shorter and faster.

Almost no problem requires a specific programming language, that's just not how things work.
The easiest way to get a new language into an environment like yours is to start a new work project in your own time in the new language. Make it do something you need doing, and write it on your own time. Use it yourself, and other people will probably notice it. They then say "Can you send me that program?" and boom, they're using your new language.
If you really want to something, I would probably write a site in Django, simply because its admin interface blows everyone away.
The main point to remember is that if you start using python, that's one more thing everyone else has to learn, and it's another bullet point that will need to be on every prospective employee's resume. That can get expensive, and management won't like it.

Sneaking a language in is often done by automating tedious manual tasks (especially dynamic/scripting languages like Python/Ruby etc). Set it up so something like deploying builds, or shuffling backups, or whatever is done with Python.
Then casually slip in how easy it was to do, and try to spread some of the enthusiasm around.
Acceptance and awareness should slowly grow from that, and before you know it, management is seriously considering Python for a new project.

Can you guys help me think of
something to finally convince my boss
to really learn Python and start using
it on projects?
Unfortunately, the answer is no. As Harley said, no problem is going to require a specific language. The approach Harley suggested is also a good one. Learn on your time, build an useful app on your time, and maybe, just maybe, someone at your work will want to use it, like it, love it, then want to learn more about it.
Another approach you could take is to get a better understanding of why your company uses .Net (therefore, Windows Server, and probably SQL server) for nearly all development. Once you have a good understanding of why they aren't open to other languages, then you have some fire power to build a business case for the "why not?".
Why pay licensing costs when you have tools that can accomplish the same things? There are free alternatives out there, like Python, that run on free servers.
Why not give your team the chance to grow their professional tool-belt? This is my opinion, but a good developer is a developer that isn't afraid to learn new ways of doing the same thing they've done before.
But, in the end, I wouldn't get your hopes up. Bottom line, it costs money to introduce a new language/environment into an IT shop. Whether it's software, training, or employee rollover, there is a business reason behind utilizing a single language for a company, and sticking to it.
I'm in the exact scenario you're in. I work in a .Net shop, and that's not going to change any time soon. I get by, by working on my own projects in my "free" time. I enjoy it, and it makes for a good balance.
Hope this helps.

Take a step back, and look at your approach. "I know what I want the answer to be, but I can't find any evidence to support it."
Despite the fact that Python is my current first choice language, I am afraid I find myself on the side of your boss! Sorry.
I think you should open your mind and consider all the options from the stance of your organisation's best interest, and see if you don't come to a different conclusion about the best language.
There are many factors in the choice of language, and how pretty it is is a fairly minor one. The availability of staff is a key one. The cost of retraining, availability of the libraries and meta-tools, performance, etc. etc.
Once you have taken into consideration all the different factors (and not just "Oooh! It'd be fun!") and made a balanced assessment (rather than a predetermined answer), you may find that your boss is more willing to listen.
p.s. The suggestion to secretly use Python for work code, and leaving the company with a terrible code debt in a language they are not prepared for seems very unprofessional to me.

The best leverage you're likely going to have is tools and libraries; as others have pointed out, no language is required to solve any particular program. So let's look at Things You Can Leverage Using Python:
Google App Engine
SciPy
pywinauto
django
Those are off the top of my head; finding what's applicable to your team and your company is left as an exercise for the questioner :)

Well, here's a view of why Python programmers make better Java programmers; the concepts are much the same as for your situation.
Essentially, people who learn a language because they want to show that they enjoy programming, like to learn new things, and are more likely to think outside the box.
...if a company chooses to write
its software in a comparatively
esoteric language, they'll be able to
hire better programmers, because
they'll attract only those who cared
enough to learn it. And for
programmers the paradox is even more
pronounced: the language to learn, if
you want to get a good job, is a
language that people don't learn
merely to get a job.
Not only that, but Python enforces "good looking" code and you don't have to do the whole code/compile routine. With IronPython, you can simply code in Python and use it as is; just another .NET tool.

Python got a good start in the Java world as Jython for unit testing. In fact many Java people started using it first that way. Its dynamic scripting nature makes it a great fit for unit tests. Just yesterday I was wishing I could use it or something like it for the unit tests I was writing for a VB.Net project. I'd have to say that it isn't so much about the individual language IronRuby or IronPython as it is about the style of development that they enable. You can write static language like code in either but you don't fully reap the benefits until you can start to think dynamically. Once you grasp those concepts you'll start to slowly change the way you code and your projects will require less classes and less code to implement. Testing, particularly unit tests will become a must since you give up the warm blanket known as a compiler with type safety checks for other efficiencies.

The language is almost never the key to success. Good programmers can be successful in a variety of languages, and you'll find successful projects in almost any language. You won't find the failures that much because those projects just go away never to be heard of again. If you're looking for a new language because you don't have good programmers, even the best language in the world isn't going to help.
And, you haven't said anything about the sort of work you're doing. Python might be a good choice because it has well-supported and widely-used libraries that are critical for you. On the other hand, C# might have better support for the stuff that you want to do. A tool outside of context has no intrinsic merit. You might love screwdrivers, but that doesn't help you row a boat.
If you want to use Python, or any other language, just because you like it, be honest with yourself and those around you. It looks like you've made a decision to switch, don't know why you are switching, and now need to rationalize it with reasons that had nothing to do with your desire to switch. If you had a good reason, you wouldn't be asking here :)
That's not entirely a bad thing, though. Programming is a human enterprise. If the programmers (at whatever level) insanely love a particular language, no matter how stupid the reason, they are probably going to produce more. It's just not a technological solution though.
Good luck, :)

I am pretty sure (100%) that you don't need to use Python for MS Windows at least.
In cases of other platforms you can use any language you like.

If it is decided that our system needs an overhaul, what is the best way to go about it?

We are mainting a web application that is built on Classic ASP using VBScript as the primary language. We are in agreement that our backend (framework if you will) is out dated and doesn't provide us with the proper tools to move forward in a quick manner. We have pretty much embraced the current webMVC pattern that is all over the place, and cannot do it, in a reasonable manner, with the current technology. The big missing features are proper dispatching and templating with inheritance, amongst others.
Currently there are two paths being discussed:
Port the existing application to Classic ASP using JScript, which will allow us to hopefully go from there to .NET MSJscript without too much trouble, and eventually end up on the .NET platform (preferably the MVC stuff will be done by then, ASP.NET isn't much better than were we are on now, in our opinions). This has been argued as the safer path with less risk than the next option, albeit it might take slightly longer.
Completely rewrite the application using some other technology, right now the leader of the pack is Python WSGI with a custom framework, ORM, and a good templating solution. There is wiggle room here for even django and other pre-built solutions. This method would hopefully be the quickest solution, as we would probably run a beta beside the actual product, but it does have the potential for a big waste of time if we can't/don't get it right.
This does not mean that our logic is gone, as what we have built over the years is fairly stable, as noted just difficult to deal with. It is built on SQL Server 2005 with heavy use of stored procedures and published on IIS 6, just for a little more background.
Now, the question. Has anyone taken either of the two paths above? If so, was it successful, how could it have been better, etc. We aren't looking to deviate much from doing one of those two things, but some suggestions or other solutions would potentially be helpful.

Don't throw away your code!
It's the single worst mistake you can make (on a large codebase). See Things You Should Never Do, Part 1.
You've invested a lot of effort into that old code and worked out many bugs. Throwing it away is a classic developer mistake (and one I've done many times). It makes you feel "better", like a spring cleaning. But you don't need to buy a new apartment and all new furniture to outfit your house. You can work on one room at a time... and maybe some things just need a new paintjob. Hence, this is where refactoring comes in.
For new functionality in your app, write it in C# and call it from your classic ASP. You'll be forced to be modular when you rewrite this new code. When you have time, refactor parts of your old code into C# as well, and work out the bugs as you go. Eventually, you'll have replaced your app with all new code.
You could also write your own compiler. We wrote one for our classic ASP app a long time ago to allow us to output PHP. It's called Wasabi and I think it's the reason Jeff Atwood thought Joel Spolsky went off his rocker. Actually, maybe we should just ship it, and then you could use that.
It allowed us to switch our entire codebase to .NET for the next release while only rewriting a very small portion of our source. It also caused a bunch of people to call us crazy, but writing a compiler is not that complicated, and it gave us a lot of flexibility.
Also, if this is an internal only app, just leave it. Don't rewrite it - you are the only customer and if the requirement is you need to run it as classic asp, you can meet that requirement.

Use this as an opportunity to remove unused features! Definitely go with the new language. Call it 2.0. It will be a lot less work to rebuild the 80% of it that you really need.
Start by wiping your brain clean of the whole application. Sit down with a list of its overall goals, then decide which features are needed based on which ones are used. Then redesign it with those features in mind, and build.
(I love to delete code.)

It works out better than you'd believe.
Recently I did a large reverse-engineering job on a hideous old collection of C code. Function by function I reallocated the features that were still relevant into classes, wrote unit tests for the classes, and built up what looked like a replacement application. It had some of the original "logic flow" through the classes, and some classes were poorly designed [Mostly this was because of a subset of the global variables that was too hard to tease apart.]
It passed unit tests at the class level and at the overall application level. The legacy source was mostly used as a kind of "specification in C" to ferret out the really obscure business rules.
Last year, I wrote a project plan for replacing 30-year old COBOL. The customer was leaning toward Java. I prototyped the revised data model in Python using Django as part of the planning effort. I could demo the core transactions before I was done planning.
Note: It was quicker to build a the model and admin interface in Django than to plan the project as a whole.
Because of the "we need to use Java" mentality, the resulting project will be larger and more expensive than finishing the Django demo. With no real value to balance that cost.
Also, I did the same basic "prototype in Django" for a VB desktop application that needed to become a web application. I built the model in Django, loaded legacy data, and was up and running in a few weeks. I used that working prototype to specify the rest of the conversion effort.
Note: I had a working Django implementation (model and admin pages only) that I used to plan the rest of the effort.
The best part about doing this kind of prototyping in Django is that you can mess around with the model, unit tests and admin pages until you get it right. Once the model's right, you can spend the rest of your time fiddling around with the user interface until everyone's happy.

Whatever you do, see if you can manage to follow a plan where you do not have to port the application all in one big bang. It is tempting to throw it all away and start from scratch, but if you can manage to do it gradually the mistakes you do will not cost so much and cause so much panic.

Half a year ago I took over a large web application (fortunately already in Python) which had some major architectural deficiencies (templates and code mixed, code duplication, you name it...).
My plan is to eventually have the system respond to WSGI, but I am not there yet. I found the best way to do it, is in small steps. Over the last 6 month, code reuse has gone up and progress has accelerated.
General principles which have worked for me:
Throw away code which is not used or commented out
Throw away all comments which are not useful
Define a layer hierarchy (models, business logic, view/controller logic, display logic, etc.) of your application. This has not to be very clear cut architecture but rather should help you think about the various parts of your application and help you better categorize your code.
If something grossly violates this hierarchy, change the offending code. Move the code around, recode it at another place, etc. At the same time adjust the rest of your application to use this code instead of the old one. Throw the old one away if not used anymore.
Keep you APIs simple!
Progress can be painstakingly slow, but should be worth it.

I would not recommend JScript as that is definitely the road less traveled.
ASP.NET MVC is rapidly maturing, and I think that you could begin a migration to it, simultaneously ramping up on the ASP.NET MVC framework as its finalization comes through.
Another option would be to use something like ASP.NET w/Subsonic or NHibernate.

Don't try and go 2.0 ( more features then currently exists or scheduled) instead build your new platform with the intent of resolving the current issues with the code base (maintainability/speed/wtf) and go from there.

A good place to begin if you're considering the move to Python is to rewrite your administrator interface in Django. This will help you get some of the kinks worked out in terms of getting Python up and running with IIS (or to migrate it to Apache). Speaking of which, I recommend isapi-wsgi. It's by far the easiest way to get up and running with IIS.

I agree with Michael Pryor and Joel that it's almost always a better idea to continue evolving your existing code base rather than re-writing from scratch. There are typically opportunities to just re-write or re-factor certain components for performance or flexibility.