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

[Ilias Lazaridis]

Alex Martelli wrote:
> 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.
[...]

> <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
[...] - (comments, examples, elaborations)

I understand.

Ok, thus Google is flexible in this.

[sidenote: some jobs _require_ a degree by law]

So, I like Google again (in this context).

-

What about external independents ?

Does Google cooperate with them?

And how can one contact such a giant?

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

hicc!

-

Python vs. jamLang follows:

>>>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?
[...] - (code, explanations)

thanks, I've changed this:

http://lazaridis.com/case/lang/python.html#simple_variable_access

this leads to a new limitation:

"#LIMITATION: large amount of repetitive code"

>>>"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

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.

> evaluation of Ruby I note there's a LOT of code for this corresponding
> case, indeed through inspect, despite the 'without code' specification).
[...] - (code-level elaborations, implementation suggestions)

ok

>>>"#LIMITATION: attribute is not available systemwide in every object
>>>#LIMITATION: attribute is not on object-model-level
>>>#LIMITATION: Operation is not Object Oriented
[...]

>>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
[...] - (elaborations)

I've understood this.

[...]
>>=> 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".

I understand now.

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

=> Python: immutable objects

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

yes, you are right.

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

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

I estimate that there is a "unfreeze" operation, too - which would lead 
to flexibity.

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

I think I've understood your elaborations.

[...]
>>>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

ok

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

ok

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

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

ok

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

clarified above.

>>Thank you for taking the time to answer.
> 
> You're welcome.
> 
> Alex

.

-- 
http://lazaridis.com