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

[Alex Martelli]

Ilias Lazaridis <ilias at lazaridis.com> wrote:
   ...
> > ... "or equivalent" (I do believe all I named have at least a Bachelor
> > degree, but with the undisputable results they've shown afterwards, I
> > think they'd all meet the "or equivalent" clause anyway).
> 
> "   * BS or MS in Computer Science or equivalent (PhD a plus). "
> 
> This referes to an _academic_ degree.

Ah, I see.  It depends on the job; for example,
<http://www.google.com/support/jobs/bin/answer.py?answer=23641> phrases
the requirement in a more explicit way:

* BS in Computer Science or equivalent experience.

so it's obvious that instead of the academic degree "equivalent
experience" is accepted, while other job offers are very specific in
requiring SOME degree.  I had always taken the shorter "or equivalent"
as standing for the same concept, "or equivalent experience", as is
spelled out for some jobs, rather than like, say,
<http://www.google.com/support/jobs/bin/answer.py?answer=23604> which is
very specific about requiring:

* A BS degree in mechanical, electrical or industrial technology.

> Very few companies make an explicit statement about non-academic applicants.
> 
> It seems Google does not.

It seems we do, for some but not all of our job openings -- that "or
equivalent experience" being the key, where it appears (and, in my
personal opinion the shorter "or equivalent" not being poles apart - but
that's a separate issue of interpretation).

Of course, a candidate who's not already a legal resident of the country
where they want to work may face other issues, visa-related ones, that
are not decided by Google but rather by governments and legislatures of
the various countries involved.  I know I did have, among other things,
to document my academic history to the satisfaction of the US Government
(not of Google;-) to obtain my visa, once Google had extended me an
offer, and I believe that getting a visa would have been an even bigger
hassle if I did not have a degree (still, it's _possible_: my compatriot
Roberto Benigni does not have an academic degree, yet he did manage to
get visas to come collect his Oscar prizes, act in Jarmusch's "Coffe and
Cigarettes", and so on;-).

> >>Mr. Martinelli, you seem to know python.
> > 
> > Sorry, that's a brand of sparking apple cider.  I get my name mispelled
> > that way often enough, since I moved to the US, to have become quite
> > sensitive about it!-)  In MY name, there is no "in"...
> 
> Mr. Martelli, I apologize for naming you like an soft-drink.

Thanks: if I have to get mis-spelled, I prefer the alternate
mis-spelling "Martel", which at least refers to a potable cognac!-)

> > re: #LIMITATION: automated get/set methods via var-name not available
> > see the 'property' built-in.
> 
> Can you (or some reader) sent (or fill in) the relevant code?

# within file talker.py, class Talker: (take care of indentations)

        def __init__(self):
                self.name = '' 
                self.age = 0 

        def setName(self, value):
                self.name = value

        def getName(self):
                return self.name

        def setAge(self, value):
                self.age = value

        def getAge(self):
                return self.age

                zName = property(getName, setName)
                zAge = property(getAge, setAge)

Normally, we would name the properties just 'name' and 'age' (and pick
different names for the internal attributes, such as '_name' and
'_age'), but in this case you're already using the plain names for the
attributes, so I've made up different varnames for the properties.

At any rate, with this class definition,
    john.zName = 'John Doe Python'
    john.zAge = 19
perform the calls to setName and setAge respectively.


> > "prints Class Definition (methods, fields), without code
> > LIMITATION: no direct access on object-model-level"
> > not sure what you mean, but maybe see the 'inspect' module.
> 
> => Clas Definition is not accessible via MetaClasses
> (possible workaround: inspect module)

You can surely define a custom metaclass with methods that call
inspect.whatever, or directly perform whatever introspection you
require; it just seems strange to me to put this functionality in the
metaclass.  At any rate, SOME code will need to execute to perform this
task, so "without code" cannot be accomplished.  (Looking at your
evaluation of Ruby I note there's a LOT of code for this corresponding
case, indeed through inspect, despite the 'without code' specification).

Depending on what exactly you mean here, a simple dir() may in fact
suffice.  For example:

>>> class Foo(object):
...   def __init__(self): self.zap=23
...   def zapper(self): return self.zap
... 
>>> f=Foo()
>>> dir(f)
['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__',
'__hash__', '__init__', '__module__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__',
'zap', 'zapper']

The issues are obvious: you only get the names ('zap' and 'zapper' are
both just names here, no immediate indication of what's an instance
variable and what's a method instead) AND you get all the special names
as well, which clutters the results.  Obviously (if you don't want
special names) you can easily filter this list of strings at a purely
string-processing level, and to distinguish methods from non-methods
takes just a little introspection.  What module inspect does is provide
simple functions to perform such menial tasks -- nothing mysterious or
magic, you can read inspect.py to see the Python code in question.

> 
> > "#LIMITATION: attribute is not available systemwide in every object
> > #LIMITATION: attribute is not on object-model-level
> > #LIMITATION: Operation is not Object Oriented
> > "
> > If you think that the syntax x(y,z) is "not Object Oriented", then again
> > I strongly suggest that you switch to other languages (avoiding other
> > powerful object oriented languages such as Dylan, Lisp, or O'CAML, which
> > also allow usage of function-call notation for THEIR OO power); in other
> > words, if you think the mere presence of a syntax like 'y.x(z)' makes
> > any difference wrt accessing a functionality versus 'x(y, z)', you're
> > clearly evaluating things at a totally inappropriate level.
> 
> I assure you: the level is totally appropriate.

My point is that whether you call:

  setattr(zap, zip, zop)

or

  zap.__setattr__(zip, zop)

is a syntax trifle.  The semantics are the same (setattr is defined to
call the __setattr__ method, net of "legacy" issues with oldstyle
classes), so the difference boils down to where exactly you're placing
what punctuation (parentheses, commas, dots), names and decorations in
the statement; describing such merely-syntactical minutiae of
punctuation-placement as "OO" vs "not OO" is making a mockery of the
whole concept of "object orientation".

Python has many similar cases, in which prefix or infix syntax is
defined to internally call specified method.  For example, in Python,

  a + b

IS "an OO operation" -- it calls a.__add__(b), or, if warranted,
b.__radd__(a), indeed forming a typical 'TemplateMethod' Design Pattern
-- even though it's clothed in infix syntax.  And similarly, e.g., for
setattr, which is clothed in prefix ("functioncall") syntax instead.

> 
> > The notation you choose, setattr(Object, "meta", "Some meta
> 
> I did not choose it.
> 
> Someone has posted it.

It's quite correct, it's just that there are alternatives.

> > information"), is, at any rate, absolutely semantically identical to
> > Object.meta = "Some meta information" -- they will both succeed or both
> > fail, and when they both succeed they will have identical effects; thus,
> > that point about "not Object Oriented" seems to fall somewhere between
> > embarassingly wrong, and crazy-level weird.
> 
> => Object.meta = "Some meta information"
> => can be used instead of setattr(Object, "meta", "Some metainformation")

I'd put it the other way 'round, since assigning to Object.meta is the
simpler and most common approach (for an attribute name that's fixed).
setattr is generally used only when the attribute name is computed at
runtime (a variable or expression), because in that case there is no
more direct syntax for the task.  getattr, in addition, has another use
case: you can provide a "default value" so that, if the attribute is
absent in the object, you get the default value rather than having to
field an exception (AttributeError).  IOW, instead of:

  try:
    mymeta = Object.meta
  except AttributeError:
    mymeta = "No metainfo available"

you can code the simpler:

  mymeta = getattr(Object, 'meta', "No metainfo available")

This is a reasonably frequent use case, since nobody particularly likes
using four "atomic actions" (try, etc) to express the unitary concept
"give me the 'meta' attribute, IF available, otherwise a default".

> > It IS true that in Python you cannot set arbitrary attributes on
> 
> => #LIMITATION: Cannot add arbitrary attributes to arbitrary objects.

Correct.  In particular, Python has a concept of IMMUTABLE objects:
objects which, once created, cannot be altered in any way.  In
particular, you cannot add attributes (or change existing ones, etc) in
such "immutable", aka "constant", objects.

If any language you evaluate lacks the concept of immutable objects, be
sure to note the reciprocal "LIMITATION: cannot define immutable,
constant objects".

Python could do better (since some objects are mutable and still don't
support attribute-setting -- function objects for example used to be
that way, though that limitation was removed a few versions ago), but
giving up the important concept of "constant"/"immutable" objects would
not be right, so (given the inherent contradiction between having
something immutable and being allowed to add stuff to it) I dearly hope
it will never be possible to alter EVERY object.

Again looking at your evaluation of Ruby, it seems this point is
incorrect there: in Ruby, it's possible to ``freeze'' an object, making
it constant/immutable; once you've done so, you can't then "add
arbitrary" [[or non-arbitrary, for that matter!-)]] "attributes" to it.

If you consider it a limitation that "unchangeable objects cannot be
changed" (which, to me, is a mere DEFINITION of "unchangeable"!-), you
should record the alleged limitation explicitly in both cases.

> 
> > arbitrary objects.  The workaround is to use a dict, indexed by the id
> > of the object you want to "set arbitrary attributes on"; this has the
> > helpful consequence that separate namespaces are used, so your arbitrary
> > setting of metadata cannot interfere with the `true' attributes of the
> > object in question.
> 
> => possible workaround: use dict.
> 
> > I'm unable to understand what you're trying to do in the "extend talker
> > code" box following that one.
> 
> Someone has posted this code, to solve "Applying metadata (or 
> attributes, as you prefere) to Class, Object, ...".
> 
> I understand that the poster has send code which does not work.

You mean something like...:

Talker.meta = "Class meta information"
john.meta = "Instance meta information"
Talker.sayHello.meta = 'method meta information"

You can't do that on an integer, because an integer is immutable; you
can't do it on 'Talker.name', because there IS no such thing as
'Talker.name' (if that's a limitation, it's also a limitation that you
can't do it on 'rumpelstiltskin.meta' either, and the reason is just the
same: there IS no such thing as rumpelstiltskin in this code).

There's no need to define this 'meta' attribute anywhere, it just
springs into existence when you assign to it.

Once you've set these, you can "print Talker.meta" etc etc.


> If you (or any reader) like, please provide the concrete code to solve
> the open limitations (the simple ones, like e.g. get/set).

Hope I've done that in the few cases where I understood what your
intentions were, but there must be more in which I didn't, such as the
strange "without code" specification.

> Thank you for taking the time to answer.

You're welcome.


Alex