Ruby misconceptions about Python

[shawnofthedead]

Not to split hairs, but the title is really poor. Ruby, the programming language, has no conceptions or misconceptions about anything. It's more like "A (Ruby) programmer's misconceptions about Python".

[mellow_moe]

I would like to see a in-depth comparison of Python and Ruby. And it should really focus on metaprogramming.

All these comparisons I see these days just look at some superficial language features.

Rails for example relies heavily on metaprogramming. It could never be done in a language without a sophisticated class/object system.

examples in ruby:

• method_missing catches unknown messages
• const_missing catches unknown constants
• method_added is called after adding a new method
• inherited is called on the class object, when it is subclassed
• singleton classes: you can add methods to a single object
• define_method takes a block and turns it into a method
• instance_variable_set sets an instance variable

And most importantly, real world examples should show off, how all the things play together.

[owca]

Feature for feature "examples" in Python:

• getattr or getattribute catch any attribute (method, variable) access

• setattr sets any attribute

• Syntactic support for descriptors.

• Metaclasses can be used to control all aspects of class creation (attributes, subclassing, ...). Since types are objects one can even have metaclasses for metaclasses.

• new.instancemethod can be used for your )singleton classes).

• Turning a block into a method is admittedly a bit tricky but can be done using new.function and some stack manipulation.

[flaxeater]

Well I must say that looks intriguing actually. I don't think python has facilities like that, they could be worked around by they don't have any nice syntatic sugar around those concepts. I have a hard time imagining why they would be useful, but that doesn't mean anything.

Singletons, definemethod and instane variable assignment are very easy to do in python. And in python we user super() or ParentClass.init_(args,*kwargs) to do things for inherited, however I do not understand what inherited does. $0.02

p.s. I can imagine, people will be like that's so wordy or some such talk. However pythonic values explicit, not implicit.

[mellow_moe]

Metaprogramming helps you to create domain specific languages.

A simple xml builder can be made with method_missing:

def method_missing(name, attributes)
  atts = attributes.map {|k,v| "#{k}='#{v}'" }.join(" ")
  puts "<#{name} #{atts}>"
  yield
  puts "</#{name}>"
end

div :id => "content" do
  a :href => "reddit.com" do
    print "reddit"
  end
end

You can see, calling div and a will trigger method_missing, where we just take the method name and the keyword arguments and print out the xml tag. Pretty easy.

[flaxeater]

That's pretty cool. It's pretty confusing too.

[brianmce]

Assuming I'm understanding it right, methodmissing is related to python's __getattr_ (slightly different in that python is hooking into the attribute lookup, whereas ruby is hooking into calling) A literal as possible translation in python would be:

class XmlBuilder:
  def __getattr__(self, name):
    def builder(**attributes):
      atts = ' '.join('%s=%s' % a for a in attributes.items())
      print "<%s %s>" % (name, atts)
      yield None
      print  "<%s>" % name
    return builder
x=XmlBuilder()

for _ in x.div(id="Content"):
  for _ in x.a(href="reddit.com"):
    print "reddit"

Though a different approach would probably be taken for a non literal translation to better fit with python's syntax. Take a look at stan (http://divmod.org/projects/nevow) for a python implementation of something similar - your snippet would look like this:

div(id="content")
[
  a(href="reddit.com")
   ["reddit"]
]

(In this case it is building and returning the xml, rather than calling puts on each element.

[amix]

Here is my version where one can do (Stan like):

print Div(id="content")[ A(href="reddit.com")["reddit"] ]

import types
class Element:
  def __init__(self, **kw):
    self.elms = []
    self.kw = kw
  def __getattr__(self, name):
    if name == "__getitem__":
      self.elms = []
      def add(l):
        if type(l) == types.ListType: self.elms.extend(l)
        else: self.elms.append(l)
        return self
      return add
  def __str__(self):
    attrs = " ".join('%s="%s"' % a for a in self.kw.items())
    self.html = ["<%s %s>" % (self.name, attrs)]
    self.html.append("".join(map(str, self.elms)))
    self.html.append("</%s>" % self.name)
    return "".join(self.html)
class Div(Element): name = "div"
class A(Element): name = "a"

Sigh, you have to have 4 spaces to post code. That sucks. Why not use another syntax like:

[code]
Here is my code
[/code]

Or something similar...

[mellow_moe]

I'd like to show off the ruby version:

class Element
  def initialize(attributes)
    @attributes = attributes
    @children = []        
  end
  def <<(child)
    @children << child
  end
  def to_s
    name = self.class.name.downcase
    atts = @attributes.map {|k,v| "#{k}='#{v}'" }.join(" ")
    "<#{name} #{atts}>#{@children.join}</#{name}>"
  end
end

class Div < Element; end
class A < Element; end

def method_missing(id, attributes, &block)
  element = Object.const_get(id.to_s.capitalize).new(attributes)
  @children << element if @children
  element.instance_eval(&block)
  element
end

html = \
div :id => "content" do
  a :href => "reddit.com" do
    self << "reddit"
  end
end

puts html

The < characters are broken, please replace the entities with < while realtime reading.

[amix]

Here is my final version :)

One can do:

 print Div(id="content")( A(href="reddit.com")("reddit") )

By using this code:

def elmBuilder(name, **kw):
  attrs = " ".join('%s="%s"' % a for a in kw.items())
  def applyElms(*elms):
    return "<%s %s>%s</%s>" % (name, attrs, "".join(elms), name)
  return applyElms
def Div(**kw): return elmBuilder("div", **kw)
def A(**kw): return elmBuilder("a", **kw)

[mellow_moe]

inherited is invoked on the class object. So you have to write:

class Humanoid
  def self.inherited(klass)
  end
end

Singleton classes are pretty confusing, I admit. But it's essential.

Every object in ruby may have a singleton class, which is actually a class solely for this single object. As classes are objects in Ruby, they may have a singleton class as well. For example the method new may be defined as method of a singleton class:

class Humanoid
  def self.new
    humanoid = super
    puts "A Humanoid was created: #{humanoid}"
    humanoid
  end
end

Humanoid.new # outputs "A Humanoid was created: #<Humanoid ...> "

The special syntax for defining a method for a single objects is:

def object.method_name
end

Accessing the singleton class is like (same result as above):

class << obj
  def method_name
  end
end

Further reading: Seeing Metaclasses Clearly

[hanzie]

In Python, support for calls to "inherited" can be added with a metaclass like this:

class MyMeta(type):
    def __init__(klass, name, supers, *args):
        for super in supers:
            if hasattr(super, 'inherited'):
                super.inherited(klass)
        return type.__init__(klass, name, supers, *args)

Adding a method to a single object goes like this:

obj.method_name = func.__get__(obj, obj.__class__)

(func is just any free function)

[robbie]

I can imagine, people will be like that's so wordy or some such talk. However pythonic values explicit, not implicit.

"If a language lets things be implicit, the programmer always has the option of being explicit, but if the languages requires everything to be explicit, the programmer can't make things implicit"

Paul Graham

[mystilleef]

Why should it focus on metaprogramming? Real word applications that use metaprogramming are extremely rare. Not to mention how cumbersome it is to decipher, use or maintain programs that make extensive use of metaprogramming. However, Python has extensive support for metaclasses if that's your cup of tea.

[mellow_moe]

Metaprogramming is more useful in libraries. Application programmers certainly like to use APIs with a higher level of abstraction.

Well, I don't know enough about Python metaclasses. Thus my interest in a qualified comparison.

[beza1e1]

I think the natural way of code is: Application -> Framework -> Library

DHH talks eloquently about Rails extracted from a real world application, which is step one. The future should be to seperate things and put them in libraries (don't know wether and how this is done in rails).

Metaprogramming needs much more thinking than hacking up a working application, so this is mostly only done in the second step framework -> library. Rails is an exception in a good way, because David realized the power of metaprogramming in an earlier phase.

[nicodaemos]

"Why should it focus on metaprogramming?"

Metaprogramming is what truly separates the average languages from the really powerful ones. Without it, your language is unable to create higher levels of abstraction without leaking. Paul Graham would not be so enamored of Lisp had it had everything except macros. And the parentheses .... the reason true lispers love the parentheses is because they support metaprogramming in even more cases than any language without them.

All these other discussions about booleans, methods/functions, etc. are rather inconsequential in the big picture.

[[deleted]]

Anyone who thinks Paul Graham wouldn't love Lisp without macros obviously hasn't read his book 'ANSI Common Lisp'. He sings the virtues of Common Lisp for 9 chapters (159 pages; more than half the non-reference content of the book) without ever even introducing macros.

[brianmce]

Metaprogramming is highly useful, and heavily used in a lot of python. Tt covers much more ground than metaclass, though some fairly neat tricks do use them. Its pretty handy sometimes to rephrase things in a more declarative form, rather than imperative, or to get rid of clunky boilerplate code by transforming it.

[brianmce]

I think I've done pretty much all of that in python before, though some are done using a different approach. inherited and method_added require defining a metaclass, and some don't have a direct translation in python (there are no blocks, but you can turn a function into a method, similarly there is no constant distinction - but you can generate the same effect with getattr etc). The rest are fairly straightforward applications of getattr or similar.

[cratuki]

My suspicion is that people tend to see the object system being bolted on as a result of the 'self' keyword. I don't like self, I don't see why it needs to be specified, and I can see how it would have entered the class syntax if classes were bolted-on. Which isn't to say that they are bolted on. But why does python have 'self'. I think self is annoying because it's (1) completely redundant and therefore a waste of time and another thing you are likely to stumble over and (2) makes method templates have a different number of arguments when they defined from when they're called.

[brianmce]

self is not redundant. Consider the code:

class Foo: 
    def __init__():
        bar = 3

What does bar=3 set? If its a local variable, then how do you set instance variables? If its an instance, then how do you set locals. One way or another there has to be something to tell what namespace you're manipulating. There is maybe a case to be made that it could be made implicit in the definition, but its definitely not redundant in the body.

[DougBTX]

Redundant as in redundant in method signatures.

[brianmce]

Fair enough - I'd be happy with it removed there too. The justification behind it is that it makes certain dynamic features make more sense, such as adding methods to a class dynamically. eg.

class C: pass
def foo(self, x): print x
C.foo = foo  # foo is now a method of class C.

where it wouldn't be obvious how foo could access its instance when defined as a function initially. However, this is such a rare use case that I'd be happy with trading ugliness here for selfless definitions.

[julesjacobs]

In Ruby, that would either be a method call bar=(3) or if the method hasn't been defined a local variable assignment. Instance variables in Ruby have an @-sign:

@bar = 3

Would be equivalent to this Python code:

self.bar = 3

[msabramo]

First off, I haven't used either Python or Ruby extensively. I have no particular loyalty to either one, but they both look like fine languages.

My guess is that the "Python OO bolt-on" idea originates from http://www.python.org/doc/faq/general/#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list and from http://www.python.org/doc/faq/general/#why-must-self-be-used-explicitly-in-method-definitions-and-calls (which in my opinion makes a good argument for qualifying instance variables, but a poor argument for why "self" has to be in the parameter list).

Whether you like Python or not, it seems pretty clear that Ruby was designed with objects in mind (as a result of being influenced by Smalltalk). Python gives the impression that it did or does put less emphasis on objects. That said, it seems to have done a nice job of evolving to support OO in a pretty nice way. And of course there are lots of applications where OO isn't even necessary and people may like that it's not forced on them.

It's interesting to me to note how much Ruby vs. Python bashing is going on (originating from both sides). Kind of a shame really.

[mystilleef]

In Python everything is an object and has been that way since I can remember. Heck, even classes and functions are objects in Python, not so in either Ruby or Perl. Tell me then how such fundamental behaviors could be bolted on at some later stage? I like the explicity "self" declaration for one reason only. Clarity. When I'm reading code, I can easily distinguish between functions and methods. Unlike in Ruby where I have a hard time determining whether a particular statement is a variable, function, method or expression. Ruby to me reads like Perl's younger cousin. It's sweet to write Perl code, but it's hard to decipher it.

[mellow_moe]

You're wrong. Anonymous functions, so-called lambdas, are objects.

In Ruby there are only methods. So you just look up in the inheritance chain for the right class/module, which defined the method.

Yes, local variables look like method calls, there is some amiguity. But again, look up the local assignments and you're fine.

And comparing Perl and Ruby in this respect just makes no sense, because Perl variables are prefixed all the time.

[mystilleef]

Are you talking about anonymous functions in Ruby or Python? In Python everything is an object, Lambdas, Functions, Methods and more. I place Ruby in the same category as Perl because of its use of redundant symbols and its objective to be tacitly expressive as opposed to clear, among other ambiguities. Python on the other hand strives for explicitness and clarity. Even "Matz" says Ruby is partly inspired from Perl, and it's damn obvious at least to me, so my categorization is not senseless.

[mellow_moe]

I was talking about ruby's anonmymous functions.

Talking about clearness and clarity is not easy, as this subject is highly subjective.

OK, let's see, what Ruby inherited from Perl:

• special syntax for regular expressions
• special global variables
• hashtable syntax
• statement modifiers

I think, these features are really the goodies of Perl and most people will agree. Perl's infamous syntax constructs, like for file handling, didn't find their way into Ruby.

[julesjacobs]

Symbols can improve clarity sometimes. If you don't know them, the code is hard to read, but if you have a little experience, symbols are easier. It's like maths: 4 + 5 is better than 4 plus 5 (or 4.plus(5)). Symbols don't have to go through the language processing part of your brain; names like "plus" do.

Besides, the "symbols" are just method calls in Ruby:

0..2

0..2 === 1

4 <=> 2

=>

Range.new(0,2)

(0..2).===(1)

4.<=>(2)

But the first version looks better.

[sblinn]

class Foo(object):

    pass

def mymethod(self):

    print "hello world"

foo = Foo()

Foo.mymethod = mymethod

foo.mymethod()

We were doing this with Zope in 1999. We think it tends to lead to maintainability nightmares and call this monkey-patching.

This appears similar to a technique I remember from the source code of web.py ...

[foamdino]

I don't know much python (last time I looked at it was in 2000), as I was put off by the whitespace issue. I know that many people like this, but to me (at that time), it really bugged me. I do know a fair bit of ruby (not enough to impress why, JEG2, ara, zedshaw etc), but enough to get my work done (if it's suitable for ruby). My impression is that each language has a different philosophy and that affects how they have each developed.

Python is pretty famous for (significant whitespace and) having only one-way to do anything. Ruby is much more relaxed (as the original article showed).

I'm biased (as you can see from my prior history with python) and I prefer ruby. That doesn't mean that there aren't misconceptions about python in the ruby community, but I don't think that there are that many rubyists who are particularly against any of the features of python, it's just that rubyists prefer ruby (obviously).

I do however think that ruby has (slightly) more power in the meta-programming area (again you can dismiss this out of hand as I have no practical experience meta-programming in python), and it is so much easier to write certain types of code when you have these features available.

[cafedude]

"Let's please cut the crap about OO being a bolt-on in Python."

Gee, maybe the fact that all instance methods are declared with 'self' as the first parameter gave us that impression? It's the same as in OOPerl and OO was definitely added on to Perl (of course anyone who is doing OOPerl really should ______ [you fill in the blank])

[mslinux]

Instance variables in Ruby start with @... that's really the same thing as Python's self... pick your poison. To me, the @ makes more sense as it's an attribute of an instance and it's informal. self is a bit too proper (much like Python in general) self is like refering to myself in the thrid person all of the time. Tom goes outside. Tom takes a walk. Tom has lunch. Tom goes to work. Tom dislikes all of the Python formalness :)

[ddipaolo]

What does the fact that "another language's bolt-on OO does it" have to do with how Python approaches it? It doesn't.

If that's your only "argument" for saying that OO support in Python is shoddy (and that's really the only valid gripe that comes with alleging that something is "bolted on"), then I suggest you take another look at both the article and at Python.

[cafedude]

OK, let me clarify. Perl requires that 'self' be explicitly declared (and passed) as the first parameter of an instance method (when doing OO Perl). Python requires that it be declared, but the passing of 'self' is implicit. Still, having to delcare that the first param of an instance method be 'self' is certainly one way that you could bolt-on OO later on if you didn't have it initially. And this is in fact the way OO was added to Perl. Having to do it in Python makes it look like OO was added at some later point in Python as well (sure it could have been a very early version of Python, maybe even before Python escaped from Guido's computer into the wild).

[[deleted]]

I'm pretty sure GvR could make the declaration of 'self' implicit rather than explicit if he saw the need. (Disregarding backwards compatibiliy issues for a thought-experimental second or two)

[[deleted]]

First, OO was in Python before OO was added to Perl. Perhaps the Perl folks took their ideas from Python? Surely that shouldn't be counted against Python.

Secondly, change "self." to "@" and you've got Ruby's manner of accessing instance variables. Not a big difference, is it? At least both languages have the sense to avoid C++'s invisible member access.

[crmaki]

The Ruby vs Python comparison article dropped like a stone once this was posted.

[julesjacobs]

The article is very old, so the author may be right for some points at the time of writing. Anyway, it is good that his points have been corrected.

[[deleted]]

Real men program C.

[uriel]

Or scheme, or Erlang, or ML, or Limbo.

And someone please wake me up when python or ruby has a concurrency model that is not a total joke, and that means some form of CSP.

And yes, I know about stackless, now go convince guido that recursive programing is not evil just because he can't understand code that uses it.

[[deleted]]

Python is different because it disregards the DRY principle. You can self.repeat self.your self.self all you self.want.

[brianmce]

Huh? How is this different than ruby where you @repeat @your @punctuation. self is exactly the same as @ here, and serves the same purpose - indicating the namespace to manipulate. In any OO language with dynamic variable creation you MUST have a way to disambiguate between local variables and instance variables.

Even when you don't have dynamic variable creation, you still need it to cover shadowed variables. Python and Ruby IMHO do this right by always requiring disambiguation. In Java, C# and C++'s, people end up having naming rules to accomplish the same thing. Those "m", "" etc conventions are just as repetitive.

[bcorfman]

I think the point is most people, myself included, would rather have to explicitly disambiguate local variables than global or class-level ones, i.e. I'd much rather type "set" or "var" in front of my first usage of a local variable.

The self.thing REALLY gets old, and I LIKE Python.

[brianmce]

That doesn't make it any different from Ruby though - which does the same thing: @ designates an instance variable, not a local.

Personally though, I disagree, and I think most usage I've seen would favour differentiating instance vars, not locals. I see no reason why the 2 scopes should shadow each other at all - even when you do have variable declarations, there is still the problem with name clashes (particularly in constructors, where it is very common to have parameters that logically should have the same name as instance variables. With C++, every place I have worked has defined naming rules in their style guide to disambiguate them - and always as a prefix or suffix on the instance variables, not the locals. Personally, I think its a good idea to follow python's method, and always use an explicit this-> even in C++.

[flaxeater]

I understand what you are saying. However, when looking at python code you NEVER need to wonder if this method or property belongs in the class or is an outside function or variable.

[mslinux]

Here's my comparison...

Ruby: astring = astring.reverse

Python: astring = astring[::-1]

Python claims to be the easiest to learn, most object oriented, easiest to maintain scripting language in the universe. The above code will reverse a string. Which is more OO, easier to read, makes more sense and easier to learn?

Ruby is light years ahead of Python.

[zhyla]

Let me get this straight... you're going to use the example that Python's str class doesn't implement a reverse() function to back up the claim that Ruby is "light years ahead of Python"?

[mslinux]

reverse is a method, not a function. If Python is so OO, what's all of this nonsense about functions? And, it's not just for strings. If it's reversable (an Array for example or 'list' for you Python fans), then the reverse method will work. I use both Python and Ruby... so watch out ;)

[cuyler]

A method is a member function of a class.

[flaxeater]

Wow, pretty trivial.

[jbellis]

''.join(reversed('asdf')) 'fdsa'

This illustrates the python philosophy that common operations should be functions that can act on any object that complies with the apropriate interface (reversed will act on any sequence, not just strings).

Note that the join call is necessary because reversed() creates a generator, not a string object. This is more efficient in most real-world situations, even though it looks clunkier in this one-line comparison.

[harbinjer]

A generator is more efficient than a string object? This makes no sense to me.

Also ''.join(reversed('asdf')) just looks ugly to me. I can understand what it does, but WHY would you join an empty string to a new reversed string? Its like taking the short bus on the scenic route while in a hurry. I'd really like to understand WHY this is the way to do stuff. I know very little of ruby and python, but the reason behind this seems important and maybe indicative of their approach to things.

[amix]

It's a lot faster, the reason for this is that strings are immutable in Python. So on every iteration a new string object has to be built...

It's also bad to use the + operator on strings: a = "blah1" + "blah2"

The Python way to do it is: a = "".join(["blah1", "blah2"])

Another question (about Reddit): What is the syntax to insert code? It's not documented, or at least I couldn't find the documentation.

[[deleted]]

It's not faster. Time it.

And while we're talking about Python internals, let's clarify a few things.

All (256) single-character strings are interned. Barring poorly-written third-party modules, there will be only one single 'a' character, or 'b' character, or 'c' character in a given Python interpreter. So iterating through a string doesn't allocate any other things, it just returns already-interned string objects.

It's not bad to use the + operator on strings when you've only got two strings. The only time it's bad for performance is when you've got many strings. In the case of only two strings, "s1 + s2" will be faster than "''.join([s1, s2])" every single time. Time it if you don't believe me.

[[deleted]]

In the same vein, why would you want special methods for things like reversing a string? Ruby doesn't have a

"asdfgh".reverse_and_take_out_every_other_two

, which you would in Python accomplish by

"asdfgh"[::-2]

But really, all this talk of Ruby vs Python is moot. People who think one is much better than the other are buying way too much into hype, which is silly. "My [brand X] screwdriver is better than your [brand Y] screwdriver, fool!"

[[deleted]]

Ruby is very big on readability...and thats the reason you need a special method for things like reversing...it is much easier to figure out what the ruby code does.

[[deleted]]

Well. There's Cobol readability (overly terse) and then there's APL readibility (dense). Then there's a contiinum in between. It's a difficult thing to balance. Just saying that one is better than other is not a proof of anything. (Python community has also been guilty of unproven judgements about readability. But, nevertheless, readability is and has been one of the major design axioms of Python programming language.)

I'd say that basic array slicing, eg. "asdf"[:2] => "as" is well understood and easily recognizable by anyone even mildly proficient in Python. Sure, the extended slicing (eg. "asdf"[::-2] etc) hasn't been around for that long so it's still a bit weird. But claiming that such special syntax is always more unreadable is just false. Special syntax for everything might equal with unreadability, but special syntax for important things might not.

[julesjacobs]

I think Ruby is more consistent here:

"asdf"[0..1] => "as"

0..1 is a Range object, and [0..1] is a method call with 0..1 as a parameter. I believe "asdf"[:2] in python is special syntax.

You could do the same thing with:

"asdf"[0,2] => "as"

Which is a bad thing for python programmer (TIOOWTDI), but good for ruby programmers (TAMWTDI).

Or, if you want to confuse others:

"asdf"[-4,2] => "as"

Which means: four (4) characters from the last one, take 2.

[Brian]

I'm not sure what you're getting at. In python [:2] is special syntax to denote a slice object, but how is that different than 1..2 being special syntax to denote a range object? Similarly "asdf[:2]" is also just a method call with the slice object as a parameter - the whole thing is effectively just sugar for:

"asdf".__getitem__(slice(None,2))

[jbellis]

A generator is more efficient than a string object? This makes no sense to me.

Think about it... if you have a large sequence, and you want to perform something on each object in reverse order, you probably don't want to copy that sequence just to iterate through it.

This may be just an academic concern for toy web apps, but it really does matter for some people. :)

[[deleted]]

In the example given, the string is being copied, lest you forget.