Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python for Ruby Programmers (LA RubyConf 2013)

speakerdeck.com

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Python for Ruby Programmers (LA RubyConf 2013)

#41

Post by tragomaskhalos »

As a longtime Ruby person who has recently been doing a bit of Python, I find Ruby to be more regular (echoing its Smalltalk heritage, another plus point), but the one Python thing that really jarred - but which I have never seen anyone else complain about! - was having to put all those pesky colons in after defs, ifs etc.

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.

Re: Python for Ruby Programmers (LA RubyConf 2013)

#42

Post by sirclueless »

masklinn wrote: post #23

To add to other comments, things the author could have expanded upon: * 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…

Is Python's multiple inheritance model still wonky? For example, I remember this being a "broken" (that is, incompatible with MI) class:

    class BaseClass:
        def __init__(self):
            do_important_work()
It's broken, because this class doesn't expect to have any superclass other than Object, and hence doesn't call

    super(self, BaseClass).__init__(*args, **kwargs)
or something like that (which by the way, is super awkward syntax, repeating both self and BaseClass). But if it's subclassed as one of multiple base classes the parent classes might not get their __init__ methods called (or you might not get your __init__ called, because they forgot to call super().__init__ as well, and the superclass inheritance order ended up putting them in front of you).

Re: Python for Ruby Programmers (LA RubyConf 2013)

#43

Post by nahname »

masklinn wrote: post #23

To add to other comments, things the author could have expanded upon: * 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…

Multiple Inheritance is one of those things I really just cannot understand. From my experience, inheritance is almost always the wrong solution. Composition being the correct tool.

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?

Re: Python for Ruby Programmers (LA RubyConf 2013)

#44

Post by arxanas »

sirclueless wrote: post #42
masklinn wrote: post #23

To add to other comments, things the author could have expanded upon: * 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…

Is Python's multiple inheritance model still wonky? For example, I remember this being a "broken" (that is, incompatible with MI) class: class BaseClass: def __init__(self): do_important_work() It's broken, because this class doesn't expect to have any superclass other than Object, and hence doesn't call super(self, BaseClass).__init__(*args, **kwargs) or something like that (which by the way, is super awkward syntax…

Is this what the old-style and new-style class distinction was meant to be used for?

Re: Python for Ruby Programmers (LA RubyConf 2013)

#45

Post by arxanas »

nahname wrote: post #43
masklinn wrote: post #23

To add to other comments, things the author could have expanded upon: * 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…

Multiple Inheritance is one of those things I really just cannot understand. From my experience, inheritance is almost always the wrong solution. Composition being the correct tool. 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…

I wouldn't say mix-ins are based on the concept of composition. The mix-in is not a discrete object that's part of the composition of the class.

Re: Python for Ruby Programmers (LA RubyConf 2013)

#46

Post by nahname »

arxanas wrote: post #45
nahname wrote: post #43

Earlier quoted context omitted.

Multiple Inheritance is one of those things I really just cannot understand. From my experience, inheritance is almost always the wrong solution. Composition being the correct tool. 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…

I wouldn't say mix-ins are based on the concept of composition. The mix-in is not a discrete object that's part of the composition of the class.

Their effect of adding a mixin is similar to macros, but they provide the same abilities as composition. I wouldn't be surprised to find that mixins were based off of macros. They work really well in places where I would compose behaviour into an object.

Re: Python for Ruby Programmers (LA RubyConf 2013)

#47

Post by tomsthumb »

hamxiaoz wrote: post #27
throwa wrote: post #11

Earlier quoted context omitted.

Except if you have a good reason for wanting to learn Python, I will say as a rubyist you should learn a functional programming language like clojure or scala if you don't know them already. This is because both Python and Ruby are OO and similar in alot of ways.

Good point! I know C# and I'm learning Ruby. Next I'll pick clojure for functional programming. We should learn a new language that will change the way of our thinking.

Why not learn F#? It seems rather nice.

Re: Python for Ruby Programmers (LA RubyConf 2013)

#48

Post by ch0wn »

sirclueless wrote: post #42
masklinn wrote: post #23

To add to other comments, things the author could have expanded upon: * 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…

Is Python's multiple inheritance model still wonky? For example, I remember this being a "broken" (that is, incompatible with MI) class: class BaseClass: def __init__(self): do_important_work() It's broken, because this class doesn't expect to have any superclass other than Object, and hence doesn't call super(self, BaseClass).__init__(*args, **kwargs) or something like that (which by the way, is super awkward syntax…

> which by the way, is super awkward syntax, repeating both self and BaseClass

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.

Re: Python for Ruby Programmers (LA RubyConf 2013)

#49

Post by yen223 »

tragomaskhalos wrote: post #41

As a longtime Ruby person who has recently been doing a bit of Python, I find Ruby to be more regular (echoing its Smalltalk heritage, another plus point), but the one Python thing that really jarred - but which I have never seen anyone else complain about! - was having to put all those pesky colons in after defs, ifs etc. On the credit side, I don't understand why anyone would grumble about the indentation thing - t…

If you are allowed to complain about the pesky colons, then we should be allowed to complain about having to put "end" everywhere :P

Re: Python for Ruby Programmers (LA RubyConf 2013)

#50

Post by ch0wn »

ch0wn wrote: post #48
sirclueless wrote: post #42

Earlier quoted context omitted.

Is Python's multiple inheritance model still wonky? For example, I remember this being a "broken" (that is, incompatible with MI) class: class BaseClass: def __init__(self): do_important_work() It's broken, because this class doesn't expect to have any superclass other than Object, and hence doesn't call super(self, BaseClass).__init__(*args, **kwargs) or something like that (which by the way, is super awkward syntax…

> which by the way, is super awkward syntax, repeating both self and BaseClass 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.

I screwed up the markup there, it's supposed to be

    BaseClass.__init__(self, *args, **kwargs)
Post reply on HN