From Python to Ruby in 10 seconds

ruby-talk
1

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 http://www.ruby-doc.org/docs/ .

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

···

--
(remove zeez if demunging email address)

2

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?

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 Mar 11, 2006, at 5:13 PM, John M. Gabriele wrote:

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
--
(remove zeez if demunging email address)

3

>- 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.

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

···

On Sun, Mar 12, 2006 at 07:41:20AM +0900, Logan Capaldo wrote:
--
Marcel Molina Jr. <marcel@vernix.org>

4

Logan Capaldo 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...

5

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 Capaldo 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

6

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

···

2006/3/12, Mc Osten <riko@despammed.com>:

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

7

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

···

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

Logan Capaldo 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...

8

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 Capaldo 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"

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, Dave Burt <dave@burt.id.au> wrote:

--
Bill Guindon (aka aGorilla)
The best answer to most questions is "it depends".

9

Hi --

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 Capaldo 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"

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.

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

···

On Sun, 12 Mar 2006, Bill Guindon wrote:

On 3/11/06, Dave Burt <dave@burt.id.au> wrote:

--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black

10

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.

···

Il 12-03-2006 Douglas Livingstone 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.

11

Hi --

>> 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 Capaldo 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"
>
> 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.

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.

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:

···

On 3/11/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

On Sun, 12 Mar 2006, Bill Guindon wrote:
> On 3/11/06, Dave Burt <dave@burt.id.au> wrote:

David

--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

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

--
Bill Guindon (aka aGorilla)
The best answer to most questions is "it depends".

12

Hi --
`

Hi --

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 Capaldo 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"

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.

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.

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.

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:

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

···

On Sun, 12 Mar 2006, Bill Guindon wrote:

On 3/11/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

On Sun, 12 Mar 2006, Bill Guindon wrote:

On 3/11/06, Dave Burt <dave@burt.id.au> wrote:

--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

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