Asp Forum - from Python to Ruby in 10 seconds

John M. Gabriele

3/11/2006 10:05:00 PM

I think this subject might make for a very nice article in
the faq (maybe to complement
http://www.rubygarden.org/faq/ent... ), or else
possibly could belong at http://www.ruby-doc... .

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)

11 Answers

Logan Capaldo

3/11/2006 10:41:00 PM

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

> I think this subject might make for a very nice article in
> the faq (maybe to complement
> http://www.rubygarden.org/faq/ent... ), or else
> possibly could belong at http://www.ruby-doc... .
>
> 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.

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

Marcel Molina Jr.

3/11/2006 10:50:00 PM

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

Mc Osten

3/12/2006 12:39:00 AM

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

Douglas Livingstone

3/12/2006 1:57:00 AM

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

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

Dave Burt

3/12/2006 2:25:00 AM

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

Logan Capaldo

3/12/2006 2:33:00 AM

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

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

Bill Guindon

3/12/2006 2:52:00 AM

On 3/11/06, Dave Burt <dave@burt.id.au> wrote:
> 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.

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

dblack

3/12/2006 3:50:00 AM

Bill Guindon

3/12/2006 4:08:00 AM

On 3/11/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
> Hi --
>
> On Sun, 12 Mar 2006, Bill Guindon wrote:
>
> > On 3/11/06, Dave Burt <dave@burt.id.au> wrote:
> >> 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 ;)

>
> David
>
> --
> David A. Black (dblack@wobblini.net)
> Ruby Power and Light, LLC (http://www.rubypoweran...)
>
> "Ruby for Rails" chapters now available
> from Manning Early Access Program! http://www.manning.com/b...
>
>

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

dblack

3/12/2006 4:47:00 AM

comp.lang.ruby

from Python to Ruby in 10 seconds

John M. Gabriele

Logan Capaldo

Marcel Molina Jr.

Mc Osten

Douglas Livingstone

Dave Burt

Logan Capaldo

Bill Guindon

dblack

Bill Guindon

dblack

x Login to ForumsZone