- E04 - Leadership! Google, Guido van Rossum, PSF
xavier.morel at masklinn.net
Tue Jan 3 16:00:44 EST 2006
Ilias Lazaridis wrote:
> I estimate that there is a "unfreeze" operation, too - which would lead
> to flexibity.
There is none, you have to make a copy of the object via the "dup"
(duplicate) method to get an unfrozen copy (note: clone yields an exact
copy, which means that it's still frozen).
Unfreezing an object is forbidden in Ruby.
Alex Martelli wrote:
> At the other extreme, Ruby's very productive choice is to
> allow freeze and unfreeze of everything (I believe -- but you should
> double check with a Ruby expert)
I'm no ruby expert, but I'm pretty sure there is no way to unfreeze a
frozen ruby object, you *have* to create a molten copy with the "dup"
Ilias Lazaridis wrote:
> Alex Martelli wrote:
>> Ilias Lazaridis <ilias at lazaridis.com> wrote:
> [...] - google stuff
>>> this leads to a new limitation:
>>> "#LIMITATION: large amount of repetitive code"
>> One normally does not define large numbers of identical accessors (there
> [...] - (extensive elaboration)
> possibly one can provide the code for something similar to the ruby
> class Talker
> def sayHello
> puts "Hello world"
> attr_accessor :name, :age
> thus they can later be accessed this way
> john.age = 19
> print john.age
There is no point, these exist because a ruby attribute can *never* be
accessed from outside the object, a Ruby attribute is always private
while a Python attribute is always public. This means that you *have to*
declare properties to have the ability to access an attribute of a Ruby
object, which lead to attr_accessor, attr_reader and attr_writer as
shortcut-declarations of basic properties.
The Pythonic equivalent of Ruby's attr_accessor is merely to do nothing,
because what the attr_accessor does is:
def something= value
@something = value
but not doing it would prevent any access to the "something" attribute.
(attr_reader only declares the getter method, making the attribute
read-only, and attr_writer only defines the setter, making the attribute
One thing that is very important is that in Ruby you *never* deal with
member attributes from outside the object, only methods (messages to the
In Python, you deal either with methods (messages) or attributes
(datas), but these attributes can be either "real" attributes (real
unchecked data) or properties, e.g. virtual attributes (that may
generate side-effects, sanity check on the data, or _may not map to any
existing unique data in the object_) and unless you really try to, you
don't have any way to distinguish a "real" attribute from a property
("virtual" attribute), and you don't care.
> thus if I make a typo, I create a new attribute?
Why yes of course, what were you expecting?
More information about the Python-list