> > What would the disadvantage be of using Pyramid over a PHP framework ?
First, the disadvantage:
PHP is ubiquitous - it's on nearly every web hosting plan, and has
great support with simple installers for most linux distros. It also
rarely requires extra modules , and they can almost always just be
dropped-in to a folder.
With Pyramid, you need to have Python and install a bunch of modules
( preferably into a virtualenv ). It also often run daemonized on
another port or socket with port80 traffic being directed to it
somehow ( proxypass, uwsgi, etc).
Those are both broad generalizations.
In terms of the advantages ( adding to what others have said ):
You shouldn't consider Drupal at all. While it can be used as a
framework, it's a CMS -- so you'd be building modules for a CMS and
having to interface with all it's internal functions. You will get
frustrated.
Symfony is a fine framework, but it's a framework. I've generally had
this experience:
- A "framework" like Symfony, CakePHP, Rails, Django, etc will get you
up & running very quickly -- but your ability to innovate and iterate
quickly decreases as you start to code more for the framework ( and
getting around it ) than for your app.
- A "library" like Pyramid makes it a little harder to get off the
ground, but once you're up and running you can generally iterate
faster and faster -- slowly changing the model and request processing
into something that works for your teams scaling and product needs.
That being said, I want to address this line:
> I can utilize numpy & matplotlib directly iny data driven web page. Is that correct?
You could - and it's fine for development, but in production you
probably shouldn't. They're kind of intense packages and can take up
a bit of CPU and RAM. When dealing with stuff like that, I generally
do one of the following:
- Set up a daemon in Twisted or similar
- Build a separate Pyramid app that *only* handles those requests
By taking that stuff out of your app and pushing it elsewhere, you can
better control how memory and cpu are used ( by adjusting the
connections, etc for the other server ). The same strategy holds true
for PHP -- anything that touches PDF generation or 'mathy' things is
best put into another cgi/apache config where it won't affect the main
app