python without OO

[Erik Johnson]

"Davor" <davorss at gmail.com> 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