- E04 - Leadership! Google, Guido van Rossum, PSF

Ilias Lazaridis ilias at lazaridis.com
Tue Jan 3 15:21:55 EST 2006


Alex Martelli wrote:
> Ilias Lazaridis <ilias at lazaridis.com> wrote:
[...] - google stuff

>>http://lazaridis.com/case/lang/python.html#simple_variable_access
>>
>>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 
attr_accessor:

class Talker
   def sayHello
     puts "Hello world"
   end

   attr_accessor :name, :age

end

thus they can later be accessed this way

john.age = 19

print john.age


>>I meant: reproduce the definition of the class (but without reproducing
>>the source-code of the class)
>>
>>I have removed the "without code" remark, which was missleading.
> 
> Aha!  I see now, and it does make more sense.  Yes, using inspect you
> could surely emit for example skeletons for the various methods, with
> e.g. a 'pass' in lieu of their code.  However, since instance attributes
> are determined by code that gets executed (in __init__, and maybe in
> __new__ and even elsewhere), it's not really practical to find out what
> attributes an instance would have without in fact creating such an
> instance and introspecting on it.  Would such instantiation be OK here?

If I understand you right, it would be ok.

The requirements are given by the template:

john.sayYourClassDefinition()

"john" is instantiated, when asked for his class definition.

> In some cases instantiating a class might have externally visible
> effects, say opening a network connection, or a database, etc, so you
> might well want to forbid that for purely introspective purposes.

see above.

>>yes, you are right.
>>
>>=> {New Requirement: ability to declare objects as mutable/immutable.}
> 
>    ...
> 
>>I estimate that there is a "unfreeze" operation, too - which would lead
>>to flexibity.
> 
> Yes, but also mean that immutable objects are not really immutable, only
> "immutable until further notice".  For example, the immutability of
[...] - (elaborations)

I understand now.

=> {New Requirement: ability to declare objects as immmutable or 
mutable/immutable}

>>>There's no need to define this 'meta' attribute anywhere, it just
>>>springs into existence when you assign to it.
>>
>>?
>>
>>"assign to it" with:
>>
>>setattr(Talker, 'meta', "Class meta information")
>>
>>but _not_ with this:
>>
>>Talker.meta = "Class meta information"
>>
>>correct?
> 
> Nope: both forms have IDENTICAL semantics.  They both work in just the
> SAME way.
> 
> Try it out...!

But this means that "assignment of metadata" works fine.

>>>>class Talker(object): pass
> 
> ... 
> 
>>>>Talker.meta = 'class metainfo'
>>>>print Talker.meta
> 
> class metainfo

thus if I make a typo, I create a new attribute?

.

-- 
http://lazaridis.com



More information about the Python-list mailing list