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

[Alex Martelli]

Ilias Lazaridis <ilias at lazaridis.com> wrote:
   ...
> Ok, thus Google is flexible in this.
> 
> [sidenote: some jobs _require_ a degree by law]

Or some even more stringent qualification, such as the state's Bar exam
for lawyers -- you may not be able to sit for that exam w/o the
appropriate degree, but the degree by itself is not enough, you still
have to pass the exam.  It is that way for Engineers in Italy (I passed
my State Exam in the early '80s), although you only need the certificate
for some specific professional undertakings (e.g. design a ship, or a
large building, or technically supervise building operations beyond a
certain size -- not to write software or to design chips).

Personally, I agree with the theory, first expressed by Adam Smith, that
such barriers to entry are mostly useful to grant practitioners of a
certain profession the "scarcity value" that lets them charge higher
prices, although of course they're always presented as "good for
society".  Note that in Europe in the Middle Ages you needed strict
qualifications of that kind for just about anything -- you could not
make hats unless you belonged to the Hatters' Guild, etc; most of those
restrictions have since been lifted, but a few groups (doctors, lawyers,
accountants, ...) have managed to keep them in place.

> What about external independents ?
> Does Google cooperate with them?

Hardly ever... I, too, was at first trying to see if I could establish
some kind of consulting relationship with Google, in order to keep my
existing freelance practice alive as well, but in the end I found no way
to do so.  I believe Google's external consultants are very few -- e.g.,
some lawyers (Google employs some, but also has some external ones on
retainer), the members of our Board of Directors, Hal Varian.

> And how can one contact such a giant?

I believe that starting at <http://www.google.com/about.html> and
navigating from it will show you all the various avenues of contact
depending on your purpose for the contact; except that, for questions
about the Google Foundation, it might be better to start at
<http://google.org/> instead.  Since the number of people wanting to
establish such contact for all sort of purposes is very large, and only
a few of Google's 5000 employees spend their time dealing with such
contact attempts, I have unfortunately heard of many cases in which such
attempts prove unfruitful.


> 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
would be no purpose served in so doing), so the "boilerplate"
(repetitive code) does not truly occur.  If for whatever reason one DOES
want a bazillion identical accessors, a simple custom metaclass (if one
has many classes with such needs), or simpler code still (if just one or
two classes require such bundles of accessors), avoid the repetitions.

For example (untested code, but should work):

class Talker(object):
  def __init__(self):
    self._name = ''
    self._age = 0
for attr in '_name _age'.split():
  def getter(self, attr=attr): return getattr(self, attr)
  def setter(self, value, attr=attr): return setattr(self, attr, value)
  setattr(Talker, attr[1:], property(getter, setter))

This is probably not worth the bother for just 2 attributes, but it
trivially generalizes to a bazillion attributes, if that's what you
want.  A custom metaclass could also more easily define an __init__
based simply on attribute names and default values desired (it's quite
possible this way, too, of course); alternative approaches include
wrapping the 'class' statement and the following loop in a factory
function which builds and returns the desired class (this gives roughly
the same power as a custom metaclass for this specialized task, though a
custom metaclass is more flexible and general); and the use of lexical
closures in preference to the simple getter and setter functions shown
here (or, factory functions for properties, embedding such closures).
E.g., change the loop to:

def makeprop(attr):
  def getter(self): return getattr(self, attr)
  def setter(self, value): return setattr(self, attr, value)
  return property(getter, setter)
for attr in '_name _age'.split():
  setattr(Talker, attr[1:], makeprop(attr))

Some would consider this more elegant (better factored).


The reason you don't see this kind of thing emphasized in Python
literature is that this style of programming is very rarely needed --
mostly when you're building a framework, or the Python modest equivalent
of a domain-specific minilanguage, or some kind of automated code
generator.  For 99% of the normal, everyday application programming one
does in Python, this introspective metaprogramming would be overkill,
although that may not be obvious to one who does not know Python -- for
example, it remains true that the addition of all of those trivial
getters and setters by whatever means performs NOTHING useful -- the 
class's functionality and interface are IDENTICAL to the one you'd
normally code, with directly accessible attributes and without all of
those boilerplate methods.

You'll find more examples of appropriate use of metaprogramming and
introspection in the 2nd edition of the Python Cookbook, though.

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

> 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
objects can be used to enhance the ability to reason about a program's
correctness... but such reasoning is not helpful if an 'immutable'
object isn't really immutable.

Perhaps rather than thinking in terms of ideals and limitations, in this
field you could just use a simple descriptive approach, since each
choice has some advantages.  E.g., a language such as Haskell occupies
one (productive) extreme: EVERY object is immutable -- you never change
existing objects, but rather make new ones as needed; this makes the
language ideal to reason about program correctness, although it requires
a programming style very different from what's normal in other languages
(I believe Haskell and other functional-programming languages of its ilk
requires very deep abilities to reason mathematically -- I've been known
to describe that as "math or CS PhD", although of course that's merely
indicative!).  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) -- makes it a lost cause to use
immutability to reason about program correctness, but allows a wide
variety of programming styles.

Most languages try to strike a balance with SOME objects being mutable
and others not, which of course like all compromises tries to get some
advantages from each side but also inevitably gets some DIS-advantages
too.  It's not necessarily easy to see all the implication of each such
choice, or trade-off, and yet most design IS about making trade-offs...

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

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


Alex