> Do we really need factory pattern in Python?

Yes.

    from PIL import Image
    im = Image.open("bride.jpg")

Image.open here is a factory, and im will be an object of a different class, depending on the filename you pass to it(jpeg, gif, png).

That is just one example, but you get the idea.

We really don't have to attach design pattern concept in a dynamic language.

    PIL.open = lambda filename: PIL.getattr("open_" + filename.split('.')[-1].strip())

so

    PIL.open('whatever.jpg') == PIL.open_jpg('whatever.jpg')

We don't do this in C++/Java because object & methods are compiled into address, and you can't concatenate arbitary memory/VM address directly like getattr()

Factory pattern is basically a huge pile of lookup table of if's and switch's, unless you use some clever voodoo in reflection, it's just a bridge to map semantic vars to memory/VM addresses.

Which in a way, is a user-level re-implementation of a dynamic language engine (poor man's version)

Well really, what's the point in calling it a factory? In Ruby or Python everything is an object, every method or function call returns an object, hence everything is a factory, and the term loses its meaning.

In this particularly case Image isn't a class, and Image.open isn't a method: https://bitbucket.org/effbot/pil-117/src/162542cc8aca/PIL/Im...

I don't know that there's any equivalent for this in Java, so I think the grandparent's question still stands.

> In Ruby or Python everything is an object, every method or function call returns an object, hence everything is a factory, and the term loses its meaning.

I don't think factory is defined as anything that returns an object.

I am not a design pattern buff, but here is what the wiki entry says:

* it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. *

I don't see why it has anything to do with everything being an object.

The Image.open example is factory pattern. It isn't implemented the same way it's implemented for Java/C++, and I wasn't commenting on the implementation; but that doesn't make it not factory.

Similarly, the command pattern, in a language with first-class functions and closures, will be implicit and look nothing like the one implemented in GoF book.

If you are taking the implementation in GoF as the definition, callbacks as we do in Ruby, JS, Python et al. look nothing like command pattern. But the implementation isn't definition, and GoF explicitly mentions it that these patterns aren't the same in all languages.

> I don't see why it has anything to do with everything being an object.

Well it certainly blurs the lines, doesn't it? If you're returning an object anyway, it's not that much of a stretch to return a slightly different object depending on circumstances. Why does it warrant a pattern all to itself and an entire chapter of a book? And more to the point, why should I care about it, other than to try and decipher legacy ex-Java code like this?

To return slightly to the original point - where are the patterns for list comprehensions, decorators or generators? There aren't any, because in the Java/C++ world it's so hard to throw functions around like this. You need to look to fields like FP and Haskell to find good uses for list comprehensions beyond the very basic stuff.

> Why does it warrant a pattern all to itself and an entire chapter of a book? And more to the point, why should I care about it, other than to try and decipher legacy ex-Java code like this?

I think we started discussing different things. I wasn't saying the way GoF implements factory for C++, or the article in question does that, is useful; I mentioned elsewhere that copying patterns literally from Java/C++ isn't really fruitful when programming in Python https://hackernews.hn/item?id=3399581

Many of the classical design patterns will either be invisible or simpler in dynamic languages. In Peter Norwig's presentation, he claims 17 of the 23 are either invisible or much simpler for Dylan - we can make the same claim for Python, Perl, Ruby et al.

But even in Python, some patterns are non-obvious, and it's better that the developer knows them beforehand, rather than re-inventing them. Apart from the non-obvious ones, you sometimes need the others as they condense a paragraph of explanation to single term.

Factory isn't one of those non-obvious patterns - a competent developer, given the problem for the factory pattern(the above Image.open) will invent factory in under 5 minutes.

So, I'm curious - which patterns do you consider non-obvious in Python?

Absolutely. I have not seen a factory pattern in use in ages. I think the last time was before http://dirtsimple.org/2004/12/python-is-not-java.html was around.

Oooh, check out Django - it uses them for forms (and maybe other things). I've spent far too much time tinkering with modelformset_factory, inlineformset_factory, and my personal favourite, generic_inlineformset_factory.

(As a bonus, they're quite poorly documented too. Yay!)