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