Forum: Ruby from Python to Ruby in 10 seconds

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
7e66f4997af8ddc1344774d45ef060ad?d=identicon&s=25 John M. Gabriele (Guest)
on 2006-03-11 23:15
(Received via mailing list)
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
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-03-11 23:42
(Received via mailing list)
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.
Cee0292fffa691f1fb320d5400200e99?d=identicon&s=25 Marcel Molina Jr. (Guest)
on 2006-03-11 23:52
(Received via mailing list)
On Sun, Mar 12, 2006 at 07:41:20AM +0900, Logan Capaldo 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
10ac092ffea69dbf830f7159b05dfc77?d=identicon&s=25 Mc Osten (Guest)
on 2006-03-12 01:44
(Received via mailing list)
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...
Eeba234182bcbd7faed9ff52e233394d?d=identicon&s=25 Douglas Livingstone (Guest)
on 2006-03-12 02:57
(Received via mailing list)
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
0b561a629b87f0bbf71b45ee5a48febb?d=identicon&s=25 Dave Burt (Guest)
on 2006-03-12 03:30
(Received via mailing list)
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
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-03-12 03:33
(Received via mailing list)
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
Ff63c03fd68754adbadd2c6314646bef?d=identicon&s=25 Bill Guindon (agorilla)
on 2006-03-12 03:51
(Received via mailing list)
On 3/11/06, Dave Burt <dave@burt.id.au> 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.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-12 04:52
(Received via mailing list)
Hi --

On Sun, 12 Mar 2006, Bill Guindon 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 (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
Ff63c03fd68754adbadd2c6314646bef?d=identicon&s=25 Bill Guindon (agorilla)
on 2006-03-12 05:10
(Received via mailing list)
On 3/11/06, dblack@wobblini.net <dblack@wobblini.net> 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 ;)
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-12 05:47
(Received via mailing list)
Hi --
`
On Sun, 12 Mar 2006, Bill Guindon 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 ;)
And think of all those friends and relatives who also might not know
that private can take a string! :-)  (Disclaimer: I can't remember
whether I mention this point in the book or not.  But I approve of
your logic :-)

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 (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
10ac092ffea69dbf830f7159b05dfc77?d=identicon&s=25 Mc Osten (Guest)
on 2006-03-12 10:25
(Received via mailing list)
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.

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.
This topic is locked and can not be replied to.