I only know PHP. How do I write a Web application in Python? | Hacker News Reader

I only know PHP. How do I write a Web application in Python?

me.veekun.com

230 pointsjrheard186 comments

I'd say the necessity of this post is why PHP is as popular as it is. With PHP, there are no package managers I have to install; there is no template language to learn; there is often no version control; there is no "framework"; etc. You just drop in a .php file and, most likely, it will just run. If I need a quick dynamic page on my server, it's much easier to do this in PHP than in Python or Ruby.

Until Python or Ruby have that kind of simplicity, they can't overtake PHP. While it might not be the kind of design that leads to well-designed web apps or even good code, it is the kind of design that leads to more — especially less technical, or, like me, lazy — users. It's up to the developers of those languages if this is even a market they want. There may need to be something new to do the same job as PHP, but better, without the innumerable warts.

Most of the post _isn't_ strictly necessary. You don't need a database to get your feet wet. You don't need to care about XSS for your first throwaway app (though, arguably, you should). I pimp Mako precisely because there's no separate language to learn: the core syntax is just Python.

I tried to describe the _ecosystem_, and I assume any serious PHP application will care about most of the same things.

Here's all you really need: look at http://flask.pocoo.org/ and do that thing it says right there. You don't even need to install a separate web server. (Yeah, yeah, 5.4, I know.)

A "quick dynamic page" is a deployment problem. If you're already running Apache and mod_php, you already have an environment ready to go to serve PHP, so of course it'll be easy for you. I don't run Apache, so PHP doesn't really help me there. (mod_passenger promises to, but I haven't tried it with Python yet.)

Also, http://pow.cx/ (Ruby I know, but it shows such things can be done.)

Also the argument of python/ruby requiring lots of configuration while php would not is just plain bullshit. Making PHP run with Apache (esp. on a windows machine) without stuff like EasyPHP (and this is where you stop comparing apples to oragnes) is by and large tough on the beginner.

Indeed, I would say setting up PHP and Apache is usually more work than setting up Ruby or Python behind nginx.

I am lucky that I found Flask a while ago, because I was sick of PHP. Flask, jinja2, and uWSGI have since been my best friends.

It took a little while to figure out how to setup a proper web server around those, but the guides are not that complex. Install nginx, darmonize uWSGI with upstart, and configure it. It's funny, in some ways it's easier to use than PHP, because when I am working with the website on my local machine, I can run uWSGI in http mode, no configuration necessary.

The only barrier I see going from PHP to Python or Ruby is managed hosting.

In fact, I felt impassioned about it enough to create a blog and write about it:

http://kramerapps.com/blog/post/22551999777/flask-uwsgi-ngin...

I agree on the simplicity of php. The barrier to write php is low. All you need is notepad and browser. This may be a transition from writing html.

Compare this to other languages where you need multiple tools before you can even begin.

This doesn't make php better. It just may explain why less people make the jump.

You also need a server, which I think is one of the crucial components for PHP adoption.

MAMP, XAMPP, WAMP are all really easy to install and you don't need to go into the CL to do anything.

All we need is to be able to drop an .erb file in a server and have it instantly rendered with the same magic of .php files. How hard would that be?

Anyone here know how to write plugins for Apache?

You just described python cgi scripts

Ahh! So I was: http://wiki.dreamhost.com/ERB

Now all we need to do is make this a default .cgi in all apache installations and we're golden.

Install eruby binary (example given is ubuntu/apache):

  sudo apt-get install ruby libapache2-mod-ruby eruby

Set up your web server to serve it:

  AddHandler rubypage .erb .xhtml
  Action rubypage /cgi-bin/eruby

Start writing pages like this:

  The time is <%= Time.now %>.

The first two steps could be completed by your web host, or done by you once. Obviously you might run into performance issues etc (no idea how well this would work on a live server), but that gets you up and running.

I would point out that most examples you can think of as trivial as that above could just be done with js anyway though, without any dynamic language server-side - the main reason to use a server-side language is to talk to a db or store data, at which point you probably want a framework anyway.

It's already a solved problem really, but people at that level are happy enough on PHP, which for the example above would be almost identical, and for anything more complex a framework is actually useful, and so there's no point in starting this way for many web projects.

As I recall a big issue with mod-ruby was that it used a single Ruby process for all scripts.

That meant if script A decides to rewrite, say, Array#include? to only work with symbols (or whatever), script B now has to live with it.

PHP is a template language at heart, so it's a little disingenuous to say that it doesn't force you to learn one, as it does - it's like the erb template language part of rails without the controllers and models. That's fine for what it is, but becomes cumbersome if you want to persist data to the db, handle forms for your models, etc at which point you'd often be better served looking at a framework which does a lot of that work for you. Some are available in PHP, but there are IMHO better options in other languages, and of course, better languages.

Do we need to have one language which scales from 'throw together a web page' to complex web apps? Is it even possible or desirable?

While I think it'd be nice to see Python and Ruby have the number of users that PHP does (though perhaps it wouldn't, with scale comes a worse NSR), it's probably not going to happen, simply because they provide a bit more structure, and many people don't want structure. Those people will be happy with PHP (until they're not, and realise they needed that structure after all), and I don't think Ruby or Python frameworks really have any ambition of catering to them. That's fine and is not a failing on either side. For example no one on the ruby side is going to stop using gems as package management because users starting out might be confused, as they are just too useful. You will find plenty of web frameworks for ruby which are simply one gem to install and off you go though - hardly onerous.

It would certainly be possible to write a better PHP, but all the people who might do that are busy using slightly more complex frameworks which make web development easier.

I am but an egg. But refactoring badly done projects that were started as PHP seems a plausibly common pattern. If Python or Ruby were simpler to start with, there would be more badly done Python / Ruby code, but at least it would refactor in Python / Ruby.

The core Py / Rb community probably wouldn't use simpler quick-and-dirty setups, they have the skills to the same things better and faster already. But making that pathway available would bring more novices to the language, hopefully growing them into Py / Rb. And it would bring more projects into the fold.

CGI scripts have much of PHPs simplicity. You can just drop in a executable file, and depending bit on server configuration, it will just run. With Python a basic hello world would look something like this:

    #!/usr/bin/python
    
    print "Content-type: text/plain"
    print ""
    print "Hello World!"

So 3 lines of "boilerplate", and then you can do anything you want. No extra packages to install or languages to learn. No frameworks necessary.

edit: just as an example of minimal hello world in WSGI:

    def application(environ, start_response):
        start_response('200 OK', [('Content-type', 'text/plain')])
        yield 'Hello World!'

also doesn't need any extra python packages or frameworks. but configuring web server to handle wsgi is bit more involved than cgi.

It's a good point that of course python web apps don't have to be complicated. But what you're describing is also not the same as PHP.

plus you can not just mix html and python code, which might not be a good practice, but is incredibly useful for something quick and dirty.

And therein lies the problem, in WSGI

99% of web sites are hosted in "shared hosting" services

Now compare copying the .php files with configuring WSGI

"No, but WSGI is easy blah blah blah" it doesn't beat copying files And no, settings WSGI is not easy

Also, if you depend on IIS for example, PHP is almost plug'n'play

WSGI on Windows is the definition of "bag of hurt". You can try fastcgi to run on windows, and then you find out flup needs socket.fromfd

The easiest way, if it's your machine, run gunicorn or similar and just make Apache redirect the traffic.

But in shared services it's still way too complicated.

FastCGI works fairly well in my experience on shared Linux servers (that's how I host my personal projects). And for smaller scripts where I don't bother setting up FCGI, I just use plain CGI, which is just copying files.

might want to not do that... http://www.php.net/archive/2012.php#id2012-05-03-1

That only affects PHP scripts running as CGI (using a certain specific configuration), not CGI scripts in general.

I think shared hosts have already enabled FastCGI for all php files

Something like this: http://test.fastcgi.com/drupal/node/5?q=node/10

At least the shared hosting I use (bluehost) has warned me they were enabling this. In 2007

Still, for most uses, CGI works fine.

Let's look at the PHP version:

    Hello World!

One line. I didn't have to worry about Linux/Windows, knowing HTTP headers or the fact that I need two CRLFs after the last header[1]. I just wanted a page that says "Hello World!" and that's what I got.

Don't get me wrong, I would never choose to write a web app in PHP over python. But it is brain dead simple to go from nothing to something in a few keystrokes. Which is precisely what people just learning to write web apps want (right or wrong).

[1] I can't remember how long it took me to figure out that I needed the second CRLF after the "Content-Type: text/html" when I was learning perl (or even the fact that I needed to specify the Content-Type in the first place).

In the context of the parent comment I'd argue that the differences are insignificant. Xuzz argued that PHP is simpler because you don't need to know the ecosystem. Which I countered by showing a basic example of Python which doesn't depend on the ecosystem (like frameworks, package managers or version control).

Besides that, I don't think knowing HTTP headers or understanding significance of trailing newlines is required to write CGI scripts. You only need to know that you need those three 'magic' lines in the front of your scripts. Similarly like you need to know that in php you need <?php ... ?> around your script.

But I never needed to worry about those three lines in PHP, to a new user that is important. To you and I they come naturally.

PHP "is especially suited for Web development and can be embedded into HTML" [1]. Python "lets you work more quickly and integrate your systems more effectively" [2]. They can both do the task of the other, but the upstart time for a developer to handle the task of making a web app is smaller for PHP.

I've never taken the non-framework approach with python for anything significant, but how does it handle cookies, GET and POST fields, sessions, and file uploads? In PHP you'd have $_COOKIE, $_GET, $_POST, $_SESSION, and $_FILES as built-in global variables.

Are these differences still insignificant?

[1] http://php.net/ [2] http://python.org/

Python has a `cgi` module that does most of the superglobal stuff for you.

But, er. Does this really matter? Yes, you can get "hello world" in PHP with one line of not-PHP. You can also get "hello world" in Python + Flask with seven lines, and you'll get half a dozen extremely nice features for free that you can learn about as you go.

Arguing about what stack has the simplest way to build from total scratch is a sad race to the bottom. I'd rather be making the point that rich Web development can be easy, not that cobble-your-own-thing-together-with-duct-tape can be easy.

The first poster in this thread made the statement: "If I need a quick dynamic page on my server, it's much easier to do this in PHP than in Python or Ruby."

So yes, it really does matter in the context of this thread. On the whole I agree with your philosophy that frameworks are there for a reason: you get many features for almost nothing.

But sometimes you just don't need a framework, you need something quick-and-dirty that just works.

But even something quick and dirty is longer than "hello world". I've written a couple pretty dinky things with Flask, and the minuscule overhead of typing `import Flask` was definitely worth having e.g. a solid template language and XSS protection ready to go.

Yeah, PHP is great to start off with, it's simple and everything in the language is obvio- Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM

That's only hard to understand if you don't speak Hebrew. Anti-Semite! :)

CGI is easy, yeah, but it has a lot of the same disadvantages as mod_php: no routing, no shared state, slow execution, server misconfiguration can expose your code, possible code execution if you accept uploads, etc.

There are approaches that'll let you dump a WSGI app (with a known interface) anywhere and have the web server still run it. Gosh, someone ought to write about those.

It took me a while to get used to creating an HTML file and making part of it executable. How utterly obvious and convenient. Templating systems and MVC frameworks now seem like bureaucracy that solve a purely theoretical problem.

Sure, if all you need is a mildly dynamic page the full blown MVC frameworks that are "standard" for other languages probably seem like bureaucracy to you. But they have their uses, and they also exist for PHP for a good reason. MVC makes massively complicated systems easier to maintain, especially if there's more than one contributor.

Example: I'm responsible for maintaining a "classic" ASP project that's evolved over many years ('98 was the oldest code comment I've found). A report has the wrong value for the record on it. Where do I go to find the source of the error?

You'd say "look at the page that edits that value". Well, sure, but there are dozens of pages that edit that database table plus dozens of other processes that could be altering it (stored procedures, print processes, scheduled tasks, people manually writing SQL statements, etc), looking at all of them would be a huge headache. In a MVC system, I would just go look at the model file of that table and debug the methods it uses to manipulate the database (that's simplified, but it's much less work than the spaghetti alternative).

That is of course assuming that the person who wrote the original code actually understood how to use an MVC framework.

It seems to me that most peoples default assumption upon encountering one is to use the Model as a simple abstraction to the DB and stick all of the logic in the controllers (with many controller methods calling methods in other controllers).

It would help if web frameworks that have precious little to do with MVC would stop trying to piggy-back on the term. For example, if your model, view and controller have a control flow that makes them three layers in a stack, with the controller sitting between the model and the view, then your architecture is not really anything like MVC at all.

The common architectural pattern for web apps where you have a request handler that talks to a database and then generates its output by filling in a template is popular and widely applicable. However, I think the way some of these frameworks tried to hijack a well-established term for publicity in the early days has come back to haunt them now they are better known. Today, if someone wants to learn how to use these web frameworks, particularly the common underlying concepts and design skills, and searches for "MVC", they find a whole load of other information that doesn't really make sense in the context of web apps.

Similarly, anyone who really does want to learn MVC in a context where it is more applicable -- including designing larger JS-based applications that run primarily in-browser, for example -- comes up against a lot of material that is in some cases almost the antithesis of MVC, which doesn't help there either.

When the most common reasonably simple architecture beyond PHP's everything-is-a-template starts off at such a disadvantage, it's not really surprising that many people struggle to understand the basics and just stick with PHP's "it just works" instead, despite the other disadvantages they suffer in making that choice.

There appears to be currently ongoing some sort of shift in web development.

At the top end of the scale , people are creating more sophisticated "app like" websites that use sophisticated platforms like AWS and "serious" programming like Scala/Java/Ruby/Python/jQuery etc. Because once you have decided to invest serious money in your web development you want to use the best tech you can and build a very "bespoke" online experience.

However at the lower end, sites that would have 5 years ago been build using static HTML with a smattering of PHP and be run on low end shared hosting are being devoured by various platforms. For example rather than hire a webdesigner you can have a facebook fan page or wordpress blog for free (possibly paying someone to customise the CSS in a template for you). As another example in my area there are various services aimed at the takeaway business that provide a turnkey website with an online menu, opening hours, maps etc.

To be honest, working in the low end of the web dev market has always been a nightmare as this is where you will get shaky clients who can't articulate what they want and hardly want to pay anything for it.

If I was going to go back into website development for a business I would be far more interested in finding common requirements for a particular market segment and building something turnkey to sell to 1000+ customers at $20-100 per month where they can upload their own logo and change a bit of the CSS.

Regarding your last point... are you talking 'turnkey' as in something like 37 Signal's Basecamp?

To an extent , yes. Although basecamp is something that is intended more as an internal tool that just happens to work over HTTP and is not directed at any specific market niche (other than perhaps general SMB).

Let's think about real estate as an example. I imagine that pretty much every real estate agent will want the following features on their website:

A list of properties (that can be sorted by Price etc)

Search By Postcode/Zipcode.

Then a page for each property with:

Pictures from inside/outside the property.

Asking Price.

Number of bedrooms/bathrooms.

Some blurb about the property.

A form to book a viewing (possibly integrated with calendering at the backend).

Of course they will also want the generic "contact us" pages and pages about how great they are.

You could develop all of this bespoke every time for each estate agent, but then the amount of time you invest and how good you can make it are capped by the amount of money they want to spend on the project. You also have to worry about hoating arrangements for each client.

Alternatively you could just build the best real estate website you can make, host it on your own infrastructure and charge a monthly fee to rent an "instance" of it. Because the website is already built activation can be instant.

As an added benefit (if you get enough users) you now have a huge database of properties which you could potentially use to launch your own property search/comparison website.

You will have customers who will require more custom functionality and will eventually outgrow your "one size fits all" system regardless of how customisable you make it. At this point however they are probably willing to pay a significant amount of money to have a bespoke website developed. Another option at this point would be to license them the sourcecode for your system so that they can take it elsewhere for modification.

> "With PHP ... there is no template language to learn"

While this might be nice for the beginner getting started, it's also a brilliant way to encourage bad habits in people who want to turn it into a career.

Leaving the "PHP is a templating language" pedantry aside, this 'benefit' encourages the aspiring developer to not bother separating concerns. Just go ahead and throw HTML into PHP and vice-versa; throw all your database logic, SQL, and connection details into those self-same files that are being served; leave XSS vulnerabilities in all your code because you probably weren't told to wrap your output in `htmlspecialchars` or whatever.

Shit like that needs to stop. But as the barrier to entry is so low, the same mistakes will be repeated ad infinitum. I would love to figure out a way to introduce a beginner coder to a language, without scaring them off, but without being lax with security and separation of concerns.

That being said, I do agree about frameworks, but I also think that this is because there is no "one true framework" for PHP (Zend, Symfony and Cake don't fit the bill, I don't think). There's no Rails, or Django, and there's no Sinatra or Flask as a minimal alternative. PHP is dire for framework development, not because of the language, but because so many groups of developers are trying to re-invent the same framework (but with their own idea of what 'the PHP way' should be - Javatastic bloat like Symfony and Zend, or Rails mimicry with no real understanding of PHP not being anything like Ruby), treading the same ground over and over again, when there could be more collaboration to provide the definitive offering.

If that were to change, and for the better, I might extend my argument to say that such a framework may be a great way to learn PHP, just like Rails was a great way for many to learn Ruby.

Nice littel overview, but...

"Unicode sucks. This is a universal truth."

And here I stopped reading. Unicode is the best thing around, what sucks it that Py2 does not implement it very well. Py3 does, and that is the main reason I really would like to use it and hope Django will soon fully support it. (Because: there are other languages beside the European ones)

Fair point. Correction: working with encodings sucks.

Py3 isn't magnitudes better with Unicode; it's better about converting incoming bytes, and it makes literals into real strings. But the former isn't necessarily a good thing, and you can get the latter with a `__future__` import. Always dying on implicit conversions is definitely nice, though.

Working with encodings is indeed annoying in Python, but it’s not a “universal” problem.

There is a language called 'Java' where every string is in unicode, and I do not remember ever running into an issue!

Except that Java strings aren't in Unicode. They're in UTF-16, which is the worst-of-all-worlds encoding. (It's big and heavy, and it still has multibyte sequences. They're just rare enough that you're likely to forget about them during testing.)

UTF-16 is most certainly Unicode, even if it isn't the preferred flavor.

"UCS-2 (2-byte Universal Character Set) is a character encoding that was superseded by UTF-16 in version 2.0 of the Unicode standard in July 1996". Java adopted UCS-2 which was later supplemented with UTF-16 support.

There are at least a few languages in this world which do not use roman letters and are better represented as multibyte sequences :). That is why Java added support for supplementary UTF-16 characters over and above UCS-2. That said, use of UTF-8 would have been optimal for western languages, but sub optimal for several other languages.

Wrong. UTF-16 is an encoding, Unicode is the abstract representation. You can encode Unicode strings into UTF-16, but that doesn't make UTF-16 Unicode. Python's Unicode strings are actually really just Unicode, that's why you can't write them to a file or anything - you need to encode them first (which defaults to UTF-8).

Unfortunately it only defaults to utf-8 in Python 3

In Java, you end up seeing the guts of UTF-16 far more often than you should. Most notably, the String APIs often index strings by UTF-16 code units, not characters, so string "lengths" don't always correspond to the number of Unicode characters, and you can end up cutting surrogate pairs in half if you aren't careful.

Working with encoding is not that bad in for example Ruby 1.9. What makes them horrible to work with are the bad design decisions in Python, especially Python 2.

I've only read about Ruby strings, not used them, but they seem like a middle ground between Perl's approach and Python's approach. What do you perceive as the problem with Python?

I would love to switch to Python from PHP but I can't. The reason is I keep getting told to learn Python 2. Python 3 has been out for ages!

Basically I am concerned that I will learn something and create app's which within a year will be out of date. I am confused why Python developers are advocating that newbies learn an old and presumably soon to be legacy version of the language.

I remember when this kinda happened with PHP and versions 4 and 5. I still run across hosts who default to PHP4!? WTF? Its 2012!

Is PYthon3 really that new that you shouldn't pick it up or is this developers still refusing to update?

Python 2 versus 3 isn't anything like PHP 4 versus 5.

The problem is that there are a few minor but backwards-incompatible changes to the syntax in py3. Libraries can't update until all their dependencies update. And web frameworks are some of the most complex software with the most dependencies, so they're updating last.

It's still pretty much the same language behaving in the same way, though. If you know Python 2 really well, it'll take all of five minutes to get accustomed to Python 3. Just don't worry about it and learn 2 until people stop telling you otherwise. :)

"Don't worry, migration from Python 2 to 3 is really easy. It'll take 5 minutes to learn."

"Migration for libraries from Python 2 to 3 is really hard. It's taken them a few years and counting."

Right. Learning Python 3, once you know 2, is really easy.

Library maintainers have two problems: they have to twiddle their thumbs until all their dependencies have ported, and then they have to get their code running against both 2 and 3. The former is exactly why I'm saying to use 2 for now, and the latter is easy if you only support 2.7 but rather more difficult for projects that still want to run on some archaic thing like 2.3.

Python3 isn't much different from Python2. It's not like you have to re-learn Python when you switch from 2 to 3.

In a nutshell: print() has become a function instead of a statement. The standard library has been made more consistent. Built-in iterators are lazy by default. The two string types (str and unicode) are properly redefined as 'bytes' and 'strings'.

In practice, for MOST developers, the changes between 2 and 3 are minimal. Offhand, print is a function, and there's no distinction between unicode strings and ascii strings anymore. If you do a lot of "low level" networking involving byte strings, you'll notice the difference, because you can't just jump between bytes and strings anymore.

It's this distinction that's delaying a lot of networking related libraries from porting to Python 3 - basically, it's going to be a long, buggy journey. Libraries such as Twisted, have very old codebases - old enough that some of the practices aren't the best, even for Python 2 code. Upgrading it to Python 3 will introduce quite a few breakages.

There's a lot more that I can't think of right now, but I'm sure someone else can cover off other differences.

There's no reason not to learn both - I use Python 3 for a few personal projects, and Python 2 for work.

Python 3 is not "really that new" and Python 2.6-2.7 is not "old" in any way.

In fact we have: pre-2.4 (really old, preinstalled on old Redhats), 2.4-2.7, 3.x

Python 3 is curing problem with variable visibility (and if you do not write in "pure" functional way - you will never see this problem) and unicode strings. Other differences is not so "revolutionary".

> (and if you do not write in "pure" functional way - you will never see this problem)

Could you explain this a little more, please?

I assume he's talking about the `nonlocal` keyword introduced in py3, which allows overwriting names defined in outer-but-not-global scopes.

Yes, eevee is right.

I'm talking about http://www.python.org/dev/peps/pep-3104

New keyword nonlocal and ability to have better closures.

For the vast majority of projects, upgrading (or working with both PY2 and PY3 at the same time) is not that big of a deal unless the project you're working on is really, really old (2.3 days). At work we run unittests targeting different python versions and the most time I've spent changing a typically 4k loc project's codebase to work on both 2 and 3 has been around 4 hours. The average around 1.

The differences between Python 2.7 and 3.x are going to be minimal. You can mostly write Python 3.x style code in 2.7 and still have access to all of the libraries that have not ported their code yet.

> I am concerned that I will learn something and create app's which within a year will be out of date

Don't worry about that. Start with Python 2 and if you ever have to move to Python 3, it will be fairly easy.

The same thing happened in the PHP world during the switch from 3 to 4 and then 4 to 5. The move from Python 2 to 3 will probably be smoother.

   The idea is that a transaction starts when a request  starts, and it’s automatically rolled back if there’s an exception. This is behavior you want from the start! It’s half (err, ¼) the point of using a database.

I mostly agreed with the rest of the article but this strikes me as massive blooper. I can see no reason this would be considered good advise.

It's the database equivalent of the GIL, can't figure out what you actually need to lock? Just lock everything!

An example of this going wrong in production, I work in the online gaming (gambling) industry. One of our users won a large jackpot, our code started a transaction, contacted the 3rd party to have them release the funds, recorded the win in the transaction journal, updated the customers balance etc. Then the stored procedure which inserted a row into the outgoing email queue had a small error. This caused all of the database work on our end to rollback.

For what its worth, this was discovered during a reconciliation with the 3rd party and the customer received his winnings.

My point being, this is a horrible way of dealing with database transactions. Only things which are transactional by nature should be carried out within the same transaction. Obviously your code needs to deal with any errors and carry on or report an error as is appropriate.

The transaction is internal to the database. It's essentially a list of operations to perform, if something goes wrong it provides a list of things to reverse. If the db transaction fails, then there would need to be some code to handle rolling back operations outside of the database. I don't think db transactions were to fault in your situation.

I'm not sure I really get what you are trying to say. I know what a transaction is, and I know it wasn't the fault of transactions. It was the fault of our poor use of transactions, in the same monolithic transaction pattern that the OP appears to be advocating.

transaction-per-request is by far the best default pattern to use. If some particular methods have special needs, like needing to break up the operations into multiple transactions to deal with third-party communication, those are the exceptions.

The alternatives to transaction-per-request are autocommit, or explicit transactions required at all times. Autocommit is a terrible choice because now you've lost all atomicity and isolation for dependent operations (locking is also not much of an issue. If you're doing VB, then you're on SQL server, which has some of the worst locking behavior - turn on snapshot isolation to make it bearable). Explicit transactions required at all times is a terrible choice because now your app is littered with what is 90% of the time unnecessary boilerplate.

Why not the third (and in my experience most common) alternative? Autocommit but if you explicitly start a transaction then automcommit is turned off until that transaction has been committed.

If you have more than one statement, then autocommit is usually wrong, and what you usually want is transaction-per-request. If you have exactly one statement, then autocommit is exactly identical to transaction-per-request.

Also part of the transaction-per-request pattern is that the transaction is started when the first statement is invoked. So there's no overhead for zero-statement requests either.

It seemed you were arguing against using transactions by default because they didn't roll back a call to a web service. I meant to point out that the issue in your case seems less about db transactions and more about the code and error handling.

Indeed, transactions should be as short as possible but no shorter. If your code crashing within a set of queries would leave the code in an inconsistent state you should probably wrap them in a transaction, but if not you should not put them in the same transaction.

> An example of this going wrong in production, I work in the online gaming (gambling) industry. One of our users won a large jackpot, our code started a transaction, contacted the 3rd party to have them release the funds, recorded the win in the transaction journal, updated the customers balance etc. Then the stored procedure which inserted a row into the outgoing email queue had a small error. This caused all of the database work on our end to rollback.

Updating a customer's winnings and recording a win are definitely things that should be together in a transaction - if one happened and not the other, that's a failure.

This is not the fault of using a transaction, this is the fault of not working with what is essentially a distributed transaction. Since you are relying on a message against a third party, you need to build distribution into this system, which is challenging. You might contact the third party after you've completed the internal processing, and you might use two-phase semantics even such that you can "PREPARE TRANSACTION" the work you've done locally, (nearly) guaranteeing that a commit will proceed, then work with your external messaging, then commit locally.

background at http://en.wikipedia.org/wiki/Two-phase_commit_protocol

> Updating a customer's winnings and recording a win are definitely things that should be together in a transaction - if one happened and not the other, that's a failure.

Yes, they these clearly do belong in the same transaction. Inserting a congratulations email into the email queue doesn't.

emails typically get fired off as part of a post-commit hook. Pyramid's transaction manager has explicit support for this pattern - as you establish "emails" within your trans, the actual send operation is deferred til after the transaction proceeds.

It's only default behavior. The alternative is for any request that runs more than one query to be inherently but unpredictably unreliable; that is definitely not acceptable.

If you're doing something complicated, you're going to have to tread carefully anyway. No default could have handled your situation cleanly.

For what it's worth, zope transactions (which Pyramid uses) support combining notions of "transaction" from arbitrary other services and tries to do the right thing for a commit and rollback. I've used this to keep a database and mogilefs in sync, for example.

"MySQL is the PHP of databases". Strange, I just had this sentence popping in my head yesterday. I'm seriously considering writing a list of its wrong doings.

Great article overall.

I'd be interested in reading that list!

Please write that list. I'd be very interested in reading it.

Color me as another interested specimen.

I wanted to do that now but did some lego with my kid instead, will keep you 3 informed when done.

It seems an article on Ars Technica has already compiled some defect of MySQL:

http://arstechnica.com/civis/viewtopic.php?f=20&t=92525

Another thing that reminds of PHP, the list of commands:

    mysql                       mysql_client_test_embedded  mysql_find_rows             mysqlrepair                 mysql_tzinfo_to_sql
    mysqlaccess                 mysql_config                mysql_fix_extensions        mysqlreport                 mysql_upgrade
    mysqladmin                  mysql_convert_table_format  mysql_fix_privilege_tables  mysql_secure_installation   mysql_waitpid
    mysqlanalyze                mysqld                      mysqlhotcopy                mysql_setpermission         mysql_zap
    mysqlbinlog                 mysqld_multi                mysqlimport                 mysqlshow                   
    mysqlbug                    mysqld_safe                 mysql_install_db            mysqlslap                   
    mysqlcheck                  mysqldump                   mysqlmanager                mysqltest                   
    mysql_client_test           mysqldumpslow               mysqloptimize               mysqltest_embedded

Why the hell show we want a 'mysqldumpslow'? Is it because mysqldump is fast but wrong? And why not mysql_dump?

I have started with MySQL for my first (php) website, and to me the database was just the natural storage, I had no idea of the problems, because I didn't know that a relational database is a particular well-defined mathematical object, which asserts truths about the "world" in a manner that makes it possible to model this world safely and ask questions about it. Then I used PostgreSQL at my previous work, and discovered it all, the hard way. And PostgreSQL has (almost) always been a reliable companion taking care of the most valuable asset: the Data. Then I switched job and have to use MySQL again. I live with it, it's fine, but the difference is not benign, and I sometime wonder if the NoSQL movement is not a partly a misunderstanding and should renamed NoMySQL: when using an unreliable datastore, it is certainly better to use one that is explicitly not reliable and do not force on you the relational model while, at the same time, not giving you its strengths.

In case anybody was wondering: mysqldumpslow is for dumping MySQL's slow query log.

Linux is the PHP of Unixes and Apache is the PHP of webservers. And now we have covered the whole LAMP stack :)

Is there any cheap & easy webhosting available for Python?

Occasionally I get commisioned to build small websites ( < 50 visitors per day) and for that I want to be able to build the site in a day or two.

I don't want the hassle/expense of having to setup and run VPS/AWS infastructure. I just want to give someone a bunch of files and say "sign up for some cheap webhosting, ask them to give you a DB called X and upload these".

I usually end up just doing it in PHP, but it has always felt like a poor reason to choose a language with so many warts.

Heroku is a good choice,

> This quickstart will get you going with Python and the Flask web framework on the Cedar stack. For Django apps, please see the Django quickstart.

https://devcenter.heroku.com/articles/python

It can be very cheap or free at low scale,

> Each application receives 750 free dyno hours per month.

https://devcenter.heroku.com/articles/dynos

Replying to Jiggy, but can't directly reply since it's dead:

No, a simple Rails app is not very coupled to Heroku.

The deployment process is simpler and pretty unique to Heroku, but it's usually pretty easy to move away from Heroku or deploy in parallel to another location. I actually deploy one app to Heroku and I have an offsite backup process that deploys the same codebase to a NGINX/Passenger setup and clones the production Heroku data to that instance.

Your mileage will vary, of course. If you start using a bunch of Heroku plugins, you'll find it's harder to maintain an easy dual-deploy setup.

You can get close to that with Webfaction (some assembly required) or Heroku.

I've had a lot of great luck with dotcloud.

http://docs.dotcloud.com/services/python/

I have no idea why web2py gotten such a bad rep. I am a beginning webdeveloper and seriously: web2py is a pleasure to work with. Simple to start, deploy, port and hack. It's backwards compatible and has a template language that really is non existant as so far as its pure python.

Compare that to Rails - which is (comparable) hell to set-up and breaks with upgrades etc.

If you want python web development to be simple, web2py is the way to go. Since I don't have a CS degree and I have often been wrong before - there might be a real problem somewhere. But I don't think so. One of the reasons for this is that Jakob Moss removed his web2py bashing from this thread. Didn't edit - removed it: https://www.quora.com/Is-web2py-a-good-Python-web-framework/...

> But I don't think so. One of the reasons for this is that Jakob Moss removed his web2py bashing from this thread. Didn't edit - removed it: https://www.quora.com/Is-web2py-a-good-Python-web-framework/....

What did he remove?

https://www.quora.com/Is-web2py-a-good-Python-web-framework/...

This isn't the first instance of Django/Flask people not agreeing with web2py design and implementation, and they have been vocal about it a couple of times.

http://www.reddit.com/r/Python/comments/ex54j/seeking_clarif...

Look for comments by mitsuhiko(flask dev) and jacobian(django dev).

Sorry - I remembered that I on an earlier occasion couldn't find JKM' answer. It's there now - and I personally don't find it convincing. Again - I am a novice and has no authority here. – I'd edit above if I could. I am sorry that I wrote wrong info.

Thanks for the reddit link. As you say it seems to me most of the flak is from not agreeing on something. But can an oppinion be correct?

And yes: Mitsuhiko seems to be a super cool, clever and friendly guy. In my last project I played around with request. Lovely it was.

Anyways: my point was not to express that web2py is the greatest thing invented since bacon. Only that I don't understand why the python community dislike it so. After all - web2py makes it very easy to build stuff. Hence it will probably attract people to the language. Hence make it more feasible for webhosts to offer python friendly environments. And that should be a good thing? Especially in the context of OP - "how do PHP guy start with python"?

>And yes: Mitsuhiko seems to be a super cool, clever and friendly guy. In my last project I played around with request. Lovely it was.

That would be kenneth reitz https://github.com/kennethreitz

But I do agree, mitsuhiko is a super-cool guy!

Personally, I _like_ PHP because, at the core, it is a collection of utility functions to write webapps quickly. Here's a small set of those function that I would like to see somewhere else (like in Python for example):

Save a file: file_put_contents()

Load a file: file_get_contents()

Trim whitespace: trim()

Print a string (even numbers!): print $str

Dump an array: print_r()

Print the stack trace: print $e->getTraceAsString()

Want to embed HTML? Go ahead, _without_ any of this nonsense: print "<table><tbody><tr><td>"+str(val)+"</td></tr></tbody></table>"

Want to check for errors and improve the quality of the code? Go ahead! Use lower level functions like fwrite, fread, etc; most functions return FALSE on error, use try/catch, throw Exceptions, create custom Exception classes, go nuts with over-architecting if that's your thing.

Also, as someone who knows C and C++ rather well, I find PHP completely intuitive, very easy and flexible, as opposed to:

  if __main__=="__main__": 
      main()

and passing self around is just plain redundant.

The icing on the cake is that a huge part of the built-in functions wrap and extend existing C functions: strpos, strlen, so the language rarely gets in your way. The docs are pretty good (there's room for improvement).

So you can be a zealot all you want, but the truth is: the language doesn't make your code reliable - YOU make the code reliable and, from my experience, people who bash a language rarely know what they're talking about and it usually just boils down to personal preferences like braces vs no-braces.

Lastly, I wish you all the best in your fanatic bashing of a good tool that has proven itself appropriate for web applications. Everyone's tired of the following example, but I'm going to say it anyway: Facebook (and thousands of other large websites). Feel free to be in denial about that.

In Ruby:

    # Save a file
    f.write(str)

    # Read a file
    f.read

    # Trim whitespace
    " foo ".strip

    # Print anything
    puts 1 # even numbers!
    puts File.open("foo", "w+") # even file handles!
    puts [1, 2, 3, 4] # even arrays!
    puts [].class # even classes!
    puts [].method(:size) # even functions!

    # Dump an array (see above)

Python is similarly clear:

    # Save a file
    f.write(str)

    # Read a file
    f.read()

    # Trim whitespace
    " foo ".strip()

    # Print anything
    print 1 # even numbers!
    print open("foo", "w+") # even file handles!
    print [1, 2, 3, 4] # even arrays!
    print [].__class__ # even classes!
    puts [].remove # even functions!

    # Dump an array (see above)

Ruby and Python are extremely well documented. They have great standard libraries which wrap existing C functions too...and wrap them in a consistent fashion. They are also the second and third most popular language on Github, respectively...which means tons of great libraries to solve almost any problem you can think of.

Ruby and Python are just as easy to use as PHP.

Not sure about the Python ones, but the Ruby read/write file examples aren't quite fully done/correct here:

  # Equivalent of file_put_contents() in PHP
  # This could also be used for appending if the correct mode is specified.
  File.open("filename", "w") { |f| f.write("some data") }

  # Equivalent of file_get_contents() in PHP
  some_var = File.read("filename")

Python:

with open("filename", "r") as a_file:

    contents = a_file.read()

Ruby 1.9.3 added File.write("filename", "some data").

Cool. Didn't know that. Thanks.

I guess I should have specified "where f is a file handle":

f = File.open("foo", "r") f.read

f = File.open("foo", "w+") f.write(x)

> Personally, I _like_ PHP because, at the core, it is a collection of utility functions to write webapps quickly. Here's a small set of those function that I would like to see somewhere else (like in Python for example):

As another commenter has already posted, these are pretty trivial in Ruby and Python(and plenty of other languages).

> Want to check for errors and improve the quality of the code? Go ahead! Use lower level functions like fwrite, fread, etc;

fwrite/fread improve quality of code? As opposed to what?

> The icing on the cake is that a huge part of the built-in functions wrap and extend existing C functions: strpos, strlen, so the language rarely gets in your way.

I don't see how your conclusion follows from your premise. How does a language using strlen equate to not getting in my way?

> from my experience, people who bash a language rarely know what they're talking about and it usually just boils down to personal preferences like braces vs no-braces.

None of the languages are perfect. Though a lot of people bash languages without knowing their shit, it doesn't mean all criticism is invalid. PHP has warts - warts that go beyond personal preferences.

> these are pretty trivial in Ruby and Python I wasn't arguing that they're difficult, I was saying they're quick, dirty functions you can use to get something up quickly (the RAD way).

> fwrite/fread improve quality of code? As opposed to what? as opposed to just using file_put_contents() and never checking for the number of bytes actually written. The point I was trying to make is that you could use quick, high level functions (like file_put_contents()) and then replace them with more low-level functions like fopen()/fwrite()/fclose() to have more fine-grained checking of errors (you could complain that the script failed to open the file when calling fopen() and then you could print the exact reason why, as opposed to just printing 'could not write to file' when using file_put_contents).

> How does a language using strlen equate to not getting in my way? I switch between languages pretty often and so keeping an active context for each language in my mind is rather difficult. I have to recall if it's len(), str.len(), str.length, str.length() and so on for every other type of task I need to deal with. If the language is really similar to C, it is more natural for me to use strlen() even if I have to come back to it after 6 months. That's what I meant by 'not getting in my way'.

> it doesn't mean all criticism is invalid. PHP has warts - warts that go beyond personal preferences.

I agree. No language is perfect, but why do you feel compelled to say 'PHP has warts [...] that go beyond personal preferences' without actually bringing evidence. It makes it sound like you're speaking purely out of hatred for PHP and I can't respect that.

I get the feeling you aren't very familiar with Python. Actually I'm hard-pressed to name a popular language in which writing a string to a file is particularly difficult.

You don't have to check for errors in Python; most functions raise exceptions on error, rather than letting your program continue with a known bad state.

The `if __name__ == "__main__":` pattern is a cute trick to distinguish a module from a file being run directly. It's not strictly necessary; just a nice habit. It's spiritually similar to the checks you have to do in PHP library files to make sure they're not being run directly.

You don't have to pass `self` around. You just list it as a parameter. There are design reasons for this, it's a tradeoff, blah blah. Think of it as the price you pay for getting to type 'def' instead of 'function'.

I'm not a C programmer, and I doubt many people writing web applications are, so how does wrapping C functions with C names help me? Are `'b' in 'abc'` and `len('foo')` that difficult to understand?

I like to think I've covered my reasons for disliking PHP well enough by now.

Okay. You're not the target audience of this article, then.

> a cute trick allow me to disagree about the cuteness of that. there are ways to distinguish a module from an executable file. For example, 'main' could be a special function (like in C).

> you just list it as a parameter yes, that's what I wanted to say. the fact is, in other languages I don't have to list it as a parameter and I don't have to get used to it. Personally, I find it annoying (but I could live with it, like everyone else).

> how does wrapping C functions with C names help me forgive my forward reference, but I will argue that "you're not the target audience" for this language. I found that PHP works best if you're coming from a C background and you treat it as a C-based scripting language (and this is kind of what PHP claims to be). I've always suspected that people coming from other backgrounds are the ones who will dislike PHP the most (and it doesn't surprise me), but I also don't know why they seem so vocal about it. I, for one, don't post negative comments about Ruby/Python (unless I'm comparing PHP with them) because I acknowledge that other people with, say, LISP backgrounds will find those more intuitive and will make efficient use of the them.

Anyways, cheers.

Strictly speaking, `main` isn't even a special function in C. It's only special to your C library and linker and something something I forget the details. Anyway it doesn't matter at all; you could leave off the `if` in Flask's example and never notice any difference. Just emerged as common practice to bracket off stuff like that /in case/ you ever decide to import your script as a module.

Part of my problem with PHP is that it doesn't seem to know what it is; there are the C parts, and the C++/Java parts, and both sides are sort of glued together with Perl influence, yet don't very well interoperate otherwise.

I have a pretty patchwork background and I could get work done in just about any language you'd pay me to use. I'd even happily write a web app in C. Doesn't make PHP any more attractive.

In implementation terms the main function isn't special, but its prototype is part of the C specification: http://groups.google.com/group/comp.std.c++/browse_thread/th...

This guy failed to cover web.py which is one of the fastest ways to start prototyping a web app in python. =/

http://webpy.org/

I personally use it for a small app which returns (and stores) search suggestions from redis.

I was thinking this could redeem the author's credibility a little after the PHP rant, but the irrational hatred for Cheetah sounded very familiar.

I only used it in one project, a few years ago, but there's really no bad thing about it I couldn't say about any other templating system in any language I ever tried.

I wouldn't really take offense with that, but while the XSS chapter still has some points, the Sanitizing chapter goes on to bash PHP for a subjective trend of sanitizing (examples?) just to go on and present an example of sanitizing.

In general, it was a decent article, but sadly again much more opinionated than needed. It's one thing to suggest one technology over the other but it doesn't help to make people who actually agree with your point have their eyes rolling every second paragraph. (That the author doesn't like MySQL was to be expected after the PHP rant as it usually goes hand in hand, but showing some real reasons for Postgres over MySQL would have been nice.)

Still the same criticisms apply, I'd wager most people use PHP (or MySQL for the matter) because it's MINDBLOWINGLY AMAZING, but because a) the infrastructure is set up (especially DBAs hate to mix and match in my experience) b) the people at hand can use the language and use it well c) it gets the job done. quickly. sometimes "good enough".

Explaining why what he does not like about MySQL would have been moving too far from the subject of the article.

And I liked the sanitizing chapter. It explains well why "sanitizing" is a misused word, which should be avoided. Almost always when I see people call it "sanitizing input" they do not seem to know how to handle input correctly.

I don\'t see the problem with \"sanitizing\". It\'s easy: just add a \\ before every quote and the string is totally safe!

I'm kinda the de facto owner of Cheetah for a fairly heavy user of it—quite possibly the heaviest. It may appear-to-work for a small project, but you would not believe the insanity that lurks beneath the surface.

It's been effectively dead for years, anyway, and the author admitted he'd jumped ship for Mako in 2008.

I like java for web app development, simply because it has a well-structured api and a massive community of developers who have run in to the majority of the road blocks you will most likely encounter on the way to launching your app.

What frameworks and platforms would you recommend for web development with java? I am writing my senior project at college in java (mainly because of the wide amount of image processing libraries available) and would love to add web capabilities.

I tend to prefer Python/Flask for Web dev to Python but if you are inclined to use Java there's only really one framework that doesn't make me want to tear my eyeballs out.

That framework is Spring MVC.

It is DI, adapters for vendor-specific libraries and utility. It's probably not the easiest thing to start with just because it is so flexible that it can be hard to know where to start. A good "Hello World" Spring MVC 3.1 app would go a long way.

I really would like to use the Play Framework and it's so close to being great but it just falls too far short.

I really liked Play 1.x with Groovy templates. It was simple and it pretty much just worked.

Play 2.x has gone in a radically different (and backwards incompatible) direction. It is now part of Typesafe and the goal of Play 2.x is to make Scala a first-class citizen.

The problem is that many of the niceties of Play are either harder to use or just outright missing in Java Play 2.x (eg AppEngine support and the OAuth client were all present in 1.x and are slated for a future 2.1 release).

There really is a niche for a Java Web framework that like Play ditches the JEE/servlet model in favour of the Rails/Django way of doing things (including dynamic class reloading) but doesn't do it in a way that makes me want to stab myself repeatedly.

This would include playing nice with the Java ecosystem (seriously just use Maven and to hell with SBT).

Grails (grails.org) is Spring under the hood, good MVC layer on top, and gives you Java or Groovy wherever you want to use it. For people coming from a dynamic language background (php, python, ruby, etc) I've found that Grails is a good middle ground option.

That framework is Spring MVC.

Agreed that Spring MVC rocks, but Grails[1] is also awesome, and Wicket[2] is pretty cool.

[1]: http://grails.org/

[2]: http://wicket.apache.org

Can't you stick with 1.2.x?

It's probably not the easiest thing to start with just because it is so flexible that it can be hard to know where to start. A good "Hello World" Spring MVC 3.1 app would go a long way.

Try http://blog.springsource.com/2011/01/04/green-beans-getting-...

"It is DI, adapters for vendor-specific libraries and utility. It's probably not the easiest thing to start with just because it is so flexible that it can be hard to know where to start. A good "Hello World" Spring MVC 3.1 app would go a long way."

Spring is OK in the service and DAO layers. I prefer Stripes on the web layer. Stripes IMO has a far more sensible approach to laying out the web layer (e.g. combining controller and backing object, fewer configurations, more sensible tag system, etc.).

http://stripesframework.org/display/stripes/Home

Wicket, a thousand times wicket. It's so good it makes programming in java worthwhile. Its templating, if you can even call it that, is a quantum leap ahead of everything else: it's actually object oriented, you can write self-contained reusable components in the way you expect, and you get the full benefits of strong typing at every point. I really wish there was something like it for python, but everyone seems to think templates are good enough.

What about something like Flask-HTMLBuilder?

http://majorz.github.com/flask-htmlbuilder/

That's not the worst idea in the world, but it looks like it expects your python code to walk the whole html tree, and it's very much mingling of logic and markup. The great thing about wicket (well, one of many) is that your markup is inert html files, and you can put reams of static content in if you want, without cluttering up the actual code. Your component hierarchy has to match your html hierarchy, but not every tag needs a component; you just need to make sure A is a descendant of B in markup (with no other components in between) whenever A is a child of B in code.

Play! Framework.

I've been using it for over a year and I have to say it's the most "rails like" framework out there for Java.

However they have just released play! 2.0 (which I have not used yet). This makes some major changes to the framework and it's not all backward compatible.

I does have a heavy emphasis on Scala now, but you can still code everything using Standard Java if you want, although it does somewhat butcher Java "best practices".

it's default ORM is JPA/Hibernate which works well enough as it gives you a ton of helper functions, it even automatically creates getter/setter method at runtime allowing you to do C# Style properties simply by declaring entity members as public.

I'm writing an AJAX webapp using Dropwizard, and seems that I won't be hitting any roadblocks anymore. The devs are very helpful on the google groups as well.

http://www.hybridserverpages.com/ Just two days learning curve.

I really don't think it's worth taking this guy seriously. First he writes a worthless and inaccurate lambast of PHP, and now he's trying to "convert" people to Python by telling us Unicode sucks. Get a life.

> ... by telling us Unicode sucks.

Could you tell us where he did this?

(I didn't notice it on the first time through; he did say to use Unicode everywhere inside your code, though, and to not do anything rude like converting Unicode to ASCII by stripping non-latin1 characters.)

Right under the big bold "Unicode" header. The very next line is

> Unicode sucks. This is a universal truth.

(In fairness, I think what he's really getting at is that dealing with Unicode in languages that were created before it became ubiquitous sucks, not Unicode itself. But if you start off your discussion of Unicode with the statement that "Unicode sucks", you shouldn't be surprised if people think your beef is with Unicode rather than with the tools we use to deal with it.)

Point. Mind you, he follows that with:

"(I’m lying. Dealing with encodings sucks. Unicode is great. It’s complicated. I’ll write about it later.)"

I think I'll wait for the follow-up article.

Who am I trying to convert? The article answers the question asked in the beginning—a question I've been asked several times since writing the PHP article.

Good article apart from one thing - avoid the hell out of session state. This becomes the dumping ground for all sorts of crap and will slowly knacker your app. You should only persist enough information to identify the user between requests and keep the rest stateless. We do that using encrypted cookies containing the user id, display name and correlation id.

I've just spent 6 months entirely removing session state from an asp.net app and the performance gain is amazing.

Great article! For those of you who say how easy PHP is, it's because you don't remember the early days when you had to compile php to run on your box, only to watch it fail after an hour of compilation :) history aside, these are just tools. For many site, perhaps for majority of tasks, PHP might be the best tool for the job. Once you start doing more complex stuff that will require additional libraries and modules then you need to look into other languages.

I used servlets from very early days, just because I could never understand another man's perl code and I thought the architecture was better. However J2EE got so big and academic that took all the fun out of coding. I've recently started to do some stuff in python and the fun is back again. I love all the NLP libs that are available for python in addition to vast support and ease of coding. Not to mention, I like the python community more than ruby (rails really). It just seems like python guys come from a stronger CS background and are not some over-night rail guys who want to push their faith down your throat.

By far the easiest way to get started with Python web development is Web2py which comes as a self-contained install where you can get started in 5 minutes. So you automatically get "request" information, big deal.

Flask comes as a self-contained install where you can get started in 5 minutes.

But Flask is a micro framework while web2py is a full stack framework. Comparing apples to oranges IMHO.

Flask doesn't help much with the database.

I've seen Flask mentioned here few times. Is Flask better than Bottle?

In my humble opinion.. Yes. I feel bottle sacrifices just a little too much for the sake of being a single file distribution. The lack of any (mainstream) templating engine might hinder newcomers, and Flask uses one of the best python templating engines around. I also find Flask's documentation to be more extensive and better laid out. Overall I would recommend Flask if you want to write a full featured website, Bottle if you are looking to write some kind of API layer, or similarly bear bones functionality, and will not require many "batteries included".

You can use Jinja2 with Bottle:

> pip install Jinja2

from bottle import jinja2_template as template

In python, stay away from default arguments for methods/functions.

EDIT: yes, mutable default values:

http://effbot.org/zone/default-values.htm

Do you mean don't use defaults that contain mutable values?

What's wrong with mysql?

Apparently, it isn't PostgreSQL; If you have no need for Postgres features and you're not familiar with it, sticking to MySQL is fine.

Well you can say the same for windows vs Linux or visual basic vs any other language, and you can also continue using paper glue to attach paintings on the wall.

It is not a matter of what you need, it is a matter of using good tools that will help you do good work, understand better what you do, build durable products, and so on.

Just one example: MySQL will not complain if you add a check constraint but will not actually add it to your schema. That's a very Microsoft-y way to handle things, and should give cold sweat to any coder.

This is actually documented behavior: "The CHECK clause is parsed but ignored by all storage engines." From: http://dev.mysql.com/doc/refman/5.5/en/create-table.html

I believe it was left to support certain migrations(?). You can create a trigger instead.

I'm pretty certain many people will consider MySQL a good tool with which they produce good work. While it may have its quirks, it's present on virtually all shared hosting environments, just like PHP, so it's very easy to create and deploy an application powered by both these technologies.

So, you are telling me that it is a good thing, a normal behavior for a reliable tool to just ignore instructions I send to it and do nothing with it, not even a warning? So when I migrate a database, I have to carefully check each and every instructions (schema and data) and make sure MySQL did not "decide" it was not worth it and just silently threw it by the window?

I have hard time to believe you are serious here...

I'm pretty certain when you migrate from a different database you're supposed to check your schema and data anyway, or do you just "decide" it should work without question?

I'm not saying this MySQL behavior is acceptable, I'm just saying that you should be aware of the limitations and quirks of the tools you work with.

So it's not acceptable behaviour, yet we shouldn't point it because we should know it has this unacceptable behaviour? Doesn't make any sense to me I'm afraid.

MySQL was a lot worse before 2004 or so. It wouldn't do transactions, nor proper joins, if I remember correctly.

I think the bad reputation still sticks to it.

I won't talk for the others but for me the "bad reputation" is not because of missing features, it is because of a wrong handling of ambiguous cases. If you ask a (SQL) question to a database and your question is ill-formed, ambiguous, or meaningless, it is very dangerous for the database engine to try to guess your meaning and answer something.

There are enough troubles with SQL (eg the Null debate) to add up to the mess by adding guesses.

Honestly, as others pointed out, the multitude of sins of omissions that MySQL has performed over the years. For example, its silently ignoring the foreign key constraints on certain database engines, such as MyISAM. On top of that, the repeated and continuing promises of actually implementing features like foreign keys in many of their database engines, including their high-performance NDB engine, means that the programmer has to do a lot more bookkeeping work on things that are built in on more rational databases.

The multiple database engine mess leads to its own problems compared to engines like postgresql. Do you use the InnoDB engine, and rely on third-party products, like galera, for clustering, or do you use NDB and suffer its weaknesses in referential integrity, and difficulty in configuration?

Finally, you get into issues where MySQL isn't nearly as featureful as PostgreSQL. For example, PostgreSQL supports a multitude of languages for creating server-side procedural functions -- pgsql, perl, python, tcl, etc, whereas MySQL only supports C, and only pre-compiled functions. This limits the utility, and leads to these quite useful features being left by the wayside because numerous coders were weaned on a database that didn't support doing these nice things for them.

While mysql does have certain uses, I'd argue severely that postgresql is a much better designed foundation for working on new projects. The attention to detail, the emphasis on not eating your data, and the level of features means that you can spend more time coding, and in the language you want to use, and less time fiddling with your database software.

off-topic: love the greek-lettered ordered list.

Should I really learn Pyramid instead of Django? I'm thinking about what would give me most value as a developer, one who already knows his python.

It's a tradeoff. Django is a full-stack framework, which integrates lots of components such as templates, form generation, and an ORM. This means that you can get off the ground quicker, and that the community is all more or less on the same page. The downside is that if you want to do something that Django isn't good at (complicated database stuff, logic in templates, etc), you are in for a world of pain (reportedly). Overall, Django is a great default for making CMS-type sites, but can become a technical debt if your requirements outgrow it.

Pyramid, on the other hand, deliberately not a full stack framework, sacrificing ease-of-use for flexibility. It doesn't include any database opinions at all, can swap templating languages on a whim and wouldn't know a form if you hit it over the head with one. The upside is that it has first class core components, really well defined extension points, an unmatched routing system, and a few truly excellent plugins (I love you pyramid_tm). The downside, of course, is that you will own your entire stack, which means that A) there is more up-front work researching, designing, and developing your application's component stack and B) there's no central community guaranteed to be using the same stack as you. Overall, pyramid is suited for essentially any use case, so long as you put the work into it.

tldr: Django is (somewhat) inflexible but easy, Pyramid is flexible but more demanding. Both are excellent.

There are probably more jobs working with Django, if that's a consideration.

Google App Engine for Python. You don't have to configure your host, you get great tooling and documentation, and a very good community of users.

Its funny how Ruby hordes overwhelms this thread talking about ruby not python nor php :-D

> Some have helpers for creating RESTful routes

Can somebody point to an example of this?

Great overview.

Say wat you want of php. But it's (insert personal pejorative option) made for it.

Sure Its a_little_inconsistent AndSomewhatChaotic

But all the basics for the web are incredible accessible right away.

With every other language you have to start with a framework.

I find php easier than rails to prototype applications and do fast hacks that need a web face.

It's simply the right tool for the job on those occasions. Of course, later they become huge systems...

That's why e.g. Flask exists: it gives you the basics, plus light structure and templating and routing and XSS protection and deployment options and whatever else. With no setup and no boilerplate.

It's about as much effort as typing `<?php`.

While that's true (and I do love Flask), PHP comes installed on every discount web host. Deploying a PHP app is as easy as using FTP, deploying a Python app can be -- but doesn't have to be -- complex. I'd say this is the bigger sticking point than the framework.

Obviously Heroku and other PAAS providers are changing the game as far as deployment ease. It should be to see what happens in the next few years on that front.

Deploying a PHP app is as easy as using FTP, deploying a Python app can be -- but doesn't have to be -- complex.

Easy != Simple && Easy != Good

See "Simple Made Easy" (http://www.infoq.com/presentations/Simple-Made-Easy).

It's a chicken-and-egg problem. Best I can do is encourage more people to write more Python software, so those crappy free hosts are more inclined to support running it.

Until then, I don't think it's terribly unreasonable to pay twenty bucks a month for a server to play with. That's less than AT&T wants to charge me for sending a thousand 160-byte messages.

"crappy free hosts" ?

Don't mess with "crappy free hosts" -- just run it on a free Heroku dyno (http://www.heroku.com/pricing). Kenneth (http://kennethreitz.com) shows you can get good performance with Flask on the free dyno (http://flask.pocoo.org/mailinglist/archive/2012/2/22/flask-o...).

That's a fair bit more involved than "FTP files to my web host and they usually just work"

It's actually easier...

  $ git push heroku master

Sure, well I would hope it's easy to do a one line deploy to any platform and with any language... once you set it up. You left out freezing requirements for pip, setting up cedar, etc. Nothing like that for a simple PHP app.

I don't want to overstate the case; deploying Flask isn't hard, but deploying PHP is stupidly easy.

As a Mercurial user who doesn't feel like learning git just for the sake of deploying toy Python apps, can anyone comment on whether hg-git or the like is a reasonable way of deploying to heroku?

It would add a bit of overhead, but you can certainly have mercurial at the center of your workflow via gh-git, yes.

Of course, this assumes you are using Git in the first place, or are willing to learn it. Most folks already have FTP/ssh down pat, so git is a big jump from just copying files.

That is obviously not sufficent. For using PHP I literally have to tell people to open an ftp GUI client and drag+drop a folder, or do something like:

    sftp -r website user@host:

So, what is the full "this is how you use heroku" I can send to a windows user, who knows HTML and wants to just get started with 'hello world'.

See the Heroku Quickstart: https://devcenter.heroku.com/articles/quickstart

Essentially you sign up for a Heroku account (https://api.heroku.com/signup), and set up the Heroku "toolbelt" (https://toolbelt.heroku.com).

Once that's done, you can run this bash script (https://gist.github.com/2622850) to create and deploy a "hello world" Flask app on Heroku:

  $ heroku login
  $ bash setup.sh helloworld
  $ cd helloworld
  $ git push heroku master

It should return a live Web URL for your app:

  http://strong-stream-5848.herokuapp.com deployed to Heroku

See the Heroku Python tutorial (https://devcenter.heroku.com/articles/python) for details.

Compared to deploying Hello World in PHP, that's a lot of work.

I guess that's true, but you know... so what? Can't we worry more about building something cool than about shaving seconds off the one-time setup cost involved with sharing that cool thing with the world?

And compared to putting down the window in my car, turning on the AC is a lot of work. Two buttons and a dial compared to just one button.

One is clearly superior to the other though and anyone going near a car should have zero difficulty with either...

You can't have 'git' and 'easier' on the same phrase

Or maybe you can: Hg is easier than Git

Now, I don't hate git, I love git, but you're seriously overestimating the knowledge of most of the programmers.

Git for lots of people feels like being thrown in a plane cockpit and asked to fly the darn thing.

And this is seriously something Heroku needs to think about. Sure, for now, it's still mostly early adopters.

But I really wouldn't like to tie my production servers to a specific VCS.

Compare this with drag-and-drop of php files to their ftp server.

There is also Google App Engine, the free tier is fairly generous as well.

That's a nice sentiment that's completely inaccurate. Even 6 years ago when I first started programming Python, simple Python cgi scripts were very easy to write. It's as simple as:

  print """\
  Content-type: text/html
  
  <html>...</html>"""

With %(var)s interpolation, you can even slap in locals() easily to trivially put variables' values into the page.

That doesn't seem like it will scale very well at all. Or am I missing something?

PHP doesn't scale well either. You can rewrite for scaling later.

and you think that manually handling headers is more straightforward than php? I disagree.

"Manually handling headers"? That is how people wrote websites in the early 2000s. Many cgi scripts were cobbled together in Perl. I found that I liked Python better.

I understand that in PHP you just add some <?php ...> stuff to an otherwise normal HTML file, but the situation in Python, with its multiline strings that support variable interpolation, isn't much worse. Just add the lines I mentioned to the top (treat is as a recipe if you like), and the rest is better than PHP.

"I only know PHP"

"I just trashed PHP rather harshly"

"I want to learn python"

Well, you're doing it wrong. How can you trash PHP if you know no other languages ?!

You're following articles, posts saying PHP is bad and.. you decide then that's right it's bad!

Ever though about thinking on your own first? Like, actually trying a language (python, why not) then deciding if it's better?

This kind of stuff always amaze me. You know, sheepish.

This is part of an FAQ series. The bolded part ("I only know PHP...") is the question I'm answering.

I'll leave you to contemplate the irony here.

Reply on news.ycombinator.com