python without OO

[Frank Bechmann (w)]

Re: python without OO

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]

Re: python without OO

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.
[color=blue]
> It seems you are telling me that :
> 1) You do not understand most programming concepts[/color]

not really - I rather want to prevent incorporation of anything that is
not really needed in the code...
[color=blue]
> 2) You are not willing to learn.[/color]

more that I like to reject anything that is not obviously substantiated
and that many people seem to have problems with...
[color=blue]
> 3) You might not have the skill set to manage developers[/color]

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

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]

Re: python without OO

thanks for the link
[color=blue]
> know what's funny: in the Lua mailing list there is currently a
> discussion about adding OO to Lua.[/color]

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]

Re: python without OO

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]

Re: python without OO

Davor wrote:[color=blue]
> thanks for the link
>
>[color=green]
>>know what's funny: in the Lua mailing list there is currently a
>>discussion about adding OO to Lua.[/color]
>
>
> I guess most of these newer languages have no choice but to support OO
> if they want to attract a larger user base :-(...[/color]

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 | ncoghlan@email. com | Brisbane, Australia
---------------------------------------------------------------

http://boredomandlaziness.skystorm.net

[Alex Martelli]

Re: python without OO

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

You _gotta_ be kidding -- what do you think, e.g., Wirth's "Algorithms
plus Data Structures Equals Programs" *IS* all about?


Alex

[Claudio Grondi]

Re: python without OO

I can't resist to point here to the
Re: How to input one char at a time from stdin?
posting in this newsgroup to demonstrate, what
this thread is about.

Claudio
[color=blue][color=green]
> >On Tue, 25 Jan 2005 12:38:13 -0700, Brent W. Hughes
> ><brent.hughes@ comcast.net> wrote:[color=darkred]
> >> I'd like to get a character from stdin, perform some action, get[/color][/color][/color]
another[color=blue][color=green][color=darkred]
> >> character, etc. If I just use stdin.read(1), it waits until I finish[/color][/color][/color]
typing[color=blue][color=green][color=darkred]
> >> a whole line before I can get the first character. How do I deal with[/color][/color][/color]
this?[color=blue][color=green]
> >
> >This is exactly what you need:
> >http://aspn.activestate.com/ASPN/Coo.../Recipe/134892
> >Title: "getch()-like unbuffered character reading from stdin on both
> >Windows and Unix"[/color]
>
> Nice to know how, but all those double underscores made my eyes bleed.
> Three classes? What's wrong with something simple like the following
> (not tested on Unix)?
>
>
> import sys
> bims = sys.builtin_mod ule_names
> if 'msvcrt' in bims:
> # Windows
> from msvcrt import getch
> elif 'termios' in bims:
> # Unix
> import tty, termios
> def getch():
> fd = sys.stdin.filen o()
> old_settings = termios.tcgetat tr(fd)
> try:
> tty.setraw(sys. stdin.fileno())
> ch = sys.stdin.read( 1)
> finally:
> termios.tcsetat tr(fd, termios.TCSADRA IN, old_settings)
> return ch
> else:
> raise NotImplementedE rror, '... fill in Mac Carbon code here'[/color]

"Davor" <davorss@gmail. com> schrieb im Newsbeitrag
news:1106689788 .676121.48490@c 13g2000cwb.goog legroups.com...[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? 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[/color]

Here the OO "solution" (activestate recipe 134892):

class _Getch:
"""Gets a single character from standard input. Does not echo to the
screen."""
def __init__(self):
try:
self.impl = _GetchWindows()
except ImportError:
self.impl = _GetchUnix()

def __call__(self): return self.impl()


class _GetchUnix:
def __init__(self):
import tty, sys

def __call__(self):
import sys, tty, termios
fd = sys.stdin.filen o()
old_settings = termios.tcgetat tr(fd)
try:
tty.setraw(sys. stdin.fileno())
ch = sys.stdin.read( 1)
finally:
termios.tcsetat tr(fd, termios.TCSADRA IN, old_settings)
return ch


class _GetchWindows:
def __init__(self):
import msvcrt

def __call__(self):
import msvcrt
return msvcrt.getch()


getch = _Getch()

[Fuzzyman]

Re: python without OO

It's perfectly possible to write good python code without using
classes. (and using functions/normal control flow).

You will have a problem with terrminology though - in python everything
is an object (more or less). Common operations use attributes and
methods of standard objects.

For example :
[color=blue]
> somestring = 'fish'
> if somestring.star tswith('f'):
> print 'It does'[/color]

The above example uses the 'startswith' method of all string objects.

Creating your own 'classes' of objects, with methods and attributes, is
just as useful.

You can certainly use/learn python without having to understand object
oreinted programming straight away. On the other hand, Python's object
model is so simple/useful that you *will* want to use it.
Regards,

Fuzzy

http://www.voidspace.org.uk/python/index.shtml

[Premshree Pillai]

Re: python without OO

On 25 Jan 2005 13:49:48 -0800, Davor <davorss@gmail. com> 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? 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[/color]

Umm, just curious -- why would you want to not use the OO stuff?
Python is like pseudocode (the basic OO, which is mostly common to
most OO languages, isn't really complicated).

Moreover, using Python without OO would be like, um, eating mango seed
without the pulp. :)
[color=blue]
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>[/color]


--
Premshree Pillai

http://www.livejournal.com/~premshree

[Miki Tebeka]

Re: python without OO

Hello Davor,
[color=blue]
> Also, is anyone aware of any scripting language that could be considered
> as "Python minus OO stuff"?[/color]
Maybe Lisp (http://clisp.cons.org/, http://www.paulgraham.com/onlisp.html)
or Scheme (http://www.plt-scheme.org/software/mzscheme/,
http://mitpress.mit.edu/sicp/full-text/book/book.html)
will be better for you mind :-)

HTH.
--
------------------------------------------------------------------------
Miki Tebeka <miki.tebeka@zo ran.com>

http://tebeka.bizhat.com

The only difference between children and adults is the price of the toys

[Neil Benn]

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? 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
>
>
>[/color]
Hello,

Yes you can, that is a benefit and flaw of python in that you
can mix up procedural and OO code, it allows for simple solutions -
however it also allows for you to create all kinds of havoc. IMHO,
there would have to be a very very small task to require procedural
code. Especially if the code is gonna be open sourced (and presumably
built upon) you will benefit from a proper design so that it can be
developed and moved on in the future.

One other thing, if your developers are proposing deep inheritance
trees in _any_ language then they are designing incorrectly. In none of
the languages I code in would I design a deep inheritance tree, the deep
inheritance tree is a fault of the designer not the language (for
example Java does not force you to design deep inheritance trees!) - 90%
of the time. I say this because you do need to be aware of the
'mythical python wand' which will turn you from a bad programmer into a
good programmer simply by typing 'class Klass(object):' .

Rather than reading a GOF book, I'd pick up an introduction to OO
programming book to take a refresher course - you thank yourself!!

Language without OO at all - what about Logo - drive that little
tortoise around!!

Cheers,

Neil

[Peter Maas]

Re: python without OO

Davor schrieb:[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]

So you think f.write('Hello world') is bloated and file_write(f,'H ello world')
is not? This is the minimum amount of OO you will see when using Python. But
I guess you will use OO in the long run to *avoid* bloated code:

--------------snip---------------

print "*** Davor's evolution towards an OO programmer ***"

print '\n*** Step 1: OO is evil, have to use atomic variables:'

name1 = 'Smith'
age1 = 35
sex1 = 'male'
name2 = 'Miller'
age2 = 33
sex2 = 'female'

print name1, age1, sex1, name2, age2, sex2

print '\n*** Step 2: This is messy, put stuff in lists:'

p1 = ['Smith', 35, 'male']
p2 = ['Miller', 33, 'female']

for e in p1:
print e

for e in p2:
print e

print '\n*** Step 3: Wait ..., p[2] is age, or was it sex? Better take a dict:'

p1 = dict(name = 'Smith', age = 35, sex = 'male')
p2 = dict(name = 'Miller', age = 33, sex = 'female')

for e in p1.keys():
print '%s: %s' % (e, p1[e])

for e in p2.keys():
print '%s: %s' % (e, p2[e])

print '\n*** Step 4: Have to create person dicts, invoice dicts, ...better use dict templates:'

class printable:
def __str__(self):
'''magic method called by print, str() ..'''
ps = ''
for e in self.__dict__.k eys():
ps += '%s: %s\n' % (e, str(self.__dict __[e]))
return ps

class person(printabl e):
def __init__(self, name, age, sex):
self.name = name
self.age = age
self.sex = sex

class invoice(printab le):
def __init__(self, name, product, price):
self.name = name
self.product = product
self.price = price

per = person(name = 'Smith', age = 35, sex = 'male')
inv = invoice(name = 'Smith', product = 'bike', price = 300.0)

print per
print inv

--------------snip---------------

Either your program is small. Then you can do it alone. Or you will
reach step 4.

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0 BtcGx1c3IuZGU=\ n'.decode('base 64')
-------------------------------------------------------------------

[Thomas Bartkus]

Re: python without OO


"Davor" <davorss@gmail. com> wrote in message
news:ct6kvm$edg $1@rumours.uwat erloo.ca...[color=blue][color=green]
> > On the other hand, this does beggar for a reason to bother with Python[/color][/color]
at[color=blue][color=green]
> > all. It seems you could be happy doing BASH scripts for Linux or DOS[/color][/color]
batch[color=blue][color=green]
> > 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, ...[/color]

The irony here is that the OO approach woven into the warp and woof of
Python is what make 1-6 possible.
[color=blue]
> 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]

Again, there is nothing "additional " about the OO in Python. It is the very
foundation upon which it is built.
[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]
It would be reasonable to decide that Python is not what you are looking
for.
I'm not sure that castrating it in this manner would be quite so reasonable.

Thomas Bartkus

[beliavsky@aol.com]

Re: python without OO


Peter Maas wrote:[color=blue]
> Davor schrieb:[color=green]
> > so initially I was hoping this is all what Python is about, but[/color][/color]
when I[color=blue][color=green]
> > started looking into it it has a huge amount of additional (mainly[/color][/color]
OO)[color=blue][color=green]
> > stuff which makes it in my view quite bloated now.[/color]
>
> So you think f.write('Hello world') is bloated and[/color]
file_write(f,'H ello world')[color=blue]
> is not? This is the minimum amount of OO you will see when using[/color]
Python. But[color=blue]
> I guess you will use OO in the long run to *avoid* bloated code:
>
> --------------snip---------------
>
> print "*** Davor's evolution towards an OO programmer ***"
>
> print '\n*** Step 1: OO is evil, have to use atomic variables:'
>
> name1 = 'Smith'
> age1 = 35
> sex1 = 'male'
> name2 = 'Miller'
> age2 = 33
> sex2 = 'female'
>
> print name1, age1, sex1, name2, age2, sex2
>
> print '\n*** Step 2: This is messy, put stuff in lists:'
>
> p1 = ['Smith', 35, 'male']
> p2 = ['Miller', 33, 'female']
>
> for e in p1:
> print e
>
> for e in p2:
> print e[/color]

Being a Fortranner, my "Step 2" would be to use parallel arrays:

names = ['Smith','Miller ']
ages = [35,33]
sexes = ['male','female']

for i in range(len(names )):
print names[i],ages[i],sexes[i]

There are disadvantages of parallel arrays (lists) -- instead of
passing one list of 'persons' to a function one must pass 3 lists, and
one can unexpectedly have lists of different sizes if there is a bug in
the program or data file. But there are advantages, too. Sometimes one
does not need to pass the entire data set to a function, just one
attribute (for examples, the ages to compute the average age). This is
more convenient with parallel arrays than a list of objects (although
it's easy in Fortran 90/95).

I am not saying that parallel arrays are better than classes for
storing data, just that they are not always worse.

It is a strength of Python that like C++, it does not force you to
program in an object-oriented style. Lutz and Ascher, in the 2nd
edition of "Learning Python", do not mention OOP for almost the first
300 pages. They say (p297)

"Python OOP is entirely optional, and you don't need to use classes
just to get started. In fact, you can get plenty of work done with
simpler constructs such as functions, or even simple top-level script
code. But classes turn out to be one of the most useful tools Python
provides ..."

[Terry Reedy]

Re: python without OO


"Peter Maas" <peter@somewher e.com> wrote in message
news:ct8517$m03 $1@swifty.weste nd.com...[color=blue]
> Davor schrieb:[color=green]
>> 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]
>
> So you think f.write('Hello world') is bloated and file_write(f,'H ello
> world')
> is not? This is the minimum amount of OO you will see when using Python.[/color]

Now that we have gently teased Davor for his OO fear, I think we should
acknowledge that his fears, and specifically his bloat fear, are not
baseless.

In Python, one can *optionally* write a+b as a.__add__(b). That is bloat.
I believe, in some strict OO languages, that bloat is mandatory. For one
operation, the bloat is minor. For ever a relatively simple expression
such as b**2-4*a*c, it becomes insanity.

If we were to have to write sin(x) instead as x.sin(), there would not be
syntax bloat. And it would be easier to write generic float-or-complex
math functions, just as your print example shows how __str__ methods
facilitate generic print operations. But if the class method syntax were
manditory, there would be class and/or class hierarchy bloat due to the
unlimited number of possible functions-of-a-float and large number of
actual such functions that have been written.

On the other hand... curryleft(list. append, somelist) is a bit more to type
than somelist.append .
[color=blue]
> print "*** Davor's evolution towards an OO programmer ***"[/color]

Your Four Steps to Python Object Oriented Programming - vars, lists, dicts,
and finally classes is great. It makes this thread worthwhile. I saved it
and perhaps will use it sometime (with credit to you) to explain same to
others.

Terry J. Reedy