views:

1781

answers:

13

If you had switched from php + (framework of choice) to python + (framework of choice) as your development platform, what would you say have been the upsides/gains of the switch?

What I want to know is if there were any significant improvements in the following aspects:

  • Speed of development
  • Maintainability of the finished solutions

That can be attributed to the platform switch per se.

I would also like to hear the "not so great" stories.

Please also include the frameworks you have switched from and to.

Thanks

+2  A: 

I think learning Python is worth the trouble. I spend one evening with docs and then was able to write simple programs.

I use python to many things and found web framework: web2py both easy and powerful. It has nice documentation (book & slides), working examples and if you have problem then dedicated google group will help you in minutes. I think you should first try Python and then if it's way of writing programms will be good for you then you can try one of its web frameworks. I mentioned web2py, but there are more with django most recognized.

Michał Niklas
+4  A: 

PHP is based on Perl. The idea of Perl code is that it's easy to write something and then write it again from scratch if you need something similar again -- because it's so easy to write and so hard to understand how you did it last time (Note: This only applies when you write Perl once in a while instead of "on a daily basis". See this example).

Python is based on the idea that code should be readable but unlike COBOL, Guido knew how to achieve that:

  1. Never fail to keep your aim on the goal

  2. Ask lots of people for their input and then ignore them consciously

PHP web frameworks try to wrap existing concepts in Perl so you can use them. They don't try to be "ground breaking".

Python web frameworks try to make writing web apps as simple as possible (for example, TurboGears comes with a built-in development server which can reload the code as you save it without you having to restart the server all the time to test your changes).

Ruby tries the same but IMHO, the Ruby syntax is not on par with Python.

Aaron Digulla
I really honestly don't think PHP was based around Perl for any reason other than it's all the language designers knew. I just don't see PHP as having any kind of style. I think Alan Kay would call PHP an "agglutinative language".
Jason Baker
The irony is that Rasmus will tell you that PHP isn't based on Perl, despite the PHP manual saying it is. We had a... discussion... about this on Slashdot before.
R. Bemrose
I agree with your last sentence (about Ruby's syntax), and I'm quite sure Python benefited from "[asking] lots of people for their input and then ignore them consciously". Ruby's syntax seems to.. run after shiney things a lot, implementing interesting ideas without enough discussion. I think the best example of this is the optional parens when calling a function, while it does make for pretty code, there are cases where it's ambiguous, so you get a warning saying "parenthesize argument(s) for future version" (ruby-forum.com/topic/63233 discusses this)
dbr
+26  A: 

I've done the switch a few years back. And I don't regret the switch in the least. At the time, I wasn't a big fan of frameworks. So I won't comment on this part. I'll keep it to the language itself.

Python's advantages

The code you write tends to be very clean and readable (it's very consistent). Code readability is - IMHO - strongly tied to maintainability as well. So that's a big plus. Obviously, you can also write mediocre code in python. But it's much harder as in PHP.

Another huge advantage over PHP is it's handling of multibyte strings (f. ex. unicode). This is handled magnificently in Python, whereas it can easily give you major headaches in PHP (try substr on a multibyte string in PHP while splitting at the position of the mb-character).

In Python everything is an object. This gives you awesome flexibility. Want to subclass an int? No problem!

Next to that, the data structures you get in python (lists, tuples, dictionaries, sets, ...) are really useful as well. Get to know them early, it will simplify your code! Also, the standard library is really nice. It's got a lot of useful stuff in there.

Blocks are defined by indentation..... once you get used to it, it's awesome! TIP: It might be an indication that you need refactoring if you start having trouble following the level of indentation (your method might have become too large or the nesting depth is too deep).

Python can also be used for other tasks as web-pages (GUIs, SOAs, Console apps). yes, you could also write GTK apps in PHP, or console applications. But that was never the main purpose of PHP. So it's support in that regard is flaky. This means, when learning python you have a truly universal tool at hand.

Python's disadvantages

Python is not as widely used as PHP. So it's not as easy to find hosting solutions. Also, the community is much smaller. At the same time, from a corporate perspective, it's harder to find Python developers. However: The bulk of Python can be learned in an afetrnoon. So it's easy and cheap to train new developers! Getting to know the frameworks and the standard library may take some while though.

For the same reason, there is less (developed) support in development tools for Python as there is for PHP. So you may see Python addons for popular IDEs, but they are less polished as they are for other languages. Do not take my word on this however, as I tend not to use IDEs anyway. Tried many of them, always fell back to my trusty vim.

There are no Interfaces in (pure) Python. Only classes. Multiple inheritance instead? I don't like it too much. It's risky if not used properly. Having said that, zope.interface provides this support (as mentioned by Kevin Horn).

Some interesting links for python web development

In order of personal preference ;)

  1. TurboGears
  2. CherryPy
  3. Pylons
  4. Django
  5. Twisted
exhuma
Yes, I know.... My section about disadvantages is very short, but after a few minutes spent on searching for some (as compared to PHP), I gave up.
exhuma
I don't know that it's a fair point that Python's community is much smaller. Even though that may be true, Python's community is still *huge*.
Jason Baker
Wow, no Django?
Josh Smeaton
@Jason: I agree that there is a large community for Python. But - for the sake of comparison - I still believe it's a fair point to mention. @Josh: omg. I totally forgot.... fixed it! And yes, there are others. But the ones (now) on the list are the ones I've worked with. So I'm not qualified to vouch for others, so I won't list them.
exhuma
While it's true that interfaces are not built into the Python language, zope.interface is great if you really need interface support.
Kevin Horn
You don't really use interfaces in python, you just use duck typing or just inherit of a abstract class.
UK-AL
@UK-AL: This is true. But in my opinion this lacks a bit of expressiveness. Don't get me wrong, duck-typing is great! But as so many things in Python it requires a lot more discipline as it's kind of "invisible". For someone switching from another language, this might bite at first. I probably shouldn't have put it under the section "disadvantages".
exhuma
+6  A: 

I think the answer is "it depends". I think that making a decision such as changing programming languages on an existing project should be taken with caution. Before anyone accuses me of loving PHP, I want to say that I'm saying the following as a die-hard Python programmer. I'm just trying to play "devil's advocate" if you will.

For all its flaws, PHP is still a viable platform for web development. It is much easier to get up and running with PHP because deploying scripts is a simple matter of FTPing them to the server.

Python, on the other hand, takes a bit more work in terms of deployment. You need to bundle your code up as an egg (which can be somewhat difficult for an inexperienced Python programmer).

Therefore, expect an initial drop in productivity when switching to Python. Of course, this will be a much smoother experience if you can find an experienced Python programmer (I find that someone who is experienced with a lot of different deployment systems is worth their weight in gold).

That said, while making the move to Python is definitely stupid in the context of any short-term goals, you won't regret it in the long term. Python's packaging is a pain because it is more versatile than PHP's. Plus, the language just doesn't have as much legacy cruft as PHP does.

Lastly, the key thing that makes Python great isn't the language itself. It's the standard library. Python's standard library is huge and there are a lot of libraries out there for various aspects of web programming from full-fledged "heavy" frameworks (like Django) down to the more simple, low-level libraries (like Werkzeug).

Jason Baker
+1  A: 

I moved to Django and I am so done with PHP. I won't even take projects in PHP anymore.

The only problem I've encountered is the lack of a well integrated IDE debugging solution. PHP has Zend which I do think makes things a little easier in terms of debugging out of the box.

Adam Nelson
Komodo Edit is free and can be hooked up to run as a debugger.
Tom
A: 

PHP has lots of problems like 0 == 'a' which appears obvious (the PHP mollahs will scream "use === !!!" at you) but in fact is far from obvious, as in practice, it is difficult to distinguish between null, '', 0, 0.0, and sometimes everything else, which leads to an endless stream of very subtle and very contagious bugs. Where in your form library did the null get transformed into '' ? How come your default values don't default anymore ? What is the difference between an empty text field and an unsibmitted field ? So you dromn under a steaming pile of '===' and is_null() and array_key_exists(), whereas Python gives you "is None", and "if x in ...".

PHP gets the basics wrong, by trying to be simple, it becomes too simple, and it ends up biting your ass. Where Python will throw an exception and tell you "Fix your code !", PHP will carefully and lovingly nurture your bugs, hiding them in a secret place, saving them for the worst possible moment, when it will smash them into your face, and you won't know what hit you, since there so many foot-guns pointing at you from all directions.

The biggest problem I had with PHP though, is the broken object model. When you want to write an ORM framework which automatically generate admin interfaces and forms (kind of like Rails), you need a good object model like Python has. However, in PHP, classes are not first class, functions are not first class, you have no closures, nothing to help you. If you want to pass a bit of code, you got to put it in a class, which sucks, when you just want to pass a validator which says "lambda x: 1 <= x <10", or "lambda fields: fields.start_date <= fields.end_date".

So, in PHP,

if class BlogPost derives from class DBObject,

and you call a static method BlogPost::displayCreationForm( ), because you want a form to create an object of class BlogPost.

However, in a normal framework, BlogPost::displayCreationForm( ) is not overriden, it is only defined in the base class : DBObject::displayCreationForm(), which calls BlogPost::getFieldList() to know exactly which fields it should put in the said form.

However, since the object model doesn't work, a static method from DBObject cannot call a static method from BlogPost. Worse, if a static method from BlogPost calls a static method from DBObjectA, this method cannot call a static method from BlogPost. You have gone backwards in the class hierarchy and cannot go back.

So, displayCreationForm() will call getFieldsList() and get the fields from DBObject, not BlogPost. Since DBObject is a generic class it has no fields. Bummer.

Now you want to call :

$post = BlogPost::getFromDatabase( $id )

No, cannot do. getTable() can't be static, you're fucked, you need to do :

$tmp = (new BlogPost); $post = $tmp->getFromDatabase( $id )

Note that the returned object can be another class than BlogPost, it can be an ImageGallery or whatever, since the information about the class is encoded in the database and it's desired that a CategoryPage has children of type ImageGallery and BlogPost and whatnot.

Result : YOU CANNOT USE STATIC METHODS. You got to instantiate dummy objects and call regular methods.

Result : my framework is littered with "$tmp = new $classname", all over the place.

It was a complete pain to write. I stopped adding features when the lack of closures became unbearable. How do I control the formatting for a specific field in the autogenerated admin ? Create yet another class ? Bleh.

In Python, it works.

peufeu
"So, displayCreationForm() will call getFieldsList() and get the fields from DBObject, not BlogPost. Since DBObject is a generic class it has no fields. Bummer." I'm surprised this works at all. Static fields belong to the class itself, and non-static fields cannot be accessed through static methods. Static methods aren't inherited, because (again), static fields belong to the class, not instances of the class.
R. Bemrose
-1 for posting a subjective rant about one of the two options (be it PHP or Python) which is hardly a constructive answer.
exhuma
PHP 5.3 has late static binding, so yes you can use static methods
Simon
+2  A: 

If you are already using an existing PHP framework, it means your code is more or less organized. From that point, I don't really see any point in switching to Python if your site is generating revenue.

However, if you hate maintaining the well organized PHP code on a daily basis, you could give Python a try. Work out a small web app in Python and one of the many framework out there(I recommend Django but the choice is yours). Keep working on the small project for a few weeks to get a general feel of it. After a month, revisit your PHP and Python projects and stick with the one that you have more fun with and makes you keep coming back to it.

Thierry Lam
+1  A: 

The development itself changes when you switch from PHP to Python. I did that myself a year ago and the first thing, which became obvious, is that you get rid of one pretty common problem in PHP Apps: SQL Injections. The Database is wrapped by a Class and you only call those methods, which do all the escaping for you, unless you manually tell it not to. (A Step I'd like to see for PHP6)

Then when you move to another level and use some Framework, you notice that the way you work needs to change. I was used to write code from top to down roughly, then fine-tune, then fine-tune again. In Python I more or less get it in one go, as the function part for common renderings is more or less 30 lines of code if you do some data verification, querying multiple sources and whatnot. Otherwise it'll be a two liner. And there's more. If your app is some wsgi app, adding a profiler is just 2 lines of code

app = myapplication()
from flickzeug.profiler import Profiler
app = Profiler(app)

and you're set. you get nice profiling files. Same exists for reloaders, caching layers and whatnot.

And the last thing I started to love is true Database abstraction. Most systems either have their own layer (Django comes to mind) or simply use SQLAlchemy. You define your class, add a table, tell it to map it together and from that on, unless really needed, you don't ever write a single line of sql again. Something PHP doesn't yet have, sadly.

After all the shiny parts, there are also some counterparts... Whether it is really bad or not, is debatable.

You really have to know your tools there. Simply hacking two lines of code to get a view done is some kind of no-go in most cases. So all the really simple things like "I just want a printout of all rows" already require some kind of knowledge about database layering or orm. You learn to do stuff properly and don't do 4 minute "hack-style" scripts, which sometimes take a bit more time but turn out to be more useful in the end.

So personally I don't regret the step but I can see that you feel a bit lost if you start with it from zero without someone who can give introductional advice what's important and what's not.

Jokey
PHP has `Zend::DB` which "feels" similar to SQLAlchemy.
exhuma
Not really... in alchemy you don't write a single line of sql unless you really want to optimize to death ;)
Jokey
A: 

These days I'm doing a careful switch from PHP to Django myself, finding more and more about coding and MVC structures, thinking more and more "the Python way".

While PHP served me in the best way so far, I find supplies better tools to get from concept to a real build.

konzepz
A: 

With reference to Adam Nelson's reply about a lack of an integrated IDE debugging solution for Django.

FWIW a recent post on apps supporting Django-Mingus recommends Django-debug-toolbar.

Description: A configurable set of panels that display various debug information about the current request/response.

Notes: A must have for every Django application. Rob Hudson the the contributors have done an amazing job. There's a reason this is the #2 followed Django application on gitub. It's terrific for debugging your DB queries, templates, etc. And now it comes with a slick new UI in the 0.8 version. Great app. Just fire up Mingus via runserver to see it in action. Make sure to view the Django-Debug-Toolbar screencast to get a quick introduction.

Hope this helps.

Adrian
+1  A: 

I started with PHP, learned a few other languages, then met and fell in love with Python. There are plenty of other answers already on this page, but I would make one comment: regardless of whether it's worth switching, it's always worth learning other languages to see different ways things can be done and different ways to think about problems. Python/ Ruby is a good choice of "Other" language because they're both great steps on the way to a truly Functional Programming language, which will further expand your horizons.

Tom
+1  A: 

I'm currently involved in a switch from PHP to Python. So far, it's been slow going. We chose to use 2.6, but, with REL5, upgrades from 2.4 has been painful. Luckily, however, we weren't in to deep with PHP. I think overall it's just been the adjustment for my fellow developers... you start thinking in terms of PHP and then BAM! you're hunting for right syntax for another language; it can get a little frustrating at times.

John Giotta
A: 

Result : YOU CANNOT USE STATIC METHODS. You got to instantiate dummy objects and call regular methods.

Have you ever tried class::getInstance()->func()? You don't have to write that in two lines if you can do it in just one.

http://en.wikipedia.org/wiki/Singleton%5Fpattern

riyuk