Ask HN: Anyone went from PHP to Python?
I'm considering learning Python (coming from a C/C++ and PHP background). Did anyone else go through that process? Could you share your experience? Which is your preferred language for web development at the moment?
13 comments
I've made the switch from PHP to Python and don't really want to look back. Python is generally much better thought out from an object oriented perspective.
Package and module imports are a lot saner in Python. I'm glad I'm no longer messing with require_once, autoloaders, and all sorts of functions polluting the global namespace.
Python having first class functions and classes makes a whole lot more sense to me. PHP's call_user_func_array and passing around string names of classes and functions for callbacks is just so ugly.
In terms of web framework experience I was using Symfony in PHP and switched to Django for Python. I liked both, but I've found that Django is easier to use. I'm not a big fan of Django's templating language though compared to Symfony (which was just straight PHP).
Package and module imports are a lot saner in Python. I'm glad I'm no longer messing with require_once, autoloaders, and all sorts of functions polluting the global namespace.
Python having first class functions and classes makes a whole lot more sense to me. PHP's call_user_func_array and passing around string names of classes and functions for callbacks is just so ugly.
In terms of web framework experience I was using Symfony in PHP and switched to Django for Python. I liked both, but I've found that Django is easier to use. I'm not a big fan of Django's templating language though compared to Symfony (which was just straight PHP).
PHP is, essentially, a souped up templating language, so I'm really not surprised you prefer it.
Django's templates aren't bad though, even if a little awkward at times.
Django's templates aren't bad though, even if a little awkward at times.
Indeed. It just seemed a little restrictive not to be able to use some basic Python operators from within a template. Why invent a separate awkward syntax when Python itself is perfectly suitable?
The idea was so that a web designer who didn't know any programming could easily edit it.
Interesting. I wonder how well that has worked out in practice.
Seems to me like any designer smart enough to get comfortable with Django's templating language probably wouldn't have any trouble getting comfortable with Python itself!
It's not like you'd ever do anything particularly complicated (programming wise) from within your templates anyway.
Seems to me like any designer smart enough to get comfortable with Django's templating language probably wouldn't have any trouble getting comfortable with Python itself!
It's not like you'd ever do anything particularly complicated (programming wise) from within your templates anyway.
There are some very neat fixes to the more glaring issues with Djangos templating language, for instance the if statement.
edit: more digging:
http://www.djangosnippets.org/snippets/1350/
edit: more digging:
http://www.djangosnippets.org/snippets/1350/
if's been upgraded in 1.2 to be significantly more useful:
http://docs.djangoproject.com/en/dev/releases/1.2-alpha-1/#s...
http://docs.djangoproject.com/en/dev/releases/1.2-alpha-1/#s...
I did.
Python is a great little language but even after multiple thousands of lines it still looks like the guardrails on the highway are missing, I never knew I was so addicted to curly braces.
I also find it very hard to switch from the one to the other and back again after sticking to one of the two for a while.
My 'preferred' language/framework for more complicated stuff actually does not seem to exist. I can list a whole series of problems with just about any development stack out there at the moment, at least the ones that I've used.
For quick and dirty stuff (throwaway sites or quick tests or prototypes) I still prefer PHP, but mostly because I can rely on a framework that I wrote years ago that makes it very easy to throw something together. It's far from perfect but it's the devil that I know best.
I've made three sites in python/django, it works but the ORM is very limiting and I keep hearing that forms are hell (but I rolled my own forms, so that wasn't a big deal).
I wished there was a clear winner amongst all these technologies, everybody seems to have built just enough to satisfy their particular itch.
Next on the list of stuff to try is werkzeug, another python framework.
Python is a great little language but even after multiple thousands of lines it still looks like the guardrails on the highway are missing, I never knew I was so addicted to curly braces.
I also find it very hard to switch from the one to the other and back again after sticking to one of the two for a while.
My 'preferred' language/framework for more complicated stuff actually does not seem to exist. I can list a whole series of problems with just about any development stack out there at the moment, at least the ones that I've used.
For quick and dirty stuff (throwaway sites or quick tests or prototypes) I still prefer PHP, but mostly because I can rely on a framework that I wrote years ago that makes it very easy to throw something together. It's far from perfect but it's the devil that I know best.
I've made three sites in python/django, it works but the ORM is very limiting and I keep hearing that forms are hell (but I rolled my own forms, so that wasn't a big deal).
I wished there was a clear winner amongst all these technologies, everybody seems to have built just enough to satisfy their particular itch.
Next on the list of stuff to try is werkzeug, another python framework.
> I've made three sites in python/django, it works but the ORM is very limiting and I keep hearing that forms are hell (but I rolled my own forms, so that wasn't a big deal).
Huh. That's not been my experience at all. I guess if you're trying to build full-strength webapps that might be the case, but we've built a decent number of fairly complex user-content-managed type sites, and Django has not caused any trouble at all. Very occasionally we step out of the ORM (usually in places we should be stepping out of RDMS in general, anyway, like tracking ad-clicks). (The ORM does now support aggregation, too - SUM(), AVG(), ad-hoc calculations etc.)
And the Forms lib is great if you're happy with default html-generation (it can do paras or tables); things get kinda fiddly when you're trying to customise layout and appearance, but it's still nice having validation, saving to the db etc. all in one place.
Huh. That's not been my experience at all. I guess if you're trying to build full-strength webapps that might be the case, but we've built a decent number of fairly complex user-content-managed type sites, and Django has not caused any trouble at all. Very occasionally we step out of the ORM (usually in places we should be stepping out of RDMS in general, anyway, like tracking ad-clicks). (The ORM does now support aggregation, too - SUM(), AVG(), ad-hoc calculations etc.)
And the Forms lib is great if you're happy with default html-generation (it can do paras or tables); things get kinda fiddly when you're trying to customise layout and appearance, but it's still nice having validation, saving to the db etc. all in one place.
A complex query is one that hits several tables in several databases on more than one server.
You can simply forget that using django, you'll have to export all the stuff you want to query in a format that exactly matches Djangos field name magic.
And better not get any of that wrong or you'll be tearing your hair out, an underscore in the wrong spot and it will look just fine but it will never work and the error messages you'll get are much less than helpful.
Here is a comment from the models.py file in one of my little django applications:
You can simply forget that using django, you'll have to export all the stuff you want to query in a format that exactly matches Djangos field name magic.
And better not get any of that wrong or you'll be tearing your hair out, an underscore in the wrong spot and it will look just fine but it will never work and the error messages you'll get are much less than helpful.
Here is a comment from the models.py file in one of my little django applications:
# caveat, the related_name parameters of parent and thread
# should not be parent_id or thread_id, this leads to
# an 'add() argument after * must be a sequence' error
# when transforming the template. Apparently the names
# clash with the underlying field names that django
# uses for these fields.
Okay, I see. In that case, you're being tripped up by the fact that `parent = ForeignKey(OtherModel)` actually creates a database field `parent_id`; parent just becomes a synthetic property. AFAIK foreign keys and "_id" is the only place that happens. On the whole though, I think you're exaggerating the "field name magic". Double-underscores in field names would be a bigger problem, but python considers those special anyhow.
And sure, cross-database and cross-server are weak points for Django. I guess it depends on the scale and complexity of what you're building… I build reasonably conventional websites for a living, and haven't hit too much pain with Django.
And sure, cross-database and cross-server are weak points for Django. I guess it depends on the scale and complexity of what you're building… I build reasonably conventional websites for a living, and haven't hit too much pain with Django.
I've written a HN clone, both in PHP and another one in Django, they look and function exactly the same.
The idea was that both could talk to the same database to check performance, and to get an idea about how much code was required in each to accomplish this.
This would have worked if I had started from python/django, but writing the PHP part first and then the python part got me caught up a couple of times.
Now for me it was no big deal to change the underlying field names, but if this would have been embedded in to something larger a restriction like that could even turn in to a dealbreaker.
What's a minor nuisance to a lone programmer can be a very big issue in a corporate setting, where there might be lots of other software talking to that same db.
In general I think it is a bad idea to resort to tricks like these.
Indeed, the __ is another one, and the fact that you can't prefix field names with database names is another.
The idea was that both could talk to the same database to check performance, and to get an idea about how much code was required in each to accomplish this.
This would have worked if I had started from python/django, but writing the PHP part first and then the python part got me caught up a couple of times.
Now for me it was no big deal to change the underlying field names, but if this would have been embedded in to something larger a restriction like that could even turn in to a dealbreaker.
What's a minor nuisance to a lone programmer can be a very big issue in a corporate setting, where there might be lots of other software talking to that same db.
In general I think it is a bad idea to resort to tricks like these.
Indeed, the __ is another one, and the fact that you can't prefix field names with database names is another.
(sorry, this is way old, but I just saw your response)
you might be interested in the 'db_column' option to Django fields, e.g.
content = models.TextField(db_column='a_different_column_name')
That will allow you to have 'content' on the model, but 'a_different_column_name' in the database. It can be quite helpful for talking to legacy systems.
you might be interested in the 'db_column' option to Django fields, e.g.
content = models.TextField(db_column='a_different_column_name')
That will allow you to have 'content' on the model, but 'a_different_column_name' in the database. It can be quite helpful for talking to legacy systems.
> I keep hearing that forms are hell (but I rolled my own forms, so that wasn't a big deal).
You should try it for yourself and form your own opinion. I've found the declarative nature of the forms in Django to be extremely pleasant. My biggest complaint is the need for writing forms at all!
You should try it for yourself and form your own opinion. I've found the declarative nature of the forms in Django to be extremely pleasant. My biggest complaint is the need for writing forms at all!
I've used it for some simple stuff and that worked ok, but as soon as you get forms with ajax integration, auto lookup and auto-reject of fields based on pre-existing keys things get tricky in a hurry.
So I rolled my own forms, thinking at the time that it must be possible but not knowing how.
Now I hear - from someone in a HN comment - that AJAX and django don't play particularly nice.
Here is the thread, I dug it up:
http://news.ycombinator.com/item?id=1078743
So I rolled my own forms, thinking at the time that it must be possible but not knowing how.
Now I hear - from someone in a HN comment - that AJAX and django don't play particularly nice.
Here is the thread, I dug it up:
http://news.ycombinator.com/item?id=1078743
Forms are IMO, most misunderstood, and underdocumentated feature of Django. A from is not just a representation of a HTML.
A form is,
0. a representation of a HTML form. 1. Knows how to validate and sanitize that data. 2. Know what to do with the data. In my apps, a lot of logic is in forms, (which people generally put in views.)
Its written by me, but I think is explains some interesting ways to use forms which people miss and do the hard way.
http://uswaretech.com/blog/2010/01/doing-things-with-django-...
A form is,
0. a representation of a HTML form. 1. Knows how to validate and sanitize that data. 2. Know what to do with the data. In my apps, a lot of logic is in forms, (which people generally put in views.)
Its written by me, but I think is explains some interesting ways to use forms which people miss and do the hard way.
http://uswaretech.com/blog/2010/01/doing-things-with-django-...
Would you recommend Python/Django over Ruby on Rails (if you have experience with that)?
I've played with ruby on rails very briefly when it was very new, and I was disillusioned with how fast I ran in to the limitations of the framework. I presume that it has come a long long way since then, but I haven't looked at it since.
I probably should.
I probably should.
Thanks for this honest response. By the way, forms are also hell with the Zend Framework IMHO.
It's surprising how hard forms seem to be to get right. Forms in Pylons were terrible too... I've not used other declarative form systems besides this but it seems like a terrible idea in general.
Do anything even slightly complicated (say validations dependent on other field values) and you end up having to extend the framework in truely monstrous ways just to get it to happen. (On a side note, using the validate decorator in Pylons is NEVER the great idea it initially seems to be).
In the end I replaced the form system with my own that let me work procedurally instead of declaratively (without the need to memorise the multi-tiered internal form handling API) but I could still plug into the existing declarative system (no need to re-invent the wheel).
In that regard Rails form handling is a pleasure to work with. Validation is just as easy for simple and complex scenarios. Integration with the ORM is fantastic removing a tonne of manual pain when constructing forms.
Do anything even slightly complicated (say validations dependent on other field values) and you end up having to extend the framework in truely monstrous ways just to get it to happen. (On a side note, using the validate decorator in Pylons is NEVER the great idea it initially seems to be).
In the end I replaced the form system with my own that let me work procedurally instead of declaratively (without the need to memorise the multi-tiered internal form handling API) but I could still plug into the existing declarative system (no need to re-invent the wheel).
In that regard Rails form handling is a pleasure to work with. Validation is just as easy for simple and complex scenarios. Integration with the ORM is fantastic removing a tonne of manual pain when constructing forms.
Is this what you are talking about? Taken from:http://uswaretech.com/blog/2010/01/doing-things-with-django-... higher in this thread.
5.
Prob. You want to create a field which has cross field validations.
Ans. Create a field with a .clean
5.
Prob. You want to create a field which has cross field validations.
Ans. Create a field with a .clean
class UserForm(forms.Form):
username = forms.CharField()
password1 = forms.PasswordField()
password2 = forms.PasswordField()
def clean(self):
data = self.cleaned_data
if "password1" in data and "password2" in data and data["password1"] != data["password2"]:
raise forms.ValudationError("Passwords must be same")[deleted]
I tried to build a solid web platform on PHP and Zend Framework for a few years. It proved very difficult. PHP doesn't provide much structure to build on. On the other hand ZF is overkill and slow with its massive class hierarchies and complex autoloading systems. And ZF's data models are a joke: they're just simple SQL table wrappers.
After moving to Python and Django, everything changed. Now there is a clear, simple structure for every application, defined by the framework itself. There is a good balance between models, views and templates, because Django enforces templates to be simple. There is no weird magic like ZF's autoloading or CodeIgniter's library loading, just basic Python imports.
It's really cool that whether you download a third-party Django app or use your own, you always have the familiar app structure of xxx.models, xxx.views, xxx.forms, xxx.admin and so on. This makes it really easy to understand how any code works.
I did go through a learning curve. First I tried to tweak Django to my own ideas of a good architecture. But slowly I realized that it actually makes sense to follow the conventions to the detail. Especially when you have a team of people that needs to follow the same principles, in order to understand and reuse each other's code.
I also used Python for several years as a shell scripting language before building real websites with it. Looking back, some of the code is pretty horrible and un-pythonic, more resembling Java or PHP, and not using Python's features properly.
So anybody new to Python should expect to go through a period of unlearning their old programming habits. Your code will shrink from the old 10-line-for-loops into 1-liners, you won't write much of your own classes any more, and eventually you'll start metaprogramming with decorators and metaclasses, to get rid of 90% of the remaining (boilerplate) code you thought you needed. :-)
When you reach Zen, you will no longer have to code. Instead you will declare your Django applications as data models, admin definitions, URL mappings, view decorators, HTML templates, and just a few lines of logic in the view functions.
After moving to Python and Django, everything changed. Now there is a clear, simple structure for every application, defined by the framework itself. There is a good balance between models, views and templates, because Django enforces templates to be simple. There is no weird magic like ZF's autoloading or CodeIgniter's library loading, just basic Python imports.
It's really cool that whether you download a third-party Django app or use your own, you always have the familiar app structure of xxx.models, xxx.views, xxx.forms, xxx.admin and so on. This makes it really easy to understand how any code works.
I did go through a learning curve. First I tried to tweak Django to my own ideas of a good architecture. But slowly I realized that it actually makes sense to follow the conventions to the detail. Especially when you have a team of people that needs to follow the same principles, in order to understand and reuse each other's code.
I also used Python for several years as a shell scripting language before building real websites with it. Looking back, some of the code is pretty horrible and un-pythonic, more resembling Java or PHP, and not using Python's features properly.
So anybody new to Python should expect to go through a period of unlearning their old programming habits. Your code will shrink from the old 10-line-for-loops into 1-liners, you won't write much of your own classes any more, and eventually you'll start metaprogramming with decorators and metaclasses, to get rid of 90% of the remaining (boilerplate) code you thought you needed. :-)
When you reach Zen, you will no longer have to code. Instead you will declare your Django applications as data models, admin definitions, URL mappings, view decorators, HTML templates, and just a few lines of logic in the view functions.
If you start using metaclasses its likely more experienced pythonista's will look down their nose at you and say "probably shouldn't have done it that way", largely because they often turn out to be magic for magics sake.
I believe the rule is, if you don't know when to not use metaclasses, you shouldn't be using them at all.
I believe the rule is, if you don't know when to not use metaclasses, you shouldn't be using them at all.
I agree. I think Django's model system is a good example of when metaclasses can help a lot. It's essentially a domain-specific language that overcomes some of Python's limitations, such as remembering the order in which class attributes were defined.
I have noticed that the same sometimes applies to __getattr__ and similar Python features. You easily shoot yourself in the foot unless you are very careful. So all that stuff is best left to carefully debugged and maintained libraries, and out of everyday quickly-written application code.
I have noticed that the same sometimes applies to __getattr__ and similar Python features. You easily shoot yourself in the foot unless you are very careful. So all that stuff is best left to carefully debugged and maintained libraries, and out of everyday quickly-written application code.
The biggest difference that stuck out in switching was the way PHP was effectively like markup language, while Python usually involves its own web server. This can be a difficult transition because instead of thinking in terms of requests to specific files, you have the option to handle all requests however you'd like. It allows for more flexibility, but you usually have a more difficult time with deployment since things like static files are better served with a traditional web server. Likewise, things like different applications need a little more thought than simply uploading a file. That said, there is a wealth of great libraries and the standard library that help not only provide functionality, but help promote better code.
As far as syntax, it's about as easy to pick up as it gets. ( http://diveintopython.org/ )
Web dev wise, it helps if you had some experience with PHP frameworks (though most of them are modeled more on Rails rather than Django or other Python frameworks). Also, the libraries aren't built in as in PHP and documentation isn't as good as PHP's (I'm not aware of any language that has online docs as good as PHP's. Django has great docs, though).
I recommend starting with Google App Engine. It basically takes care of the deployment for you, which is often a sore point in many environments. It's free and includes a basic framework that resembles web.py with bits of Django. In fact it's worth picking up Python even just for the sake of making use of GAE.
Web dev wise, it helps if you had some experience with PHP frameworks (though most of them are modeled more on Rails rather than Django or other Python frameworks). Also, the libraries aren't built in as in PHP and documentation isn't as good as PHP's (I'm not aware of any language that has online docs as good as PHP's. Django has great docs, though).
I recommend starting with Google App Engine. It basically takes care of the deployment for you, which is often a sore point in many environments. It's free and includes a basic framework that resembles web.py with bits of Django. In fact it's worth picking up Python even just for the sake of making use of GAE.
From my experience, going from .NET to Django/Python, the documentation on MSDN was superior.
I hate to say it, but that was what I encountered. The paucity of the documentation on Django is one of my primary irritations with it.
I still strongly recommend checking out Python and Django. Excellent and productive environments.
I hate to say it, but that was what I encountered. The paucity of the documentation on Django is one of my primary irritations with it.
I still strongly recommend checking out Python and Django. Excellent and productive environments.
> in fact, I don't know if any language has online docs that come close to PHP's
MSDN and MSDN Social has some decent doc and comments.
MSDN and MSDN Social has some decent doc and comments.
I'm currently working on a team that switched from PHP to Python+Django for web application development a little over a year ago. Since I've been writing Python code longer than PHP (8 years vs. 6 or so), I can't really speak personally about what the transition is like, but I can tell you about what I've observed and heard from other members of the team.
In general, the Python language and tools tend to steer you in the direction of writing cleaner, better-structured code. Working with Django also gives you access to a lot of decent 3rd-party applications that you can integrate into your project, and the Python stdlib absolutely dominates PHP in terms of scope, quality, and consistency. Having the bytecode compiler and libraries that provide better data structure and algorithm in app servers also opens up the door to a whole bunch of performance optimizations that are difficult to accomplish with PHP.
That's not to say that the Pythonic way is always better, of course. PHP encourages a very iterative approach to development -- at a basic level, you're creating a static page, then incrementally adding dynamic behavior until it does what you need. Python apps tend to put the code front-and-center, and output HTML (or JSON, or XML, or whatever) as a last step in the process. In the long term, that's usually a Good Thing, but it can make the prototyping and learning processes longer for some people.
In general, the Python language and tools tend to steer you in the direction of writing cleaner, better-structured code. Working with Django also gives you access to a lot of decent 3rd-party applications that you can integrate into your project, and the Python stdlib absolutely dominates PHP in terms of scope, quality, and consistency. Having the bytecode compiler and libraries that provide better data structure and algorithm in app servers also opens up the door to a whole bunch of performance optimizations that are difficult to accomplish with PHP.
That's not to say that the Pythonic way is always better, of course. PHP encourages a very iterative approach to development -- at a basic level, you're creating a static page, then incrementally adding dynamic behavior until it does what you need. Python apps tend to put the code front-and-center, and output HTML (or JSON, or XML, or whatever) as a last step in the process. In the long term, that's usually a Good Thing, but it can make the prototyping and learning processes longer for some people.
More of a story than anything. I'm not sure if this is typical for someone going from PHP to Python, but it might give you an idea of what to expect if you end up becoming a Python convert.
I went from PHP-Nuke, to pure PHP, to Python, to handwritten Python site engines, to Google App Engine, and now finally hunkering down and getting Django under my belt, for real this time.
And that's my first tip: GAE makes a great stepping stone to Django (and even includes a sizable chunk of Django).
I have a very bad taste in my mouth from prior experience with Joomla, but I found Drupal to be very easy to use. But once I made the decision to finally learn a real framework, Python and Django made the work... almost trivial. Looking at the code for Drupal modules now makes me wonder why I let myself do all of that extra work that Django doesn't require.
I'm with jacquesm, I still use PHP from time to time for minor things, simply because there are a good amount of hosting providers that don't offer Django. But I think my experience with Python has made me a better PHP programmer. However that works. However I've never really had issues with forms, at least not with GAE, but it IS a little wonky.
I went from PHP-Nuke, to pure PHP, to Python, to handwritten Python site engines, to Google App Engine, and now finally hunkering down and getting Django under my belt, for real this time.
And that's my first tip: GAE makes a great stepping stone to Django (and even includes a sizable chunk of Django).
I have a very bad taste in my mouth from prior experience with Joomla, but I found Drupal to be very easy to use. But once I made the decision to finally learn a real framework, Python and Django made the work... almost trivial. Looking at the code for Drupal modules now makes me wonder why I let myself do all of that extra work that Django doesn't require.
I'm with jacquesm, I still use PHP from time to time for minor things, simply because there are a good amount of hosting providers that don't offer Django. But I think my experience with Python has made me a better PHP programmer. However that works. However I've never really had issues with forms, at least not with GAE, but it IS a little wonky.
self.request.get('form_field_name')I've had some previous exposure to python, but nothing mission critical. I just switched from php to python about 3 weeks ago in order to deploy apps on the Google App Engine. My deepest language experience is in frontend Actionscript 3, so Python feels very similar to that in that you have imports, packages, and modules. I do still find myself typing ";" on rare occasions to end lines.
Here are a few things that I got tripped up by:
- I was searching for a substr? function. there is none; instead you do things like str[0:1]
- Dont Count on autocompletion (at least not in eclipse). I was hoping I could duck type things like i had done in php Eclipse and get object info autocompleted. This is not possible, so you have to keep a lot more info about objects in your head. Perhaps one way around this is to try keep all your classes in one module.
- Test with IDLE. I was used to testing php code by whipping up a single page and browsing to localhost. With appengine, and possibly your web server, this isn't justifiable when Python ships with a pretty cool cmd IDE.
hth!
Here are a few things that I got tripped up by:
- I was searching for a substr? function. there is none; instead you do things like str[0:1]
- Dont Count on autocompletion (at least not in eclipse). I was hoping I could duck type things like i had done in php Eclipse and get object info autocompleted. This is not possible, so you have to keep a lot more info about objects in your head. Perhaps one way around this is to try keep all your classes in one module.
- Test with IDLE. I was used to testing php code by whipping up a single page and browsing to localhost. With appengine, and possibly your web server, this isn't justifiable when Python ships with a pretty cool cmd IDE.
hth!
> - Dont Count on autocompletion (at least not in eclipse)
Tbh, PyDev for Eclipse is pretty darn good. Doesn't fail me on autocompletion, function arguments etc, except for places where objects are created dynamically. Also, I find it very handy being able to navigate to any one places in my $PYTHONPATH with one keystroke on F3 and get the documentation + the implementation to read through. Keeps me away from most documentation sites and inside the IDE.
Tbh, PyDev for Eclipse is pretty darn good. Doesn't fail me on autocompletion, function arguments etc, except for places where objects are created dynamically. Also, I find it very handy being able to navigate to any one places in my $PYTHONPATH with one keystroke on F3 and get the documentation + the implementation to read through. Keeps me away from most documentation sites and inside the IDE.
I made the jump from PHP to Python a few years ago and am very glad I did. As far as frameworks are concerned, I started with Django, web.py and cherry.py and landed on on Tornado. I love the include what you need, non-kitchen sink aspect of Python development and have found my apps to have much smaller CPU and memory footprints. In addition, I believe Python development has made me a better developer in general.
I can honestly say I'd be surprised if you didn't thank yourself for jumping over to Python. Just make sure to give yourself the time and resources required for the shift in process and thinking.
I can honestly say I'd be surprised if you didn't thank yourself for jumping over to Python. Just make sure to give yourself the time and resources required for the shift in process and thinking.
- Python, Django and AppEngine for the server.
- JavaScript, JQuery and Google's Closure for the client.
- NGINX for the infrastructure if needed, for media hosting for example.
- JavaScript, JQuery and Google's Closure for the client.
- NGINX for the infrastructure if needed, for media hosting for example.
I started using Python about 5 years ago, but still used PHP for my main dev for a couple of years. PHP gradually got more and more painful to go back to, though, the more Python I wrote, and eventually I ditched PHP for all but mostly-static 3-page sites. I'm a fulltime web programmer, and we now do all our work in Django.
(That said, I'm using more and more Clojure for my personal stuff.)
(That said, I'm using more and more Clojure for my personal stuff.)
It'll take a couple of weeks to get very comfortable in the language itself, and a little longer to get used to a web framework like Django.
Once you do this, you'll be very annoyed every time you need to go back to using php. This change will be practical and eye opening for you. Enjoy.
Once you do this, you'll be very annoyed every time you need to go back to using php. This change will be practical and eye opening for you. Enjoy.
I tried. But indentation was waaaay too hard. I ended up in Ruby world...
Wait, seriously? Coming from PHP you must be working in the web world. You don't strictly indent your HTML and CSS either?
In fairness, while I find it nice in most places, Python's indentation really works against it in two applications I can think of:
Dirty command line scripting, and embedding in templates. You can create custom templating languages but they just end up growing in complexity as you decide you need more features. (Kind of analoguous Greenspun's 10th rule of programming: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp. :P)
Aside from that it really does come down to personal preference. Some people like it one way, others just don't.
Dirty command line scripting, and embedding in templates. You can create custom templating languages but they just end up growing in complexity as you decide you need more features. (Kind of analoguous Greenspun's 10th rule of programming: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp. :P)
Aside from that it really does come down to personal preference. Some people like it one way, others just don't.