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. 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 -- http://mail.python.org/mailman/listinfo/python-list
