Python for data driven website?

On Fri, 2002-07-12 at 01:42, Micah Mayo wrote:
> Definatly reliabilty/scalability. We expect anywhere from 100-1000> customers, which may or may not translate into multiple users per account.

This isn't a huge number (if you don't mean concurrent users).  I
imagine that the accounts are going to be fairly lucrative, which is to
say, if you have 1000 users you'll be able to afford a big beefy box --
and until then, you can probably get by with a smaller, cheaper box. 
This usage is within the performance capabilities of most things you'll
look at (at least on Unix).  I wouldn't put performance first --
reliability is probably much more important.  If, for instance, you were
running a public website with income from advertising, you'd have to be
more concerned about performance, because high usage wouldn't
necessarily mean high income.

> Whatever we use need to be able to handle a gradual, or steep for that> matter, rise in use. I didn't mean to sound as if we were just looking for> cool technology. We have three person team. One older developer who has> years of experience with database programming, and two younger> intermediates. Me being one of the younger guys. The older guy is teaching> us the industry. The problem is almost all of his experience is with> microsoft products. When he decided that microsoft was not able to provide> an affordable solution, he started talking to us about a free/unix solution.> Of the three of us I am the only one with any real experience with unix(when> i was a luser teenager I thought I was cool because I ran FreeBSD as my> desktop), so I am the only one who is really comfortable in this area. So, I> get stuck with alot of research work of this sort. So, as far as the> application goes - the software is going to be a service for tax firms> available through the web only(unless a custom version is needed, which> would cost a pretty penny).  

If you want to plan for a non-web version (which would probably be
appealing if there's a lot of data entry -- as I imagine there would be
with a tax application), then you should consider that from the start. 
I would suggest building a strong, interface-neutral backend of objects
and interfaces.  You can then add a web interface, or a GUI interface,
as you want it.  Even if you only have a web interface, it's still a
good design practice.

This is one place where Python is considerably better than PHP or ASP --
it's a real, general-purpose language (and runs well on Windows).  Of
course, with ASP you'd want a COM interface to the backend, and with
PHP... well, I don't know what you'd do.  Perl is closer to Python than
to PHP or ASP.  But you'll have to decide on that yourself -- I can't
say much of anything good about Perl (except library support), and you
won't find many supporters in this forum.

I imagine you'll want some sort of framework -- even if you use CGI,
you'll just end up making your own ad hoc framework (which isn't
horrible, but you should expect you'll be doing that).  Configuration
won't be a big deal if you are planing on running just a single instance
of the program (on a central server) -- so I wouldn't worry about
commercial hosting support (where Python is bad and PHP is very good).


One problem you will have is that there really isn't a conventional way
to do something like this in Python.  In PHP or ASP, you won't be going
out on a limb, you probably won't be doing anything that lots of people
haven't done before -- the specifics of your application will be
different, but all the parts will be things lots of people have done. 
Oddly enough, that doesn't mean that these repeated actions have been
well factored so that they are trivial in these languages -- I am
particularly unimpressed with the modularity and number of high-level
abstractions in PHP.  Everything about PHP seems very expedient -- which
is good and bad.

If you do use Python, there are a number of distinct options for what
framework you'll use.  I wouldn't recommend Zope, because if you aren't
doing content management then it seems like a very bad fit -- there's a
lot of conceptual overhead that isn't going to help you.  You'll want to
make a frontend right away -- that way you can see the product of your
work, even if you end up throwing that frontend away.  But I'd strongly
advise you to spend a lot of time thinking about the objects that will
represent your backend.  If a framework demands that you buy-in
wholeheartedly, then I don't think you should use it (which is another
reason I don't think you should use Zope).

--
Ian Bicking           Colorstudy Web Development
ianb at colorstudy.com   http://www.colorstudy.com
4869 N Talman Ave, Chicago, IL 60625 / (773) 275-7241