By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,640 Members | 1,581 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,640 IT Pros & Developers. It's quick & easy.

Python vs PHP

P: n/a
Can Python replace PHP?
Can I use a python program to make an interface to a mysql 4.X database?
If that's possible where can I find a tutorial?
Jul 18 '05 #1
Share this Question
Share on Google+
29 Replies


P: n/a
Hi !

PHP-5 let down MySql, for Sql-Lite (rumor ?)

Python has good support for MySql AND Sql-Lite.

@+

Michel Claveau
Jul 18 '05 #2

P: n/a
In article <ma*********************************@python.org> ,
Catalin <ad****@ploiesti.astral.ro> wrote:

Can Python replace PHP?
Can I use a python program to make an interface to a mysql 4.X database?


The short answer is "yes" to both questions, but with a caveat: Python is
a general-purpose programming language, where PHP is designed to write
web applications. So it's not quite as simple/straightforward to use
Python the same way you use PHP for plain web pages; conversely, if
you've been running into difficulty with PHP in trying to write
complicated program logic, you'll find Python a big help.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"Not everything in life has a clue in front of it...." --JMS
Jul 18 '05 #3

P: n/a
News M Claveau /Hamster-P wrote:
Hi !

PHP-5 let down MySql, for Sql-Lite (rumor ?)


PHP 5 won't come bundled with a default MySql lib, but anyone is still
free to link against the official MySQL lib, one way or another...

And yes, the default 'bundled-in' SQL lib should be Sql-lite.

Bruno

Jul 18 '05 #4

P: n/a
On Mon, 07 Jul 2003 13:47:00 +0300, Catalin
<ad****@ploiesti.astral.ro> wrote:
Can Python replace PHP?
Sure. Look at http://spyce.sourceforge.net
Can I use a python program to make an interface to a mysql 4.X database?
Of course, you can. http://www.python.org/sigs/db-sig/
E.g. http://dustman.net/andy/python/MySQLdb_obsolete
If that's possible where can I find a tutorial?

http://www.python.org/doc/Newbies.html
http://www.python.org/doc/current/
http://www.python.org/cgi-bin/faqw.py

--
JZ
Jul 18 '05 #5

P: n/a
On Tue, Jul 08, 2003 at 11:14:10AM +0200, Jaroslaw Zabiello wrote:
On Mon, 07 Jul 2003 13:47:00 +0300, Catalin
<ad****@ploiesti.astral.ro> wrote:
Can Python replace PHP?


Sure. Look at http://spyce.sourceforge.net


Lest the OP think Spyce is the only or even the preferred solution for web
programming with Python:

http://cherrypy.org/

http://www.twistedmatrix.com/

http://skunkweb.sf.net

http://webware.sf.net

http://zope.org

http://www.mems-exchange.org/software/quixote/

http://www.object-craft.com.au/projects/albatross

http://jonpy.sf.net

http://jotweb.tummy.com/

And let's not forget plain old CGI and mod_python.

Jp

--
"There is no reason for any individual to have a computer in their
home."
-- Ken Olson, President of DEC, World Future Society
Convention, 1977

Jul 18 '05 #6

P: n/a
On Mon, 07 Jul 2003 13:47:00 +0300, Catalin <ad****@ploiesti.astral.ro>
wrote:
Can Python replace PHP?
Can I use a python program to make an interface to a mysql 4.X database?
If that's possible where can I find a tutorial?


I recommend Spyce, Webware, or Quixote depending on your requirements,
but Draco, SkunkWeb, RoadKill are worth looking into as well. Spyce is
really the best (for PHP-ness) in my opinion, after you actually get past
the fact that it supports your old fashioned notion of what embedded
delimiters should look like, as well as a new CTS-friendly alternative.

Spyce is the closest thing to PHP, but also provides some features PHP
does not. However, I think you will find some people, like myself, who are
still unable to make the switch from PHP to Python for web development,
because of a lot of little things. These people know Python is better and
may even know their non-web PHP applications are hell compared to their
Python re-implementations. However, they still use PHP for web development
and feel they have to. They may have even written out all the requirements
and received vague responses to them.

Python web development is fragmented. Mod_python CVS now contains the work
of what used to be mod_psp by Sterling Hughes, a PHP warlord, I'm sure
he'll reply. This possibly soon to be official 'PSP' is not much in my
opinion and should probably not be folded into mod_python. Others agree:

http://www.modpython.org/pipermail/m...ne/003200.html

Another big problem with Python web development is the lack of good shared
hosting support. Primarily the lack of anything resembling PHP's safe
mode. Mod_python has no equivalent of this safe mode, but Apache 2's
'Perchild MPM' is supposed deprecates this need. However, this still
requires an httpd.conf edit and a restart of Apache for every user added,
very annoying, especially to a shared hosting service.

http://apache.slashdot.org/apache/02...206.shtml?tid=
http://httpd.apache.org/docs-2.0/mod/perchild.html
http://www.modpython.org/pipermail/m...er/001705.html

A couple other slight issues :

* catch-all error handling not as flexible or non-existent
* no equivalent to php_value auto_prepend_file "_header.php"
* no equivalent to php_value auto_append_file "_footer.php"
* not as intelligent form value handling
* white space sensitivity is a unique problem when embedding

The best options for me are currently :

* use PHP
* use Spyce
* fork Spyce (creating more fragmentation)
* embed python straight into my favorite platform (quite funny)
* write my own mod_python-based platform (more fragmentation)
* find the holy grail (i must have missed it)

I've been handling this dilemma for months. I've even benchmarked quite a
few possible solutions, with pleasing results in those which I thought
were well done, and pleasing results for Python over PHP in general.

-AB
Jul 18 '05 #7

P: n/a
In article <km********************************@4ax.com>, Afanasiy wrote:
A couple other slight issues :

* catch-all error handling not as flexible or non-existent
* no equivalent to php_value auto_prepend_file "_header.php"
* no equivalent to php_value auto_append_file "_footer.php"
* not as intelligent form value handling
* white space sensitivity is a unique problem when embedding


Try jonpy (http://jonpy.sf.net/), it solves all of the above.
Also you may find FastCGI (which jonpy supports) helps with your
"safe mode" problem, although it might require a bit of hackery.
Jul 18 '05 #8

P: n/a
On Tue, 08 Jul 2003 15:56:58 GMT, Afanasiy <ab********@hotmail.com> wrote:
On Mon, 07 Jul 2003 13:47:00 +0300, Catalin <ad****@ploiesti.astral.ro>
wrote: A couple other slight issues :

* catch-all error handling not as flexible or non-existent
* no equivalent to php_value auto_prepend_file "_header.php"
* no equivalent to php_value auto_append_file "_footer.php"
* not as intelligent form value handling
* white space sensitivity is a unique problem when embedding


I think I should add import, pythonpath and module caching to this list.
These are much more annoying than PHP's inclusion mechanisms. I am even
annoyed in non-web applications by them quite often, but not necessarily
all at the same time.

Also add to the list, the need for PyChecker. You must run PyChecker
to discover errors which would occur on a section of logic being hit
which contained a silly typographical error. PHP would discover these
without them being hit, when you were developing the page.

Python is more beautiful and more powerful, but for this purpose I
consider the current implementations still lacking compared to PHP.
So much so that I am unable to bring myself to write new PHP, but
unable to continue using Python until I find the perfect implementation.

-AB
Jul 18 '05 #9

P: n/a
On 8 Jul 2003 16:02:48 GMT, Jon Ribbens <jo********@unequivocal.co.uk>
wrote:
In article <km********************************@4ax.com>, Afanasiy wrote:
A couple other slight issues :

* catch-all error handling not as flexible or non-existent
* no equivalent to php_value auto_prepend_file "_header.php"
* no equivalent to php_value auto_append_file "_footer.php"
* not as intelligent form value handling
* white space sensitivity is a unique problem when embedding


Try jonpy (http://jonpy.sf.net/), it solves all of the above.
Also you may find FastCGI (which jonpy supports) helps with your
"safe mode" problem, although it might require a bit of hackery.


No, CGI is not an option and I tried jonpy. I kept my notes about it...
Jul 18 '05 #10

P: n/a
In article <mo********************************@4ax.com>, Afanasiy wrote:
CGI, FastCGI, SCGI are not faster than mod_python in my experience and
straightforward benchmark.
In the case of CGI, yes of course. In the case of FastCGI, your
experience contradicts my own.
That's all I can really say about it. CGI is not an option for me.


I don't understand why you keep saying "CGI is not an option" when
nobody has suggested that you use it.
Jul 18 '05 #11

P: n/a
On 8 Jul 2003 17:59:12 GMT, Jon Ribbens <jo********@unequivocal.co.uk>
wrote:

I don't understand why you keep saying "CGI is not an option" when
nobody has suggested that you use it.


Ok
Jul 18 '05 #12

P: n/a
On 8 Jul 2003 17:59:12 GMT,
Jon Ribbens <jo********@unequivocal.co.uk> wrote:
I don't understand why you keep saying "CGI is not an option" when
nobody has suggested that you use it.


Jon, there's no point in debating Afanasiy about CGI. He's convinced
packages for Python web programming support are inadequate (*all* of them),
is unable to explain what the problem is or what his requirements are, and
doesn't seem to really understand the subject (e.g. thinking FastCGI is
basically the same as regular CGI). Ignoring him is the best course.

--amk

Jul 18 '05 #13

P: n/a
On Tue, 08 Jul 2003 20:46:53 -0500, "A.M. Kuchling" <am*@amk.ca> wrote:
On 8 Jul 2003 17:59:12 GMT,
Jon Ribbens <jo********@unequivocal.co.uk> wrote:
I don't understand why you keep saying "CGI is not an option" when
nobody has suggested that you use it.


Jon, there's no point in debating Afanasiy about CGI. He's convinced
packages for Python web programming support are inadequate (*all* of them),
is unable to explain what the problem is or what his requirements are, and
doesn't seem to really understand the subject (e.g. thinking FastCGI is
basically the same as regular CGI). Ignoring him is the best course.


Read.

Jul 18 '05 #14

P: n/a
In article <K6********************@speakeasy.net>, A.M. Kuchling wrote:
Jon, there's no point in debating Afanasiy about CGI. He's convinced
packages for Python web programming support are inadequate (*all* of them),
is unable to explain what the problem is or what his requirements are, and
doesn't seem to really understand the subject (e.g. thinking FastCGI is
basically the same as regular CGI). Ignoring him is the best course.


Oh, ok, ta ;-)
Jul 18 '05 #15

P: n/a
A.M. Kuchling wrote:
At PyCon, it was generally agreed at the Web programming BoF that the
authors of the various Python frameworks should all implement the same
example application so that potential users can compare the resulting
code. Nothing much has been done on this front since then; we should
get things moving again by figuring out what the example application
should be. The Java Pet Store was suggested, but it was pointed out
that it's a very large application, requiring too much effort for an
author to do in their spare time.
Ian Bicking did something like this with
http://colorstudy.com/docs/shootout.html with a Wiki as the example
application. If there is interest, I would volunteer to copy this into the
Wiki so that it can be more easily extended. I already got Ian's
permissionto do so, but was so far too lazy for it.
Let's think about the requirements for an example application:

* Should be implementable in a few evenings
* Should exercise a reasonable set of features.
* HTML generation (duh!)
* Accepting a form
* Returning non-HTML files (generating a GIF, say)
* Sessions


* access control
I suggest using
http://www.python.org/cgi-bin/moinmo...ammingShootOut as the entry
point for the specification of the application.

Daniel

Jul 18 '05 #16

P: n/a
On Wed, 2003-07-09 at 10:26, Daniel Dittmar wrote:
Ian Bicking did something like this with
http://colorstudy.com/docs/shootout.html with a Wiki as the example
application. If there is interest, I would volunteer to copy this into the
Wiki so that it can be more easily extended. I already got Ian's
permissionto do so, but was so far too lazy for it.


It might be preferable to do this in CVS somewhere -- it would handle
the source files better, and most of the commentary can go in comments.

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.

A SourceForge (or equivalent) project might be a good place to start.

Ian

Jul 18 '05 #17

P: n/a
"A.M. Kuchling" <am*@amk.ca> wrote in message news:
The Java Pet Store was suggested, but it was pointed out that it's a very
large application, requiring too much effort for an author to do in their
spare time.
But you can see the difference only in larger application. Not
everything scales good when programming in the large is necessary. I
never found that simple benchmarks really helps.

I think I like the store best, because the first three applications are
all text-oriented, and the content manager doesn't do much beyond spitting back


Yes, me too. It should be something that is usefull for comparison in
larger commercial applications. And it should have test generators to
check the system under heavy system load.
Jul 18 '05 #18

P: n/a
In article <VL********************@speakeasy.net>,
A.M. Kuchling <am*@amk.ca> wrote:

That reminds me: there was also a proposal to revive the Web-SIG. Ian,
anything moving on this front? (My offer to host a list still stands.)


I'd suggest putting it on python.org, so that anyone who who looks at
the mailing lists will find it.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"Not everything in life has a clue in front of it...." --JMS
Jul 18 '05 #19

P: n/a
"A.M. Kuchling" <am*@amk.ca> writes:
The Java Pet Store was suggested, but it was pointed out that it's a very
large application, requiring too much effort for an author to do in their
spare time.
Heh, the point of doing it in Python is it should take much less time
than doing it in Java :).
* Should be implementable in a few evenings
Good
* Should exercise a reasonable set of features.
* HTML generation (duh!)
* Accepting a form
Accepting a very long form (i.e. megabytes of POST data)
* Returning non-HTML files (generating a GIF, say)
* Sessions
* Uploading a file
* RDBMS access? (That's more a function of the DB-API module you're
using, but a framework might provide support for pooling
connections or something similar.)
Yes, this should be included, lack of a standard DB API module is a
serious Python deficiency and any DB-using app needs to work around
the deficiency somehow.
* Other suggestions?

Possibilities:
* A Wiki?
* A multiple-user weblog?
* A Slashdot-like discussion board?
* A simple content manager -- upload files, set permissions on them,
control access to them, and download them again.
* A simple browse-a-catalog-and-buy-things store?
* Other suggestions?


Webmail client
Jul 18 '05 #20

P: n/a
On Wed, 2003-07-09 at 15:17, A.M. Kuchling wrote:
On 09 Jul 2003 12:34:46 -0500,
Ian Bicking <ia**@colorstudy.com> 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

Jul 18 '05 #21

P: n/a
On 09 Jul 2003, Ian Bicking <ia**@colorstudy.com> 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/

Jul 18 '05 #22

P: n/a
On Wed, 2003-07-09 at 21:14, Moshe Zadka wrote:
On 09 Jul 2003, Ian Bicking <ia**@colorstudy.com> 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

Jul 18 '05 #23

P: n/a
Moshe Zadka <m@moshez.org> 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
Jul 18 '05 #24

P: n/a
Ganesan R wrote:
>>"Max" == Max M <ma**@mxm.dk> 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

Jul 18 '05 #25

P: n/a
Afanasiy <ab********@hotmail.com> wrote in message news:<eu********************************@4ax.com>. ..

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
Jul 18 '05 #26

P: n/a
Max M <ma**@mxm.dk> 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.
Jul 18 '05 #27

P: n/a
On Thu, 2003-07-10 at 10:01, A.M. Kuchling wrote:
On 09 Jul 2003 20:53:17 -0500,
Ian Bicking <ia**@colorstudy.com> 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

Jul 18 '05 #28

P: n/a
In article <ma*********************************@python.org> , 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...
Jul 18 '05 #29

P: n/a
On Thu, 2003-07-10 at 18:33, Jon Ribbens wrote:
In article <ma*********************************@python.org> , 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

Jul 18 '05 #30

This discussion thread is closed

Replies have been disabled for this discussion.