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

[Steven Bethard]

Re: python without OO

Davor wrote:[color=blue]
> 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?[/color]

Hmmm... sorta depends on how you define write procedural code... If
you mean, can you write Python code without accessing object attributes
(e.g. lst.sort()), then the answer's probably almost certainly no. If
you mean can you write Python code without ever writing a class, the
answer's probably yes. It'll make some things harder, and it'll
probably make some modules off-limits, but it's doable.

Could you clarify what you mean by "write purely procedural code"?

Steve

[Jarek Zgoda]

Re: python without OO

Davor wrote:
[color=blue]
> 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?[/color]

Sure, but you will got problem with libraries. Some of them are in fact
frameworks and need some subclassing or other OO fluff.
[color=blue]
> 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)[/color]

Icon, the language for OO haters.

May I ask why you do you hate OO so much?

--
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/

[Thomas Bartkus]

Re: python without OO

"Davor" <davorss@gmail. com> wrote in message
news:1106689788 .676121.48490@c 13g2000cwb.goog legroups.com...[color=blue]
> Is it possible to write purely procedural code in Python, ...[/color]
Of course!
[color=blue]
> or the OO
> constructs in both language and supporting libraries have got so
> embedded that it's impossible to avoid them?[/color]

You can always *write your own* purely procedure code.
A tougher problem would be living without the wealth of supporting library
code that is written OO.
[color=blue]
> Also, is anyone aware of
> any scripting language that could be considered as "Python minus OO
> stuff"?[/color]
Anyone aware? Not I!
[color=blue]
> (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)[/color]

Over time ???
Someone can correct me if I'm wrong but I do believe that all that dirty,
rotten OO stuff was incorporated in the language right from the start.
But
If you can live without coding OO, you can do it in Python.

I'm not sure what it is, exactly, you are trying to avoid.
Much "nice&simpl e scripting " simply has no need to create and use objects.
Of course, the entire structure of Python and all of it's built in data
structures are object oriented. But, if you wish to live within the
confines of your own strictly procedural code, I don't think you need to
deal with the issue.

On the other hand, this does beggar for a reason to bother with Python at
all. It seems you could be happy doing BASH scripts for Linux or DOS batch
files for Windows. Both are "nice&simpl e" scripting languages free of
object oriented contamination.

Why would you use an object oriented language if you don't want to?
Thomas Bartkus

[Davor]

Re: python without OO

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 :-) and other "proper" OO
design issues... Once I opted for C++ in a very small project and
believed everyone will stick with C subset + better type checking
offered through C++ - but I simply could not manage to keep them off
using OO stuff which was just making program more complicated than it
should have been. (note, I am not an experienced developer, nor the
others I'll be working with (even though some think they are:-)), so I
prefer preemptively dealing with issue of everyone showing off their OO
design skills)

Davor

[Davor]

Re: python without OO

> On the other hand, this does beggar for a reason to bother with Python at[color=blue]
> all. It seems you could be happy doing BASH scripts for Linux or DOS batch
> files for Windows. Both are "nice&simpl e" scripting languages free of
> object oriented contamination.[/color]

not really, 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

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... anyhow, I guess
I'll have to constrain what can be included in the code through
different policies rather than language limitations...
Thanks
Davor

[M.E.Farmer]

Re: python without OO

Wrap your head around Python, don't wrap the Python around your head!
This is NOT Java, or C++ or C , it IS Python.
Davor wrote:[color=blue]
> (note, I am not an experienced developer, nor the
> others I'll be working with (even though some think they are:-))[/color]
Don't worry we didn't get confused, it was quite clear ;)
Mostly you are just so off base I just say go *READ* and write more
Python, look at the standard library.
You will only see one or two levels of inheritance as the norm and it
is not that difficult.
Also you are telling me you don't have an OO problem, you have a
problem with your managment and communication skills.[color=blue]
> so I prefer preemptively dealing with issue of everyone showing off[/color]
their OO[color=blue]
> design skills)[/color]
Work on that micro-management just a little bit more, that gets the
code flowing ;)
hth,
M.E.Farmer

[Davor]

Re: python without OO

M.E.Farmer wrote:[color=blue]
> Wrap your head around Python, don't wrap the Python around your head!
> This is NOT Java, or C++ or C , it IS Python.[/color]

that's interesting hypothesis that behavior will vary due to the use of
different language - actually most python scripts that I have seen do
not even use OO which is quite understandable (same with perl, php,..)
and I'm not even sure why all these languages have incorporated OO at all...
[color=blue][color=green]
>>(note, I am not an experienced developer, nor the
>>others I'll be working with (even though some think they are:-))[/color]
>
> Don't worry we didn't get confused, it was quite clear ;)[/color]

:-)
[color=blue]
> Also you are telling me you don't have an OO problem, you have a
> problem with your managment and communication skills.[/color]

yeah, it's really tough telling them to write code so I can understand
it without having to know about all these patterns of theirs.

Davor

[Michael Spencer]

Re: python without OO

Davor wrote:[color=blue]
> 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 :-) and other "proper" OO
> design issues... Once I opted for C++ in a very small project and
> believed everyone will stick with C subset + better type checking
> offered through C++ - but I simply could not manage to keep them off
> using OO stuff which was just making program more complicated than it
> should have been. (note, I am not an experienced developer, nor the
> others I'll be working with (even though some think they are:-)), so I
> prefer preemptively dealing with issue of everyone showing off their OO
> design skills)
>
> Davor
>[/color]
Perhaps pylint (http://www.logilab.org/projects/pylint) or its ilk can help you
enforce a coding style

Michael

[richard]

Re: python without OO

Davor wrote:
[color=blue]
> M.E.Farmer wrote:[color=green]
>> Wrap your head around Python, don't wrap the Python around your head!
>> This is NOT Java, or C++ or C , it IS Python.[/color]
>
> that's interesting hypothesis that behavior will vary due to the use of
> different language - actually most python scripts that I have seen do
> not even use OO which is quite understandable (same with perl, php,..)
> and I'm not even sure why all these languages have incorporated OO at
> all...[/color]

Of course, *all* Python programs (whether you call them scripts or
otherwise) are using objects. Strings, numbers, files, lists,
dictionaries ... they're all objects. You *can't* write a Python program
without objects, but you can do so without a single "class" declaration.

The point that M.E.Farmer was trying to make is that you should not judge OO
by Java or C++. Those languages make OO a burden, with on the one hand
excessive requirements to subclass, and on the othe hand ... well, C++ is
just a burden all round really :)


Richard

[Jeremy Bowers]

Re: python without OO

On Tue, 25 Jan 2005 15:01:23 -0800, Davor wrote:
[color=blue]
> 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 :-)[/color]

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]

Re: python without OO

Davor wrote:
[color=blue]
> [...] 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[/color]

But modules, lists, and dictionaries *are* all objects, and one uses
standard object attribute-access behavior to work with them.
[color=blue]
> 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...[/color]

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).
[color=blue]
> anyhow, I guess
> I'll have to constrain what can be included in the code through
> different policies rather than language limitations...[/color]

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]

Re: python without OO


"Davor" <davorss@gmail. com> wrote
[color=blue]
> 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...[/color]

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).
[color=blue]
>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...[/color]

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...
[color=blue][color=green][color=darkred]
>>> dir(42)[/color][/color][/color]
['__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]

Re: python without OO

Davor wrote:
[color=blue]
> M.E.Farmer wrote:
>[color=green]
>> Wrap your head around Python, don't wrap the Python around your head!
>> This is NOT Java, or C++ or C , it IS Python.[/color]
>
>
> that's interesting hypothesis that behavior will vary due to the use of
> different language ...[/color]

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]

Re: python without OO

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