python without OO

[Davor]

Is it possible to write purely procedural code in Python, or the OO
constructs in both language and supporting libraries have got so
embedded that it's impossible to avoid them? Also, is anyone aware of
any scripting language that could be considered as "Python minus OO
stuff"? (As you can see I'm completely new to Python and initially
believed it's a nice&simple scripting language before seeing all this
OO stuff that was added in over time)
Thanks,
Davor

[Jeremy Bowers]

On Tue, 25 Jan 2005 15:01:23 -0800, Davor wrote:

Thanks,

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 - 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 :-)

The difference between Python OO and Java is that Python's *actually
solves problems* instead of creating them.

Given your experience and goals, I'd recommend going ahead with your plan,
but the time will come when the Right Solution is creating a class, and I
strongly recommend that you not avoid it because of the bad taste Java has
legitimately left in your mouth. Odds are, that time will come sooner
rather than later, too.

I'd also recommend spending a bit more time with Python before trying to
lead a project in it. That's general advice not Python-specific, and I
understand that it is also sometimes impractical. However, you will pay
for it one way or another. If nothing else, people who have learned Python
and are capable of contributing valuable code are going to be very turned
off when they submit perfectly reasonable classes to solve problems and
get shot down for being OO.

(For context on my point of view, I offer up
http://www.jerf.org/writings/bowersLaw.html ; trying to create a
completely class-free large project in Python will be possible, but it is
probably inadvisable, as you are throwing away useful tools that you will
probably end up replicating anyhow. What Java teaches about OO is actively
harmful in learning Python and must be unlearned. Java is the new Basic.)

[Jeff Shannon]

Davor wrote:

[...] what I need that Python has and bash&dos don't is:

1. portability (interpreter runs quite a bit architectures)
2. good basic library (already there)
3. modules for structuring the application (objects unnecessary)
4. high-level data structures (dictionaries & lists)
5. no strong static type checking
6. very nice syntax
But modules, lists, and dictionaries *are* all objects, and one uses
standard object attribute-access behavior to work with them.
so initially I was hoping this is all what Python is about, but when I
started looking into it it has a huge amount of additional (mainly OO)
stuff which makes it in my view quite bloated now...
If you're basing your opinion of OO off of C++ and Java, then it's not
too surprising that you're wary of it. But really, the OO in Python
is as simple and transparent as the rest of the syntax. You don't
need to define your own classes if you don't want to -- it's quite
easy to write modules that contain only simple functions. A trivial
understanding of objects & object attributes is needed to use the OO
portions of the standard library. If you really want, you can still
dictate that your own project's code be strictly procedural (i.e. you
can use objects but not define objects).
anyhow, I guess
I'll have to constrain what can be included in the code through
different policies rather than language limitations...

You mention elsewhere the fear of some developer with a 50-layer
inheritance heirarchy. That's not something that normally happens in
Python. Indeed, one of the tenets of the Zen of Python is that "flat
is better than nested". But more than that, it's just not necessary
to do that sort of thing in Python.

In statically typed languages like C++ and Java, inheritance trees are
necessary so that you can appropriately categorize objects by their
type. Since you must explicitly declare what type is to be used
where, you may need fine granularity of expressing what type a given
object is, which requires complex inheritance trees. In Python, an
object is whatever type it acts like -- behavior is more important
than declared type, so there's no value to having a huge assortment of
potential types. Deep inheritance trees only happen when people are
migrating from Java. ;)

Jeff Shannon
Technician/Programmer
Credit International

[Erik Johnson]

"Davor" <da*****@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

[Jeff Shannon]

Davor wrote:

M.E.Farmer wrote:

Wrap your head around Python, don't wrap the Python around your head!
This is NOT Java, or C++ or C , it IS Python.

that's interesting hypothesis that behavior will vary due to the use of
different language ...

If using a different language doesn't require/encourage different
programming habits, then what's the point of using a different language?

"A language that doesn't affect the way you think
about programming, is not worth knowing."
--Alan Perlis

Different languages offer different modes of expression, different
ways of approaching the same problem. That's *why* we have so many
different programming languages -- because no single approach is the
best one for all problems, and knowing multiple approaches helps you
to use your favored approach more effectively.

Jeff Shannon
Technician/Programmer
Credit International

[M.E.Farmer]

Davor,
I was gonna let it go but .... I never was good at shutin up ;)
The greatest strength a manager can have is delegation. And with that
add the ability to best use the resources available .
It seems you are telling me that :
1) You do not understand most programming concepts
2) You are not willing to learn.
3) You might not have the skill set to manage developers
What does it all mean?
Stop telling your programmers how to program! Seriously NOW.
If you managed a group of doctors would you tell them that they could
only use techniques that *YOU* understood, even if the were STANDARD
and well known by others?
That brings me to the other point , you have mentioned design patterns,
did YOU read GOF Design Patterns? It seems to me that if you were to
spend a week with the book you could grasp at least the gist of the
major patterns.They are pretty simple and quite informative.
You should at least speak the lingo of the field you manage in.
If your guys occasionally do something and you feel lost, that is a
sign you are normal.
Oh yea and don't confuse programming idioms of various language with
design patterns.
Start cultivating a talent for setting clear goals and clear objectives
, learn how to manage people and have better communication (that is two
way) with your developers.
Your job is to be a manager , so __manage__ your team , have the
overview have the design concept have the long road in mind and then at
the same time listen to your team and do what it takes to smooth the
rough edges and move the project forward, don't fiddle the details
unless needed.
Set goals not details unless they are real restrictions. Life is full
of real restrictions and so are most projects so avoid getting into the
unrealistic and unreasonable. Let your talent make you look good and
help them do it.
This advice holds true for every field I can think of. Ignorance can be
remedied with a book , but apathy sometimes needs a swift kick in the
ass.

Hope you do well,
M.E.Farmer

[Frank Bechmann (w)]

even if I follow the other answers above - language-wise and
management-advise-wise - just for the sake of completeness - I would
like to point you to Lua: http://www.lua.org/

1. portability (interpreter runs quite a bit architectures)
=> yes, nearly pure ANSI-C should compile

2. good basic library (already there)
=> you might have to collect some additional libraries and add them to
the core language, so currently not the strongest part, but typical file
handling is possible (at least w/ luafilesystem module)

3. modules for structuring the application (objects unnecessary)
=> yes, starting w/ current in-work release

4. high-level data structures (dictionaries & lists)
=> just one that combines both dictionary and list

5. no strong static type checking
=> yes

6. very nice syntax
=> little bit more "classic" than Python by using 'then ..end' and the
like, as long as you don't exploit the built-in flexibility of Lua it is
very easy to be read and written.
know what's funny: in the Lua mailing list there is currently a
discussion about adding OO to Lua.

[Davor]

M.E.Farmer,

first to clarify few things - I'm neither manager nor professionally
involved in code development - I'm just embarking on a small project
that I would like to attract some programmers to later on and make it a
nice open-source system. Based on my previous experience with few SMALL
projects, I would like to avoid object orientation as much as possible.
The reason is that I always ended up working with people who were
without much experience, same as me, but they were all so influenced by
OO propaganda that it was impossible to reason with them and to go with
as simple solution as possible (not saying that OO solution is
necessarily more complex than a structured one IN ALL CASES - but in
any single case I've seen so far it was). So every single time I was
wasting time trying to explain why not to go with cool OO way as
opposed to simple un-cool structured solution. So, if the application
was feasible to develop in C or C++, the solution would be easy - just
choose C and avoid all OO mess - of course would have slightly more
problems with C's looser type-checking but in my experience it's far
less problem then troubles that happen when one starts going crazy with
C++ generic classes, multiple inheritance, deep inheritance trees,
etc.. The nature of the application that I'm planning on is perfectly
suited to a good high-level scripting language, and python looked very
attractive so I decided to take look at it, but then i realized it has
all this OO stuff that I got scared off immediately :-) - luckily some
of these other guys including yourself mentioned that there are not
that many issues with Python's OO stuff as there is with Java's of C++
(seems I'm not the only one with Java&C++ OO traumas :-)) - so I'm
encouraged to proceed with Python.

It seems you are telling me that :
1) You do not understand most programming concepts
not really - I rather want to prevent incorporation of anything that is
not really needed in the code...
2) You are not willing to learn.
more that I like to reject anything that is not obviously substantiated
and that many people seem to have problems with...
3) You might not have the skill set to manage developers
maybe not good management approach but I would always opt for "not
giving them the tools I don't want them to use" over "giving them
tools I don't want them to use and then forbidding them to use these
tools" - especially if they are not getting paid for what they are
building :-)
Stop telling your programmers how to program! Seriously NOW.
If you managed a group of doctors would you tell them that they could
only use techniques that *YOU* understood, even if the were STANDARD
and well known by others?

This sounds like one of those ideas preached by agile community - I say
set up the rules and conventions as much as you can (in a
*non-intrusive* way) if you are a manager... Exactly the group of
professionals you mentioned in your example is support for what I am
claiming. In fact in that profession everything is exactly about the
rules, precise techniques, and exact processes that have to be done and
when they have to be used. If anything gets done outside of recommended
practices they are legally responsible for. For example, if a person
has to undergo sinus surgery and the endoscopic version is sufficient
(simple, non-intrusive, internal incision) and a doctor decides to do
the traditional surgery with external cutting - I guess everyone would
be pissed off - especially the patient :-)..

Also, yes, I have read GOF book... but I never found it a big deal -
no one ever had to document structured patterns - which definitely
exist - but seem to be obvious enough that there is no need to write a
book about them...

Thanks for your feedback!
Davor

[Davor]

thanks for the link

know what's funny: in the Lua mailing list there is currently a
discussion about adding OO to Lua.

I guess most of these newer languages have no choice but to support OO
if they want to attract a larger user base :-(...

davor

[Terry Reedy]

Davor, Before I learned Python, I too was put off by OO hype. And I
suppose I still would be if I still listened to it. But Python's class
statement is somewhere inbetween a C typedef and C++/Jave classes.
Stripped down pretty much to the essentials and only used when really
useful, it made more sense to me.

If you start a project in Python and enlist other competant Pythoneers,
they most likely will not be OO fanatics. Simply tell prospective partners
that you prefer structured procedural programming to user-written object
classes everywhere. An OO afionado will realise that yours is not the
project to join.

I think you should perhaps read and write more Python code before making a
decision. Do note that methods within a class are functions first and
benefit from good procedural-code-writing ability.

Terry J. Reedy

[Nick Coghlan]

Davor wrote:

thanks for the link

know what's funny: in the Lua mailing list there is currently a
discussion about adding OO to Lua.

I guess most of these newer languages have no choice but to support OO
if they want to attract a larger user base :-(...

Tell me, have you ever defined a C structure, and then written various functions
to operate on that structure (i.e. taking a pointer to the structure as their
first argument)?

Have you then put both the structure definition and the function prototypes into
a single header file and used that header file from other code?

That's OO programming: associating several pieces of information as an 'object',
and associating various methods to operate on instances of those objects.

Everything else is optional.

Problems with OO design generally result from violations of the KISS principle,
not from OO itself (although languages like Java and C++ make it hard to avoid
violating KISS, since they make you jump through so many hoops to get anything
to work at all). KISS (and the XP mantra "Do the simplest thing that could
possibly work") are the best means to fight off overengineering , rather than a
blanket ban on OO techniques.

Jeremy's "Bower's Law" page really does provide a good perspective on the
benefits of judicious use of OO techniques
(http://www.jerf.org/writings/bowersLaw.html).

Cheers,
Nick.

--
Nick Coghlan | nc******@email. com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net