Magic is to Python as Java is to PHP

Am I in the minority in being unable to guess what this article is about from its title? I thought maybe "Magic" was some new programming language, and I didn't know that the PHP community (such as it is) hates Java.

Having been living in the Django world for a while now, I knew what the title was referring to.

I disagree with the author, however. I think that magic is a bad thing, but this is really an in-house debate. Django and Zope are on the extreme ends of the spectrum of Magic to non-Magic, and I have worked in both frameworks.

Magic does not necessarily mean "poorly defined" as some people presume. Zope does an excellent job at defining the magic that it does. I just do not like the concept of a framework that changes the essential nature of the language in which it is written.

I think of a framework as a way to avoid writing the 80% of the code that any given web application needs. One could say, well, that 80% is magic, because it just happens, but there is a fundamental difference between a framework that changes the nature of your code, adding behavior that you would never suspect from the language itself, and a framework that provides functionality that you either invoke, or add to.

Magic is great for some people, but a real PITA when you don't want the magic to happen in the way it does. Suddenly you find yourself delving deep in to the guts of the framework, reverse engineering the decisions made by the developers, finding workarounds. Suddenly the magic becomes an impediment - you are now expending much time and effort working through a system whose entire point was to save you time and effort. The framework is no longer the elegant helper taking away a lot of work that you would otherwise have to do. It IS the work you have to do.

Again - this is an in-house debate, and no doubt a die-hard Rails developer will disagree, as is their right. But for me, I much prefer as little magic as possible.

This is silly.

First off, an IRC channel does not speak for a whole community of users, and an IRC channel that covers a topic that a subset of a community is interested in certainly doesn't cover whole community of users. I mean, Python isn't PHP, it has a lot of uses outside of web development and they don't know or care about the feelings of the #django and they probably don't know what this "magic" thing is either.

Even so, nobody in the world should ever say "Wow" to anything anyone ever does on IRC. It's all happend before, it will all happen again, it's filthy, it's nasty, it's IRC.

Or to paraphrase a great character:

    IRC.  You will never find a more wretched hive of scum and villainy.

At any rate, so far as I can tell the author doesn't know Django very well, which is fine, I don't know it that well either, but rejecting "simple solution #1" that requires writing:

    login_required(some_view)

Instead of

    login_required('some_view')

Because you want to specify all your views by module path strings instead of actually importing one... that's just silly. What is wrong with importing a view to pass it to a method? Nothing, as a fan of Python for the past ~8 years, nothing is wrong with that, it's simple, it works, do it. If it offends your sensibilities, well, your sensibilities are silly.

Never mind the "simple solution #2" (in the comments by ez, but someone on IRC should have thought of it):

    @login_required
    def limited_object_list(*args, **kwargs):
        return object_list(*args, **kwargs)

Yes, crazy simple, a tiny, itsy-bitsy wrapper that does exactly what you need it to do and lets you keep your urls.py looking how you want it to. That would have been my route (although once you have to write actual view code you might as well write your own view, after all the generic views are just there to solve common use cases and they are called "generic" views instead of "customizable and flexible" views for a reason.. besides, they are easy to reproduce if you need more complex view logic).

So, instead of the existing, simple and working solutions the author wants to add a login_required argument to every generic view, instead of just using the existing, simple and working solutions?

Yeah, that makes sense.

Magic often means a minor increase in convenience now in exchange for an increased risk of a confusing debugging nightmare at an indeterminate point down the road.

Once you've been burned by it a couple of times, you become very wary.

I think python is somewhat of a refuge for people who have learned the dangers of magic the hard way and decided it should be avoided when it isn't necessary.

I would say the big no no in ruby is requiring extensive configuration files. Which I think is also because of Java and its heavy reliance on XML to set things up. If the hello world code cant be done on one line then we won't bother with it.

Decorators to pass an initarg to a class? I don't think so.

This guy wants dependency injection, which would solve his problem, and is as non-magical as it gets.