The presentation states that tuples are “immutable lists“ and that they ”should be homogeneous, but [this is] not enforced“. I disagree: tuples are meant to act as “records“ (as in a database or other set of data), which are neither lists nor homogeneous.

The presentation brought up multiple times filter and map. An article by Guido in 2005 [1] argued that these tools should be cut from Python 3. While they still exist, I am under the impression it is considered more Pythonic to use list comprehensions in the place of filter and map, as stated in the article.

Python not having define_method is misleading. One can define a method of a class as one would any attribute of the class [2]. However, it is far easier to dynamically define a method in Ruby than in Python, because lexical scoping is inherent to a Ruby block but not a Python loop.

Python not having method_missing is wrong. One can simply override __getattr__ and return the appropriate function [3].

[1]: http://www.artima.com/weblogs/viewpost.jsp?thread=98196

[2]: http://ideone.com/njXDzO

[3]: http://ideone.com/EB9MQ8

Indeed, hence `namedtuple` (named tuples extend tuples). The author got it exactly backwards: tuples are generally heterogenous, the (rare) cases of homogenous tuples are reflexive short lists and hope of a slightly cheaper creation cost.

From the context (I was there), that was obviously just a typo, probably carried over accidentally from a previous slide.

I don't know Ruby. But it's hard for me to imagine a syntax that could express any of several related operations which could reasonably be called "dynamically defining a method" in a "far easier" way than Python does. So please enlighten me, and the other "Pythonistas" who may be reading this article, as to exactly what this magical syntax is. (The clearest explanation would include some equivalent Python code or at least a plain-English explanation of what the Ruby code does -- the Ruby language's syntax has been a bit of a barrier to me.)

For example, he mentions Python doesn't have an equivalent of method_missing -- it's technically true that there's nothing you define on a Python class to specifically intercept a nonexistent method, but that's because Python's standard facility for this operates more generally at the level of attribute access. Suspect there's a bit too much expectation of Python to be message-passing like Ruby in not seeing that one.

Similarly, Python has plenty of metaprogramming features, they're just implemented differently -- and from a different conceptual standpoint -- than Ruby's. And so on and so forth.

Reduce simply isn't used much in Python code, as a product of both culture and rather lacking lambdas. It's used so little (pretty much the only "usual use case" is covered by `sum`) it's been moved out of the builtins and to the functools module in Python 3 (whereas `map` and `filter` have remained)

There are 4 other not-completely-uncommon cases in the builtins, implemented in a significantly more efficient manner for the latter 2 (ignoring Python v C): min, max, any and all. And map and filter technically but repeatedly concatenating lists together (in python) isn't the most useful way to peg your CPU.

Also, if I say "Python doesn't have these," I'm often saying it in support of Python! :)

    class Test(object):
        pass

    t = Test()
    def test(self):
        print('ehlo')
    Test.test = test
    t.test()

> It's harder to write code that pisses off other developers in Python

* define_method simply isn't needed, just set a function as attribute on a class tadaa you've defined a method:

    >>> class A: pass
    ... 
    >>> a = A()
    >>> a.foo()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AttributeError: 'A' object has no attribute 'foo'
    >>> A.foo = lambda self: 3
    >>> a.foo
    <bound method A.<lambda> of <__main__.A object at 0x100623c10>>
    >>> a.foo()
    3

    >>> A.bar = classmethod(lambda cls: 4)
    >>> A.bar()
    4
    >>> a.bar()
    4

I would add GIS as a second (if somewhat niche) case. The two big commercial players in the field (ESRI and Safe) as well as most of the open source players all have Python as a scripting language

Also in OpenGEO, looking at their projects, aside from PostGIS it's either Python (and JS) or Java (and JS)

[0] https://docs.djangoproject.com/en/dev/ref/contrib/gis/

[1] http://rubyforge.org/projects/georuby/

[2] http://dazuma.github.com/rgeo/

They aren't similar. I found Ruby to be really hard to learn: The syntax is a mess, Rails is a nightmare, every Ruby project in existence seems to have a gigantic dependency web consisting of dozens of gems, and the language has a lot of rabid fans (including some HN'ers) who'll become downright hostile to anyone who dares suggest that Ruby's less than perfect...

So if you've survived the clusterf...of the Ruby experience, you may find Python to be a suitable substitute for many projects.

Python has its own set of problems -- the years-long Py3k debacle, super(), and anonymous functions (the latter two of which have been tossed around in this discussion) -- but I've found Python to be a much more positive overall experience than Ruby.

On the credit side, I don't understand why anyone would grumble about the indentation thing - this comes very naturally, and has the pleasing side-effect of gently coercing you into writing shorter functions.

* vararg keyword arguments (kwargs)

* Keyword-only arguments (Python 3)

* help, vars, a few other nice introspective builtins

* Assignment unpacking (multiple names as left-hand side of an assignment)

* The strangest "first blush" difference between Ruby and Python, or at least the one which I found oddest when I first started switching, is that a new Ruby class is defined from the `class {Name}` line, the whole body executes in the context of the already-created class. Not so in Python, the class object will only exist once the body has finished executing.

* No mention of generators? Also outer v inner iteration is a pretty big split between two otherwise similar languages.

Mistake-ish

* obj.__dict__ -> vars(obj)

* obj.__class__ -> type(obj)

* Python's lambdas are not one-line, they're one-expression. The reason you "can't do [this] in Python" is that if:elif:else: is a statement, so doesn't fit in lambdas. But you can have arbitrary complex code in lambdas aside from that, by following http://codon.com/programming-with-nothing. For instance you can (although you should not) write:

    map(lambda num:
            0 if num % 3 == 0 else
            num * 2 if num % 4 == 0 else
            num,
        range(1, 6))

* We generally don't say Python values "evaluate to False", we say they're falsy: they're never equal to False (outside of False and — for historical reasons — 0), they're just equivalent when evaluated in a boolean context (or passed to `bool()`). Also, the list is way incomplete: any Python type defines its own "falsiness" by implementing __bool__ (or __nonzero__ in Python 2)

* Python's reflection and metaprogramming are roughly on par with Ruby's, their lack of use is more of a cultural artefact (possibly historically motivated) than a technical one. Consider adding methods to existing types for instance. You can do it in Python (on python-defined types), you just very rarely do, it's not in the culture to do something like that. Same with using metaclasses, it's done but it generally isn't the first thing a Python developer will reach for, aside from things like registering classes on the fly/on definition

Odd comments:

* Ruby mixins, as far as I know, work by injecting the module in the inheritance chain somewhere above the new class. MI is clearer and just as powerful.

+1 on everything you listed, but especially this. You _do_ see some examples of monkey-patching in Python, but at least in my very limited experience, it tends to be much less prevalent in Python than it does in Ruby. Any data to contradict this is welcome, however.

Monkey-patching also makes it harder to easily determine which names come from which source files, which is one of the strengths of Python code: Python's import system or explicitly using "self" make Python much superior to other languages.

    class BaseClass:
        def __init__(self):
            do_important_work()

    super(self, BaseClass).__init__(*args, **kwargs)

In Python 3, you can write just `super()`, even though I personally prefer the verbose (and thus explicit) way.

In single-inheritance cases, there's actually no benefit of using super(), so using `BaseClass.__init__(self, args, *kwargs)` is even more explicit.

    BaseClass.__init__(self, *args, **kwargs)

Mixins are based on the concept of composition. In my opinion, more instances of inheritance should be composition than not. I strongly suspect that many cases for multiple inheritance are actually confusion around when to use composition.

Admittedly I have little experience with languages that support multiple inheritance. Do you have an example where multiple inheritance is a clear solution to a problem that you faced?

It makes "morphing code", such as decorators easier to write. It's explicit. It's consistent (with class methods for instance). And it's not some special case magic with special syntax. It's just another parameter.

Python's great strengths is avoiding special case magic. Much more than many people realize as there's lots of syntactic sugar on top of double underscore functions and interfaces like context manager and generators.

    class Foo:
        def bar(self):
            return "bar"

    foo = Foo()
    foo.bar()      # returns "bar"
    Foo.bar(foo)   # returns "bar"

After realizing this, I was enlightened.

I think you meant `Foo.bar(foo)` here.

    class Foo(object):
        def __init__(self, bar):
            self.bar = bar
        def something(self, arg):
            return [self.bar, arg]

    assert(Foo('spam').something('eggs') == Foo.something(Foo('spam'), 'eggs')

   assert(Foo('spam').something(Foo('ham'), 'eggs') == ['ham', 'eggs'])

  def add(a,b)
    a+b
  end

  def process_numbers(a,b,method)
    func.call(a,b)
  end

  method(:add) => #<Method: Object#add>
  process_numbers(1,2,method(:add)) => 3