website python engine (slashdot)

Daniel Green daniel.green at ncf.ca
Wed Aug 9 11:48:45 EDT 2000


If it makes you feel any better, I wrote Fenster for actual real work
purposes. I intend to actually use it. :) On the other hand, it is true that
it was stupid easy to write. I must confess, I would have thought twice
about it had I seen these links beforehand. Maybe the problem is simply one
of awareness. I began writing Fenster because the only other similar
application I had seen was PSP for JPython.

The company I am working with was looking at some pretty heavy duty stuff
(WebObjects, WebSphere, etc) but decided that a) we all hated Java too much
to have to use it and b) loved Python.

But now I almost feel bad for releasing it. :)

I also thought it'd be nice for the Windows NT folks doing Python stuff
under ASP/IIS to have somewhere to port to. I would be more than happy to
work with as many folks as possible, wether just advice/discussion or actual
code, but will probably continue to develop it even if it does remain a
one-man-show.

As for the big question, I'm not sure it can boil down to one question. It's
difficult at best to be all things to all people. But I do see your points.
:)

> Sam Penrose wrote:
> >
> > Everyone and their grandmother seems to be working on a slightly
> > different Python web application/publishing environment. A few
> > observations:
> >
> > 1) It isn't hard. Heck, even I'm doing it.
>
> Yes, it's a great spare time project. ;-)
>
> > 2) Except for Zope, most of these projects seem to be one-man
> > operations, despite the fact that the projects are mostly open source
> > and the authors trying to recruit help.
>
> I would agree, and this is why a few like-minded individuals got together
on the
> "python-web-modules" e-group:
>
>   http://www.egroups.com/group/python-web-modules
>
> Although some collaboration has taken place, many people have come forward
with
> modules of their own. This is related to your fourth point.
>
> > 3) The first two points together suggest that Python (with the standard
> > library included) is all the common code base anyone needs.
>
> I would tend to disagree with that. Whilst it might be possible that
people
> could get by with writing Web frameworks using just the 'cgi' and 'Cookie'
> modules, for example, many people would benefit from higher level modules.
I do
> accept that different people have different requirements from their Web
> frameworks, and this does tend to cut down the amount of common code; for
> example, some people like programs embedded in HTML pages, others prefer
> template systems, and others prefer programmatically generated HTML.
>
> However, the kind of higher level modules which would benefit framework
> architects depends on the background and point of view of those architects
and
> how they believe they could be helped to write better frameworks more
quickly
> and effectively. There is some consensus on "CGI wrapper" programs, but
how they
> interact with application programs is not something everyone agrees on.
>
> > 4) It also suggests that a year from now something very different will
> > be going on. If all of us feel the need to work on this but none of us
> > is quite satisfied with what anyone else is doing, it suggests that none
> > of us is coming up with a very good answer. Since most of us are pretty
> > smart (present writer excepted), that in turn suggests that we aren't
> > going to get an answer until we reformulate the question. What are we
> > missing here, folks? I have a hunch we're all going to be wishing we'd
> > thought of it whenever it finally arrives...
>
> I would say that what we are missing is a way of making Web applications
which:
>
>   * Is easy to buy into, well documented, "unsurprising".
>
>   * Allows easy deployment for simple solutions. Permits more complicated
>     deployment if that is necessary for performance, high-availability and
so
>     on.
>
>   * Scales up to provide support for complicated interactions. (We don't
really
>     need another way of writing "one shot" HTML form handlers.)
>
>   * Helps us manage the presentation and its dependency on the data
structures
>     being manipulated by application code.
>
>   * Gives obvious solutions for issues like internationalisation and
>     localisation, and many other commonly occuring issues. It isn't enough
that
>     a framework supports these things if only one can figure out how it is
done
>     - these things require clear documentation.
>
> I am sure that I could think of many other requirements, but for me these
are
> already useful for assessing the projects out there today. My own spare
time
> effort advanced to the point of being a bit too difficult to buy into, but
you
> can find information about it, with links to some of the other projects,
here:
>
>   http://www.crosswinds.net/~pboddie/
>
> Regards,
>
> Paul
> --
> http://www.python.org/mailman/listinfo/python-list





More information about the Python-list mailing list