"Davor" <[EMAIL PROTECTED]> wrote > I do not hate OO - I just do not need it for the project size I'm > dealing with - and the project will eventually become open-source and > have additional developers...
If you think your project is valuable enough to eventually be "Open Source", you can bet that one of the first criticisms it will face is that it is not OO if it is perceived that there would be any advantage to being so. If your question is "Can I write useful Python code without writing my own classes, without creating a class inheritance heirarchy, etc.?" then the answer is definitely "Yes!" Python has lots of very useful and practical libraries to allow you to do all sorts of cool things. Many of those interfaces though are presented in an OO manner (to varying degrees). >so I would prefer that we all stick to > "simple procedural" stuff rather than having to deal with a developer > that will be convincing me that his 50 layers inheritance hierarchy is > good since it exists in some weird pattern that he saw somewhere on > some Java design patterns discussion board :-) and other "proper" OO > design issues... If your question is "Can I somehow hobble Python so that there are no objects anywhere and it is not possible for other developers to even think about creating something I can't understand?" then I would ask how is it you are leading a team of other programmers that is apparently not afraid of OO concepts? You can write lot's of code that is just functions, and have functions call other functions, but what does a 'def' statement (python's syntax for function definition) do? It instantiates a function object. That function can be copied (well, the reference to it, anyway), passed to other functions, returned from functions, stored in variables, etc. You may or may not see any practical use for that, but Python was (very wisely) designed to be OO right from the very start - it definitely wasn't something that was added on later. You might want to spend a little time pondering why that is. If you don't understand the difference between pop(mylist) and mylist.pop(), it would be a wise career move to invest a little time to understand what the difference is and why the state of software development has come to prefer one over the other. At the bottom, practically everything in Python is an object... >>> dir(42) ['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__', '__delattr__', '__div__', '__divmod__', '__doc__', '__float__', '__floordiv__', '__getattribute__', '__hash__', '__hex__', '__init__', '__int__', '__invert__', '__long__', '__lshift__', '__mod__', '__mul__', '__neg__', '__new__', '__nonzero__', '__oct__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__', '__rdiv__', '__rdivmod__', '__reduce__', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__str__', '__sub__', '__truediv__', '__xor__'] there's just no getting around it. If you want to set down the groundrules for your project that you will stick to basically just procedural code, fine - that's a project management issue. If you are insistent there can be no objects anywhere in your implementation, Python is definitely the WRONG choice. Well... there is no choice. It would be impossible with Python. Note also that Perl is definitely out, as is JavaScript and even PHP. ANSI C might work and (as pointed out earlier), some other likely candidates are sh, bash, csh, ksh... I don't know a lot about Tcl/Tk - I think it implements some rather OO'ish stuff, but worth consideration. Good luck. -ej -- http://mail.python.org/mailman/listinfo/python-list