Python vs PHP
Catalin
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?
Thomas Weholt ( PRIVAT )
languages go I think there is little you can do in PHP that you cannot do in
Python some way or another.
Python has good support MySQL. Search for Mysql and python on
www.sourceforge.net. The docs contain examples on how to connect to the
database too.
General tutorials on Python are available at www.python.org, but more web
specific docs depends on what you want to do, how and where ( platform
etc ).
Give a bit more details.
Thomas
"Catalin" <ady...@ploiesti.astral.ro> wrote in message
news:mailman.105757447...@python.org...
News M Claveau /Hamster-P
PHP-5 let down MySql, for Sql-Lite (rumor ?)
Python has good support for MySql AND Sql-Lite.
@+
Michel Claveau
Gerhard Häring
> Can Python replace PHP?
With Python you can do everything that you can do with PHP. For Python,
there are lots of frameworks/libraries for writing web applications,
while PHP brings one out of the box.
> Can I use a python program to make an interface to a mysql 4.X database?
Sure.
> If that's possible where can I find a tutorial?
Python tutorials are at http://python.org/doc/Newbies.html
-- Gerhard
Aahz
Catalin <ady...@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
Bruno Desthuilliers
> 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
Ian Bicking
> Can Python replace PHP?
> Can I use a python program to make an interface to a mysql 4.X database?
Unlike PHP, Python does not have a single model for creating web pages.
See http://www.python.org/cgi-bin/moinmoin/WebProgramming for a slightly
intimidating list of options. If you feel comfortable with PHP, I would
advise using a similar system in Python, probably Spyce. Webware also
has a PSP component, which is slightly more like JSP than ASP (and PHP
is more like ASP). I believe mod_python will have a PSP option (but I
don't know where or if it's finished).
What you should remember when moving away from PHP, is that you no
longer have to use the server-page metaphor -- most of your application
logic should be in plain Python modules. Then you'll use your PSP (or
similar) page to present that code and respond to user input.
Python has good database access, look for MySQLdb, and the DB-API
documentation applies as well. There's several wrappers to make
database programming easier, see:
http://www.python.org/cgi-bin/moinmoin/HigherLevelDatabaseProgramming
For MySQL there's my own wrapper, SQLObject, as well as MiddleKi, PyDO,
and dbObj. For something a little lighter you might want to try SQLDict
for ll.sql -- I think you will find even these simple wrappers will take
a huge weight off your program compared to normal PHP MySQL usage.
Ian
Jaroslaw Zabiello
<ady...@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
Jp Calderone
> On Mon, 07 Jul 2003 13:47:00 +0300, Catalin
> <ady...@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://www.mems-exchange.org/software/quixote/
http://www.object-craft.com.au/projects/albatross
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
Afanasiy
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/mod_python/2003-June/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/12/02/1346206.shtml?tid=
http://httpd.apache.org/docs-2.0/mod/perchild.html
http://www.modpython.org/pipermail/mod_python/2001-November/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
Jon Ribbens
> 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.
Afanasiy
>On Mon, 07 Jul 2003 13:47:00 +0300, Catalin <ady...@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
Afanasiy
wrote:
No, CGI is not an option and I tried jonpy. I kept my notes about it...
Jon Ribbens
>>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...
The only similarity between FastCGI and CGI is the name. FastCGI is
just as fast, if not faster, than mod_python in my experience. jonpy
lets you use CGI or FastCGI or mod_python interchangeably anyway.
Afanasiy
wrote:
>In article <h7rlgvkogjr3t8geb...@4ax.com>, Afanasiy wrote:
CGI, FastCGI, SCGI are not faster than mod_python in my experience and
straightforward benchmark. That's all I can really say about it. CGI is
not an option for me.
Jon Ribbens
> 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.
Afanasiy
wrote:
>I don't understand why you keep saying "CGI is not an option" when
>nobody has suggested that you use it.
Ok
A.M. Kuchling
> 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
Afanasiy
Read.
Ng Pheng Siong
> Python web development is fragmented.
Wafer is a research project which compares the many open source web
application frameworks which are available using a common example
application. This research project is designed to compare the application
frameworks on a level field by specifying an example application so that
the application features become irrelevent and the merits of each
framework becomes the focus.
Java ones only.
--
Ng Pheng Siong <ng...@netmemetic.com>
http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes
http://www.post1.com/home/ngps -+- Open Source Python Crypto & SSL
Jon Ribbens
> 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 ;-)
A.M. Kuchling
Ng Pheng Siong <ng...@netmemetic.com> cited:
> Wafer is a research project which compares the many open source web
> application frameworks which are available using a common example
> application.
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.
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.)
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
* 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.)
* 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?
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
file contents and keeping a smidgen of metadata. With a store, we need
sessions for the shopping cart, and can invent some need for generating
on-the-fly images.
---amk
Thanks. The sooner I get discouraged and quit, the more time I'll save
overall.
-- Frank Sergeant, 28 Mar 1999
Daniel Dittmar
> 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/moinmoin/WebProgrammingShootOut as the entry
point for the specification of the application.
Daniel
Afanasiy
>According to Afanasiy <abeli...@hotmail.com>:
>> Python web development is fragmented.
>
>www.waferproject.org:
>
> Wafer is a research project which compares the many open source web
> application frameworks which are available using a common example
> application. This research project is designed to compare the application
> frameworks on a level field by specifying an example application so that
> the application features become irrelevent and the merits of each
> framework becomes the focus.
>
>Java ones only.
I explore and often create the feature lists of platforms through common
ground example applications in all my evaluations, web related or not.
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.
I can also imagine any sort of attempt at comparison, like a benchmark,
or the infamous language shootout, would be absolutely ridiculed.
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.
Ian Bicking
> 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
Lothar Scholz
> 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.
Bruno Desthuilliers
>
(snip)
> What you should remember when moving away from PHP, is that you no
> longer have to use the server-page metaphor -- most of your application
> logic should be in plain Python modules. Then you'll use your PSP (or
> similar) page to present that code and respond to user input.
Funny... when using PHP, I personnally write the logic in separate
modules, and keep the presentation in 'server pages' that call the
modules and format/print the result...
I don't see why coding in PHP should be that different from coding in
Python (except that one of them is a far better language whatsoever...
Too bad I can't afford Python-powered hosting)
Bruno
Aahz
A.M. Kuchling <a...@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.
A.M. Kuchling
> 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.
--amk
Paul Rubin
> 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
Ian Bicking
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
Ian Bicking
> 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.
>
> 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
> 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/
JanC
> [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
Max M
> Python web development is fragmented.
Ahem ... How os Python web development fragmented? Most of it probably
takes place in the Zope world.
But mod_python is an official Apache module. Wich sets it about on par
with PHP.
It has a standard library that beats the socks of PHP's builtin functions.
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.
Python is not fragmented, but there are more high level modules for
doing things.
There are more PHP developers, that's right, but they are all starting
from scratch, with a poor language. So it's their loss.
regards Max M
Ganesan R
> Afanasiy wrote:
>> 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? I must admit that I haven't
actually worked with any of the web development kits. As a casual observer
and a (mostly) lurker in this news group web development does appear to be a
bit fragmented.
I agree this is the case in the Python GUI world too. However, at least I
get the impression that wxPython, PyQT and PyGtk all are reasonably good
choices. I don't think you can say that for web development. At least not
yet.
Ganesan
--
Ganesan R (rganesan at debian dot org) | http://www.debian.org/~rganesan/
1024D/5D8C12EA, fingerprint F361 84F1 8D82 32E7 1832 6798 15E0 02BA 5D8C 12EA
Max M
>>>>>>"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
Ganesan R
> Ganesan R wrote:
>> 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.
You are probably right. I only given a casual look at PHP, so
I can't comment on the language, but I believe you :-). However,
PHP does come with a default (and only) web framework. This
obviously makes it easy to get started than to experiment with
Spyce or CherryPy or Cheetah or WebWare or any of the twenty
different alternatives.
Looking at it from the perspective of a PHP developer who's
looking into Python as an alternative. Python doesn't provides
her an out of the box solution yet. Think about what the
bewildering list of choices mean to her. This is not only issue
for development but also for deployment.
Paul Boddie
>
> 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/musings-on-twisted/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
A.M. Kuchling
> 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.
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.
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.
--amk
When is a cat not a cat? When it builds a cat-flap...
-- The Doctor, in "Survival"
Paul Rubin
> 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.
Ian Bicking
> 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
Joshua Schmidlkofer
> I can't comment on the language, but I believe you :-). However,
> PHP does come with a default (and only) web framework. This
> obviously makes it easy to get started than to experiment with
> Spyce or CherryPy or Cheetah or WebWare or any of the twenty
> different alternatives.
>
> Looking at it from the perspective of a PHP developer who's
> looking into Python as an alternative. Python doesn't provides
> her an out of the box solution yet. Think about what the
> bewildering list of choices mean to her. This is not only issue
> for development but also for deployment.
>
yeah, well right some nice looping code in PHP. Like loop over 30 or 40
rows in a database, format and display it. Then write it in python.
vast difference.
OTOH I really don't use PHP anymore, and I don't know if they cleaned up
the more recent versions.
js
A.M. Kuchling
On Thursday, July 10, 2003, at 02:47 PM, Ian Bicking wrote:
> 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...
... and Zope's old mod_pcgi, and mod_lisp, and doubtless a mod_ruby or
two; this wheel has been reinvented many, many times. Someone should
write a specification for the communication protocol (a protocol
simpler than FastCGI, which has a specification but is too complicated)
and then we can all use the same communication protocol.
Neil's spec for SCGI is at http://python.ca/nas/scgi/protocol.txt .
>
>> The Dulcinea package (http://www.mems-exchange.org/software/dulcinea/)
>> includes scripts for running multiple web sites on a machine
>Which portions are you referring to? None of the modules you describe
>in the overview seem to apply.
This is the bin/site script. See
http://www.mems-exchange.org/software/dulcinea/doc/site-management.html
for some documentation. (But it assumes that everything -- Apache,
site content, code -- live under /www, and changing that assumption
would be messy.)
--amk
Jon Ribbens
> 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...
Jon Ribbens
> Someone should write a specification for the communication protocol
> (a protocol simpler than FastCGI, which has a specification but is
> too complicated)
I think you've said this before, but I still don't understand it. The
FastCGI protocol is very simple, and even if it wasn't you only have
to implement it once and then everyone can use that code. jonpy
implements the entire protocol, including all optional features, in
500 lines of Python, which includes a lot of debugging code. If you
didn't implement the optional features, which most people don't, then
it's even simpler.
Harry George
This may be a case of "web application" meaning different things to
different people. Ours are architected as Model-View-Controller, with
the Model being a fairly sophisticated knowledge-based engineering app
(this lots of those add-ons you mentioned). We wrap that with
web-aware View and Controller code (which imports the Model) for
headers/footers, transaction state memory mgmt, exception handling,
etc. We sometimes do dynamic selection of which "imports" to do,
based on user-supplied data, or data from uploaded files.
In this context, the webification aspects are pretty simple -- we give
developers a framework and they fill in their particular View and
Controller functions. The intellectual energy is in the Model, where
PHP isn't going to help.
--
harry.g...@boeing.com
6-6M31 Knowledge Management
Phone: (425) 294-8757
Ian Bicking
> In article <mailman.105786283...@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
Jon Ribbens
> 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.
Certainly mod_rewrite can be difficult to get right. The redeeming
feature is RewriteLog which if you set it up to level 9 temporarily
while debugging means it is usually pretty clear what to do.
> 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? ;)
I've definitely never found it complicated, there's a lot of server
options you can tweak but I've never needed to change any of them.
It's 1 line in the httpd.conf to say when to use the fastcgi handler.
Mind you, I have a habit of finding problems in things hundreds of
thousands of people have used without trouble also, so YMMV ;-)
Graham Bloice
(snip)
> Too bad I can't afford Python-powered hosting)
See http://www.34sp.com". I've used them for two years and are
excellent value at GBP 15.00 per year.
Graham
Andy Todd
Don't forget the list of hosting providers you can find on the Wiki;
http://www.python.org/cgi-bin/moinmoin/PythonHosting
I'd be suprised if there wasn't someone on there who doesn't fulfil your
requirements.
Regards,
Andy
--
--------------------------------------------------------------------------------
From the desk of Andrew J Todd esq - http://www.halfcooked.com/