Alex Martelli wrote: > Ilias Lazaridis <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
