From Python to Ruby in 10 seconds

I think this subject might make for a very nice article in
the faq (maybe to complement
http://www.rubygarden.org/faq/entry/show/14 ), or else
possibly could belong at Ruby-Doc.org: Documenting the Ruby Language .

If it’s too much to post on this list, please let me know
where it might be more appropriate. I’m not asking these
questions because I’m too lazy to look them up (I will,
regardless), but rather, I think this might be a useful
thread.

Anyhow, for someone coming from Python to Ruby looking to
learn the crucial basic differences in a hurry:

  • Does Ruby do “everything is a reference to an object”
    like Python does? Or does it do like Perl where a variable
    is the object, and if you want a reference you need to
    explicitly take a reference to it?

  • Python is strongly typed (every object has a type, and
    the system doesn’t automatically convert between types)
    and dynamically typed (types are figured out at runtime
    as much as possible). Is Ruby strongly or weakly typed?
    Dynamically or statically typed?

  • In Python, everything is an object (including classes
    and modules too). Is Ruby that way too?

  • Python has the notion of bound and unbound methods
    (so that you can call a method like an instance method,
    or as what looks like a class method if you include
    an instance of its class in the argument list). Then
    it also has class methods and static methods too. Does
    Ruby have bound/unbound methods like this?

  • With Python, strings and tuples are immutable (for
    speed, I believe). Does Ruby have immutables like this,
    or are most object mutable?

  • Python has import where it loads and runs the module
    right where it hits that import statement. If the module’s
    already been imported, subsequent imports don’t do anything
    special. Is ruby like this?

  • Python uses _foo, __bar, and baz underscore notation
    loosely for private references. Does Ruby have similar
    notions of “privacy”?

  • Python has the pydoc command that can read docstrings
    right there in your .py file and present them as a man page.
    Can ruby’s “ri” command do this too? Or must “rdoc” get
    involved somehow?

Any other “In Python it’s like {this}, but in Ruby you
do {that}” you can think of would most likely be useful
here.

Thanks,
—John

On Mar 11, 2006, at 5:13 PM, John M. Gabriele wrote:

Anyhow, for someone coming from Python to Ruby looking to
learn the crucial basic differences in a hurry:

  • Does Ruby do “everything is a reference to an object”
    like Python does? Or does it do like Perl where a variable
    is the object, and if you want a reference you need to
    explicitly take a reference to it?

Everything is a reference to an object

  • Python is strongly typed (every object has a type, and
    the system doesn’t automatically convert between types)
    and dynamically typed (types are figured out at runtime
    as much as possible). Is Ruby strongly or weakly typed?
    Dynamically or statically typed?

Strong-Dynamic

  • In Python, everything is an object (including classes
    and modules too). Is Ruby that way too?

Yes

  • Python has the notion of bound and unbound methods
    (so that you can call a method like an instance method,
    or as what looks like a class method if you include
    an instance of its class in the argument list). Then
    it also has class methods and static methods too. Does
    Ruby have bound/unbound methods like this?

Yeeees… I think.

a = “Hello”

to_s_from_object = Object.instance_method(:to_s) #=> #<UnboundMethod:
Object(Kernel)#to_s>

to_s_from_obj_bound = to_s_from_object.bind(a) #=> #<Method:
String#to_s>
to_s_from_obj_bound.call() #=> “#String:0x3a6ebc

If that’s the sort of thing you mean

  • With Python, strings and tuples are immutable (for
    speed, I believe). Does Ruby have immutables like this,
    or are most object mutable?

Strings are mutable, symbols, fixnums, floats and bignums are
immutable (among others)
For the most part if it makes sense that something should be
mutable, it is. I don’t think that mutability is ever determined on
the basis of performance ( except for maybe symbols)

Ruby doesn’t have tuples (If these are the same tuples from ML,
etc.). Its array’s are mutable.

  • Python has import where it loads and runs the module
    right where it hits that import statement. If the module’s
    already been imported, subsequent imports don’t do anything
    special. Is ruby like this?

the method is called “require”.

  • Python uses _foo, __bar, and baz underscore notation
    loosely for private references. Does Ruby have similar
    notions of “privacy”?

Method visibility can be controlled via the private, public, and
protected key words. You can always get past these of course by use
of #instance_eval for instance.

  • Python has the pydoc command that can read docstrings
    right there in your .py file and present them as a man page.
    Can ruby’s “ri” command do this too? Or must “rdoc” get
    involved somehow?

I don’t believe ri can do on the spot parsing and viewing of the docs
for a given file.

On Sun, Mar 12, 2006 at 07:41:20AM +0900, Logan C. wrote:

Ruby doesn’t have tuples (If these are the same tuples from ML,
etc.). Its array’s are mutable.

Any object can be made immutable by freezing it.

array = %w(a b c d)
=> [“a”, “b”, “c”, “d”]

array << ‘e’
=> [“a”, “b”, “c”, “d”, “e”]

array.freeze
array << ‘f’
TypeError: can’t modify frozen array
from (irb):3:in `<<’
from (irb):3

marcel

Logan C. ha scritto:

For the most part if it makes sense that something should be mutable,
it is. I don’t think that mutability is ever determined on the basis of
performance ( except for maybe symbols)

Having some object immutable allows some optimization otherwise not
possible. On the other hand makes some algorithms slow.

The typical case is concatenating a lot of strings. In python it is
terribly unefficient, it’s better to use StringIO objects (kind of file
in memory) or joining arrays.

However, I think the real reason is:
in Python dictionary (hash) keys are supposed to be immutable (again,
for performance reasons, I’ve been told). Since hashes that could not
use strings as keys would be quite useless, strings are immutable.

ObjectiveC has both mutable and unmutable. But since in Python “there
should be only one way to do it”, strings are just unmutable.

But not to go too off-topic…

I noticed that strings are mutable in ruby since << adds to existing
string. But I found out sometimes += creates a new string objetc…

2006/3/12, Mc Osten [email protected]:

I noticed that strings are mutable in ruby since << adds to existing
string. But I found out sometimes += creates a new string objetc…

a += b is the same as a = a + b. So, (a + b) creates a new string, and
then assigns it to a. If you did a = b + c, you would not expect b to
change, and so it is the same with a += b.

Douglas

On Mar 11, 2006, at 7:43 PM, Mc Osten wrote:

terribly unefficient, it’s better to use StringIO objects (kind of

But not to go too off-topic…

I noticed that strings are mutable in ruby since << adds to
existing string. But I found out sometimes += creates a new string
objetc…

I’m sorry I made that sound more general than I meant. I meant in
ruby
generally immutablity/mutability was not decided on the basis
of performance concerns

I find Logan’s answers accurate and complete, except for one, which is a
little complicated. Let me add a little to his answer.

John M. Gabriele wrote:

  • Python uses _foo, __bar, and baz underscore notation
    loosely for private references. Does Ruby have similar
    notions of “privacy”?

Logan C. wrote:

Method visibility can be controlled via the private, public, and
protected key words. You can always get past these of course by use of
#instance_eval for instance.

In “foo.bar”, bar is always a method, not a variable. What we call
attributes are methods that behave like attributes. “foo.bar = baz”
calls a
method called bar=. We use attr_accessor, attr_reader and attr_writer to
create attributes with their own variables. For example, “class Foo;
attr_accessor :bar; end; foo = Foo.new”

So private, public and protected modify methods. We use sigils for
non-local
variables: $global, @instance_variable, and @@class_variable. You can’t
say
foo.@bar, and foo.bar bears no necessary relationship with @bar.

Finally, the methods private, public and protected can be used in two
ways.
Without an argument, they modify the visibility of all the methods
defined
after them in the current scope. They can also be fed specific method
names
to modify the visibility of particular methods.

Cheers,
Dave

On 3/11/06, Dave B. [email protected] wrote:

protected key words. You can always get past these of course by use of
#instance_eval for instance.

In “foo.bar”, bar is always a method, not a variable. What we call
attributes are methods that behave like attributes. “foo.bar = baz” calls a
method called bar=. We use attr_accessor, attr_reader and attr_writer to
create attributes with their own variables. For example, “class Foo;
attr_accessor :bar; end; foo = Foo.new”

I found this a bit confusing. Maybe…
attr_accessor, attr_reader and attr_writer can be used to create
attributes with their own variables. They can also create the
appropriate set/get methods for those (or other) variables.

Creating variables and methods:

class Foo
attr_accessor :bar
end

f = Foo.new
f.bar = ‘test’
puts f.bar

Creating methods only (variable is created when Foo.new is called):

class Foo
attr_accessor :bar
def initialize(bar=‘’)
@bar = bar
end
end

f = Foo.new
f.bar = ‘test’
puts f.bar

So private, public and protected modify methods. We use sigils for non-local
variables: $global, @instance_variable, and @@class_variable. You can’t say
foo.@bar, and foo.bar bears no necessary relationship with @bar.

Finally, the methods private, public and protected can be used in two ways.
Without an argument, they modify the visibility of all the methods defined
after them in the current scope. They can also be fed specific method names
to modify the visibility of particular methods.

The method names need to passed as symbols:
class Foo
private :bar
end

Cheers,
Dave

Cheers to you also.
Forgive me, I’m thinking in editor mode.

On 3/11/06, [email protected] [email protected] wrote:

loosely for private references. Does Ruby have similar
create attributes with their own variables. For example, "class Foo;
class C
attr_accessor :x
end

the methods x and x= have no unique claim to, or ownership of, @x.

Maybe one could say: The attr_* methods wrap instance variables in
simple, like-named getter and/or setter methods. Given a pair of such
methods x and x=, wrapped around @x, objects of the class are said to
have an attribute “x”. Or something.

Perhaps best said with “when you have no other methods that set/get @x”?

The method names need to passed as symbols:
class Foo
private :bar
end

You can use a string too (private “bar”).

I sit corrected (he says, hoping to keep his ‘standings’ in the
‘word-tweaking sweepstakes’)

If nothing else, it serves as a reminder that I should buy your book :wink:

Hi –
`
On Sun, 12 Mar 2006, Bill G. wrote:

  • Python uses _foo, __bar, and baz underscore notation
    method called bar=. We use attr_accessor, attr_reader and attr_writer to

Perhaps best said with “when you have no other methods that set/get @x”?

Perhaps, though I deliberately didn’t qualify it, on the theory that
you could have custom-written accessor methods and still refer to
something as an “attribute”. But that may be different from having
multiple things going on with the same variable. I’m not sure…
could you have one or more “changer” methods that weren’t quite setter
methods, and still have an “attribute”?

I guess it does come down to word-play, at a certain point. After
all, from Ruby’s perspective, it’s all just methods.

If nothing else, it serves as a reminder that I should buy your book :wink:
And think of all those friends and relatives who also might not know
that private can take a string! :slight_smile: (Disclaimer: I can’t remember
whether I mention this point in the book or not. But I approve of
your logic :slight_smile:

It’s also a reminder that strings can be used in a lot of places
where, for whatever reason, it became customary to use symbols.

David


David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

“Ruby for Rails” chapters now available
from Manning Early Access Program! Ruby for Rails

Hi –

On Sun, 12 Mar 2006, Bill G. wrote:

Method visibility can be controlled via the private, public, and
attr_accessor, attr_reader and attr_writer can be used to create
attributes with their own variables. They can also create the
appropriate set/get methods for those (or other) variables.

If I can join the word-tweaking sweepstakes: I don’t think attributes
really have “their own” variables. Give this:

class C
attr_accessor :x
end

the methods x and x= have no unique claim to, or ownership of, @x.

Maybe one could say: The attr_* methods wrap instance variables in
simple, like-named getter and/or setter methods. Given a pair of such
methods x and x=, wrapped around @x, objects of the class are said to
have an attribute “x”. Or something.

The method names need to passed as symbols:
class Foo
private :bar
end

You can use a string too (private “bar”).

David


David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

“Ruby for Rails” chapters now available
from Manning Early Access Program! Ruby for Rails

Il 12-03-2006 Douglas L. ha scritto:

a += b is the same as a = a + b. So, (a + b) creates a new string, and
then assigns it to a. If you did a = b + c, you would not expect b to
change, and so it is the same with a += b.

Ok. Perfect: it makes sense even if in the first instance I found it
misleading, since I expected it to have the same semantic of a simple
“append” operation, but of course regarding a+=b a contracted form of a
= a + b, it’s fine.

Probably it was prior C++ exposure that made me think that way.