«

On Wed, 2003-07-09 at 15:17, A.M. Kuchling wrote:
> On 09 Jul 2003 12:34:46 -0500,
> Ian Bicking <> wrote:
> > One of the big problems I also had was installation. Many of the
> > frameworks require non-trivial Apache configuration, which hinders
> > experimentation. Actually solving this is significant work, though --
> > but also something which very much deserves solving.
>
> Why? The purpose is to let users compare the structure of applications, not
> benchmarking. I envision users browsing the code for each framework, never
> running anything until they've selected a framework and begun implementing
> an application. Solving web server configuration problems is out of scope.

Evaluation of course only starts with reading, of course you are also
going to want to experiment directly with the system.

But more generally, I can't stand writing about how to work around
problems, when (as a programmer) it is within my power to fix those
problems. It seems far better to spend time fixing problems than merely
documenting them.

The thing is, for many of the developers of these frameworks, the payoff
for improving installation isn't that big, because they wrote this for
themselves and they only have a handful of installations to do. But
installation becomes a much bigger deal when considering larger
adoption, and I think installation is a major hindrance to Python's
adoption as a web programming language -- a combination off difficult
installation, and a lack of robustness and generality in installation
methods.

Ian

On 09 Jul 2003, Ian Bicking <> wrote:

> I think installation is a major hindrance to Python's
> adoption as a web programming language -- a combination off difficult
> installation, and a lack of robustness and generality in installation
> methods.

Since PHP is widely adopted as a web programming language, I assume
you think PHP's installation methods are robusts and general?
Let me assure you, having done PHP configuration in Apache, it
is far from it -- in fact, it is buggy and annoying beyond all
measure. [I was *shocked* to discover, for example, I can't associate
all .html files in a directory with PHP. I am sure it is a great
visibility booster for PHP to have pages end with .php, but I didn't
care much for it.]

I actually think that in a world where people think PHP installation
methods are sane, Python's barrier to entry (in that regard) is fairly
low.
--
Moshe Zadka -- http://moshez.org/
Buffy: I don't like you hanging out with someone that... short.
Riley: Yeah, a lot of young people nowadays are experimenting with shortness.
Agile Programming Language -- http://www.python.org/

On Wed, 2003-07-09 at 21:14, Moshe Zadka wrote:
> On 09 Jul 2003, Ian Bicking <> wrote:
>
> > I think installation is a major hindrance to Python's
> > adoption as a web programming language -- a combination off difficult
> > installation, and a lack of robustness and generality in installation
> > methods.
>
> Since PHP is widely adopted as a web programming language, I assume
> you think PHP's installation methods are robusts and general?
> Let me assure you, having done PHP configuration in Apache, it
> is far from it -- in fact, it is buggy and annoying beyond all
> measure. [I was *shocked* to discover, for example, I can't associate
> all .html files in a directory with PHP. I am sure it is a great
> visibility booster for PHP to have pages end with .php, but I didn't
> care much for it.]

PHP's installation is difficult, but fairly robust. The result is a
system where pages can be added easily, multiple users can coexist,
server health is generally maintained, and administrator overhead
*after* installation is pretty good. For a large set of applications,
you don't have to interact with the administrator during installation or
development of your application. Interacting with system administrators
usually does not make developers happy, so that's a big plus.

PHP certainly sucks in a whole bunch of ways, installation included, but
it gives administrators what they want (simplicity and delegation), and
gives users what they want (an available environment with a relatively
decent learning/usage curve).

Ian

Moshe Zadka <> schreef:

> [I was *shocked* to discover, for example, I can't associate
> all .html files in a directory with PHP. I am sure it is a great
> visibility booster for PHP to have pages end with .php, but I didn't
> care much for it.]

I have no problems doing that with Apache?

Just create a .htaccess (or whatever it is on your system) in that
directory and put the following line in it:

AddType application/x-httpd-php .html

Also make sure httpd.conf allows you to define types in a .htaccess file.
If you want, you can set the "local AddType" in httpd.conf too, I think.


(Tested with Apache 1.3.27 + PHP 4.3.0 on my Win98 desktop)

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

Ganesan R wrote:

>>>>>>"Max" == Max M <> writes:
>
>>>Python web development is fragmented.
>
>>Ahem ... How os Python web development fragmented? Most of it probably
>>takes place in the Zope world.
>
>
> How about the fact if you want something simpler than Zope you cannot point
> to a single framework and say use this one?


That's right. But without a framework, you are about on par with PHP.
Only with a better language and better libraries.


regards Max M

Afanasiy <> wrote in message news:<>. ..
>
> It would be nice to have a Python equivalent. Unfortunately, for now I
> need to just get started on some things myself rather than convince a
> bunch of other people to do the same. I suppose this could be the best
> way to show so many of the factors I've been listing for months which
> are apparently invisible. I'm sure people agree with me, but they do
> not participate in Usenet, and are very busy being important.

Important or not, the reason for your problems not being addressed is
clearly that most associated with certain open source development
processes: if the developers don't have the same needs as you have,
and if they don't have any incentive to meet those needs, then they
won't do the work if they have other things to be getting on with. I
seem to remember that you wanted support for per-user isolation within
Apache, for example, and I can only imagine that those people
developing Web frameworks just don't have the same hosting limitations
as you have; therefore, the need remains unsatisfied.

> I can also imagine any sort of attempt at comparison, like a benchmark,
> or the infamous language shootout, would be absolutely ridiculed.

You mean like the "Web Framework Shootout"?

http://colorstudy.com/docs/shootout.html

Or do you share the views of certain other people on this?

http://twistedmatrix.com/users/radix.../msg00000.html

(Some interesting views on Woven, but a lot of seemingly
elitist framework bashing, too.)

> I personally consider them fairly useful, but most do not and I am
> wary of spending so much time on something which would eventually, or
> perhaps not so eventually, devolve into personal attacks.

There are and were lots of different comparison charts, documents and
resources. Perhaps you could use those as a starting point - I know I
wouldn't mind if you adapted my old documents on the subject, and I
can imagine that people would welcome contributions to the PythonInfo
Wiki as well.

Paul

Max M <> writes:
> Ahem ... How os Python web development fragmented? Most of it probably
> takes place in the Zope world.

Nonsense, look at all the Python web platforms there are that don't use Zope.

> But mod_python is an official Apache module. Wich sets it about on par
> with PHP.

Nonsense, it's not on a par with PHP. It doesn't include any template
system, any sessions, etc.


> It has a standard library that beats the socks of PHP's builtin functions.

Nonsense, it doesn't include any SQL database interfaces and you're
left on your own to find one, install it, and get it working.

> On top on this there are severeal modules for templating etc. PHP does
> not have these modules, so everybody has to do it in PHP's own faulty
> way.

Nonsense, you're trying to spin a deficiency as an advantage. PHP is
its own template system, for better or worse. Python doesn't include
any template system and you're left on your own to find or write one,
install it, and get it working.

> Python is not fragmented, but there are more high level modules for
> doing things.

Nonsense, of course Python (for web development) is fragemented, look
at all these different Python web modules we've been discussing.
Python does have a lot of modules (like Numeric) that PHP doesn't, but
they're not that useful for web programming. PHP is narrowly focused
on web programming and is far superior to Python for that purpose
unless you spend a lot of time enhancing Python with add-ons before
you even start writing your applications.

> There are more PHP developers, that's right, but they are all starting
> from scratch, with a poor language. So it's their loss.

Nonsense, Python is a better language than PHP, but that's the only
advantage Python has for web development. The language is a small
part of the overall system. And it's Python developers who must start
from scratch, not PHP developers. Python could catch up by adding
more stuff to the standard library, but it hasn't done that yet and
most of the suitable Python modules for PHP-like usage aren't really
ready for prime time.

On Thu, 2003-07-10 at 10:01, A.M. Kuchling wrote:
> On 09 Jul 2003 20:53:17 -0500,
> Ian Bicking <> wrote:
> > But more generally, I can't stand writing about how to work around
> > problems, when (as a programmer) it is within my power to fix those
> > problems. It seems far better to spend time fixing problems than merely
> > documenting them.
>
> I don't believe it's possible to fix the installation problems. Quixote
> works with Apache, IIS, AOLserver, Medusa, and Twisted; there seems nothing
> that can be done to simplify things across that entire range.

Well, it wasn't Quixote I was talking about. It was more things like
jonpy (with wt templates, specifically), or Spyce, and in general the
frameworks that were more closely tied to Apache, and to non-standard
configuration (Albatross, in contrast, uses plain CGI scripts, so
configuration was easy).

So of course installation can be improved. Quixote works with all those
environments, Webware should do it exactly the same, JOTWeb should do it
the same, etc. Some of these systems are (close to) as flexible as
Quixote for deployment, most aren't anywhere close. Also, the work that
goes into installing one system is usually not helpful when installing
another. Not only should all the frameworks be similarly flexible, but
they should *do it in the same way*.

> It can be made easier in one particular case, of course. For example,
> setting up an SCGI application with Apache requires three steps:
>
> 1) Compile mod_scgi and install it. (On Debian unstable,
> you can install it with apt-get.
> 2) Add a directive to httpd.conf and restart:
> <Location "/appurl">
> SCGIServer 127.0.0.1 6500
> SCGIHandler On
> </Location>
> 3) Run the SCGI application so that it listens to port 6500.

mod_skunkweb, for instance, has a few more features than mod_scgi or
mod_webkit for failure conditions (if the backend application
disappears), though both have more than mod_scgi, and mod_webkit has
something for handling files by extension as well.

These features do make it a little more complicated, but they solve
particular problems, and reducing duplication would help us all. All
three protocols (mod_scgi, mod_skunkweb, and mod_webkit) do almost
exactly the same thing. And then there's FastCGI...

> The Dulcinea package (http://www.mems-exchange.org/software/dulcinea/)
> includes scripts for running multiple web sites on a machine and easily
> configuring them, but that's a feature that isn't being pushed very
> strongly, and we made little effort to make this feature usable by
> outsiders.

Which portions are you referring to? None of the modules you describe
in the overview seem to apply.

Ian

In article <mailman.1057862838.7508.python->, Ian Bicking wrote:
> Well, it wasn't Quixote I was talking about. It was more things like
> jonpy (with wt templates, specifically)

Well, the way 'wt' works requires you to put 2 lines of mod_rewrite
rules in your .htaccess or httpd.conf, there's no getting around that.
I don't see it as a big hardship though. It's kind've fundamental to
they way 'wt' templates work and 2 lines of work in advance means a
lot of work saving later on.

If you don't like the 'wt' templates then just use the rest of jonpy
without them...

On Thu, 2003-07-10 at 18:33, Jon Ribbens wrote:
> In article <mailman.1057862838.7508.python->, Ian Bicking wrote:
> > Well, it wasn't Quixote I was talking about. It was more things like
> > jonpy (with wt templates, specifically)
>
> Well, the way 'wt' works requires you to put 2 lines of mod_rewrite
> rules in your .htaccess or httpd.conf, there's no getting around that.
> I don't see it as a big hardship though. It's kind've fundamental to
> they way 'wt' templates work and 2 lines of work in advance means a
> lot of work saving later on.

FWIW, I spent a lot of time trying to get those two lines to work,
ultimately failing (it was a while ago, so I'm afraid I can't expand).
It's entirely possible I was trying too hard and making it more
complicated than it was... but configuring Apache in general is a pain,
because diagnostics for that sort of configuration are largely
nonexistent, you simply get incorrect behavior. Or maybe I got Apache
right, but the file layout wrong. Whichever.

My problems with FastCGI have been largely the same. It shouldn't be
complicated, but somehow manages to be so anyway. The multitudes of
FastCGI-reimplementors can't all be wrong, can they?

Always-reluctantly-a-sysadmin'ly y'rs,
Ian