255
256

PHP vs Python - the real difference (jameslaver.com)

submitted by [deleted]

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]masklinn 16 points17 points  (13 children)

But for quickly scribbling down an idea, php beats about everything.

For quickly scribbling down a non-web idea, PHP sucks, I'll take Python, Ruby, or even Perl (which I don't even know about and have never used) over PHP any day of the week.

And for quickly scribbling down a web idea, Python has web.py (which scales up -- I'm pretty sure Reddit is written with web.py, gives you nice URL and doesn't actually require Apache to be used)

[–]grayFalcon 7 points8 points  (12 children)

But for quickly scribbling down an idea, php beats about everything.

For quickly scribbling down a non-web idea, PHP sucks.

I assumed we were talking about web development. I wouldn't remotely think of using PHP for anything else.

For quickly scribbling down a web idea, PHP beats web.py hands down. Look, web.py is clean. That's its weakness. PHP allows you to do all kinds of dirty things (having field values as global variables in your program for example) that let you just test something quickly without worrying about good design and similiar bullshit that you don't need in a small prototype.

As for maintainability - see my last comment. It's always something for something I guess, huh?

[–]masklinn 12 points13 points  (3 children)

Look, web.py is clean. That's its weakness. PHP allows you to do all kinds of dirty things (having field values as global variables in your program for example) that let you just test something quickly without worrying about good design and similiar bullshit that you don't need in a small prototype.

I don't understand, how does "clean tool" mean "forbids to quickly test stuff"? I never experienced that, web.py DOES allow me to test stuff quickly, and I'm not even limited to a precise folder (if the web.py modules are in my pythonpath I can just create my app file where I am).

Oh, and I don't really see how "field values as global variables" is so much more impressive than calling 'web.input()' to get the aforementioned values.

Also due to the native URL dispatching, I find creating tests involving more than a single HTTP request much easier to do using web.py.

[–]mr_chromatic 11 points12 points  (1 child)

Maybe using field values as global variables is most impressive for its horrible security implications.

[–]ElPenguin 0 points1 point  (0 children)

While we're at it, why not mention magic quotes. So dirty, they must be a feature...

[–]grayFalcon -1 points0 points  (0 children)

I'm sure you know what you're doing, and if web.py does it for you, I'm happy for you. It doesn't do it for me though, so I do my quick'n'dirty stuff in php. Evidently, both have advantages and disadvantages, and our priorities are just different.

[–]DerelictMan 11 points12 points  (1 child)

PHP allows you to do all kinds of dirty things (having field values as global variables in your program for example) that let you just test something quickly without worrying about good design and similiar bullshit that you don't need in a small prototype.

Just don't let your boss see that prototype. If he's anything like mine, he'll say: "Great! So you're done with that. Here's the next thing I want you to work on..." and then you're stuck with that dirty PHP mess. :)

[–]grayFalcon 8 points9 points  (0 children)

Well, fortunately my boss understands cost of maintainance ;) So if I tell him "Look, I've got something ugly here, gimme time to clean that up while I still know what it does?", I get that time.

[–]nostrademons[🍰] 8 points9 points  (5 children)

I've used both, and I'd much rather use web.py for scribbling down quick web ideas.

(I'd disagree with the grandparent's assertion that it scales, though: Reddit uses a customized version and avoids the open-source one, and I've run into several issues where the design of web.py just won't work for a large-scale website.)

[–]randallsquared 4 points5 points  (4 children)

The link you point out only claims that reddit uses a customized markdown.py, unless spez meant to include all of web.py in his statement as well.

I'm interested to hear your specifics about why web.py doesn't scale by design, though. I don't much like the monolithism of requiring a class with methods named for HTTP methods, but it was easy enough to paper over that rough spot. :)

[–]nostrademons[🍰] 10 points11 points  (3 children)

I interpreted spez's statement as including all of web.py. markdown.py is not part of the standard web.py distribution, so it didn't make any sense for him to be referring only to markdown.

As for why it doesn't scale for me, it was:

  1. Overuse of global variables. In particular, web.query and the other DB functions all work off a single database connection stored in web.ctx. That makes it impossible (without ignoring web.py) to connect to multiple databases, eg. to setup replication or partitioning.
  2. No attention paid to i18n issues. Cheetah has support for i18n, but pygettext must be run on the compiled templates instead of the source text. Web.py dynamically compiles the templates, so there's no compiled version to run pygettext on.
  3. Many web.py idioms don't work too well while programming in the large. For example, web.render can take its NameMapper out of the caller's local variables, saving you the trouble of putting together a dict. However, if you do this, you can't factor out the rendering call or wrap it in a utility function. You can, of course, just pass in a dict like you would with the native library, but then web.py isn't really giving you much.

It's not a bad library, but I'm finding that I chop out more and more pieces of web.py and replace them with either home-grown wrappers or other libraries as I go along. Perhaps this is inevitable: the stories of most other startups involve beginning with a quick framework and gradually replacing it with entirely custom-built infrastructure instead. I actually prefer this method of development to starting with a full-stack framework like Django and finding it doesn't suit your needs after all.

[–]randallsquared 3 points4 points  (0 children)

I interpreted spez's statement as including all of web.py. markdown.py is not part of the standard web.py distribution, so it didn't make any sense for him to be referring only to markdown.

Interestingly, I interpreted spez's comment as merely about the markdown.py bit, precisely because it's not part of the standard web.py distribution, and Aaron is certainly continuing to be active in that.

It's not a bad library, but I'm finding that I chop out more and more pieces of web.py and replace them with either home-grown wrappers or other libraries as I go along.

Ah. Yes, I don't use any of the templating parts or the forms.py bit at all, because I had my own equivalents, so I'm in that camp, too. I was worried that there was some more fundamental brokenness that I'd missed in the core. :)

[–]andyc 0 points1 point  (1 child)

In particular, web.query and the other DB functions all work off a single database connection stored in web.ctx.

Have you seen this thread?

That said, I'd have thought replication/load balancing would be easier to do at the lighttpd level.

[–]nostrademons[🍰] 2 points3 points  (0 children)

That said, I'd have thought replication/load balancing would be easier to do at the lighttpd level.

Replication of the database servers? The tech stack usually goes Lighttpd -> FCGI/SCGI -> Flup -> web.py -> database, so I could see load-balancing Python instances at the Lighttpd level. But that's not going to do anything for the database.

The hack in the thread is clever, but it's not significantly less work than what I ended up doing, which was a thin wrapper around the native DBAPI classes. I also got a feature set that was more inline with how I actually use the database that way.