Live data from Hacker News

Ask HN: Anyone went from PHP to Python?

news.ycombinator.com

31–40 of 41 posts

Re: Ask HN: Anyone went from PHP to Python?

#31
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.

Re: Ask HN: Anyone went from PHP to Python?

#32
post #23
post #11

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.

Re: Ask HN: Anyone went from PHP to Python?

#33
post #31

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, simpl…

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.

Re: Ask HN: Anyone went from PHP to Python?

#35

Earlier quoted context omitted.

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.

Re: Ask HN: Anyone went from PHP to Python?

#36
post #10

Earlier quoted context omitted.

> 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!

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 u…

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-...

Re: Ask HN: Anyone went from PHP to Python?

#37
post #30
post #3

Earlier quoted context omitted.

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 de…

[deleted]

Re: Ask HN: Anyone went from PHP to Python?

#38
post #30
post #3

Earlier quoted context omitted.

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 de…

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

  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")

Re: Ask HN: Anyone went from PHP to Python?

#39
post #26

Earlier quoted context omitted.

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 mes…

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…

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.

Re: Ask HN: Anyone went from PHP to Python?

#40
post #33
post #31

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, simpl…

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 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.

Post reply on HN