Re: python without OO
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 :-) 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) I think Davor is making an important point here: Python has grown in the last 14 years, and it is no more the simple scripting language it used to be. In particular, it evolved a lot of OOP cruft (static/classmethods, properties, the __new__ method, super, the new MRO, descriptors,metaclasses, etc.) and there is more than a learning curve issue coming with the added complexity. Davor is right: even if you do not want to use it, the stuff is *there* and somebody in your team will. So definitely there is an audience of programmers that just do not have an use for all the sophistication and actually are penalized by it. There is not much than can be done at the Python level. But I would see with interest a Python spinoff geared towards simplicity. Few months ago there was the Prothon proposal (by all means a terrible proposal) but the goal that motivated it (simplification, trying to remove classes) was in my opinion worthwhile. Now, *how* to remove (or simplify) classes is not at all clear to me, not I am convinced that prototypes are the right way to go, but still I feel that there is something wrong with inheritance. Maybe protocols are the solution, who knows? But in any case I think it is important to keep searching for semplicity. I do not believe Python is the definitive language, and it is probabily possible to introduce something better. It is just that nothing of the kind appeared until now, but I keep watching at the horizon ;) Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Davor wrote: Timo Virkkala wrote: This guy has got to be a troll. No other way to understand. not really - it was not my intention at all - but it seems people get upset whenever this OO stuff is mentioned - and what I did not expect at all at this forum as I believed Python people should not be so OO hardcore (seems not all as quite a few have indicated in their replies)... Nevertheless, I think the discussion has several quite good points! Yes, sorry about that. I posted too soon. After posting I read more of your posts and realized that you really mean it, so I tried to cancel my message, but apparently it got through (news message canceling has never been that reliable..). I believe that if you take the time to do some Python programming, you can find out that OO, when used correctly, is not the huge monster your previous languages had led you to believe it is. In Python, you can use just the right amount of OO to make things easier and more sensible, without complicating things with huge inheritance trees and unnecessary polymorphism. Again, sorry about my premature judgement. -- Timo Virkkala -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Terry Reedy schrieb:
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.
You are right. I'm not an OO purist, I just wanted to convince Davor,
that anti-OO purism can be harmful too. It's good for programmers to
have a choice.
Your Four Steps to Python Object Oriented Programming - vars, lists, dicts,
and finally classes is great.
I'm glad you like it :)
--
---
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
---
--
http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Davor schrieb:
I browsed docs a bit today, and they also confirm what I have believed -
that OO is totally secondary in Python.
OO is not secondary in Python. It's secondary for you :) And Python
leaves the choice to you.
In fact,
object/classes/metaclasses are nothing but *dictionaries with identity*
in python.
Eliminating nothing but makes this a true statement :)
Love this approach. In fact, you can very easily implement
your own *OO model* completely separate of Python's OO model... Now I
actually strongly believe that Python's author has introduced the whole
OO model just to attract and make happy OO population...
I believe that your belief is wrong :) Guido van Rossum has introduced
OO to Python because it's a useful concept.
and you can definitely be more productive using Python's structured
programming than Java/C++ OO programming :-)... and Python is probably
the best example why we should have skipped OO all together..
Sigh. Proceed as you like but be aware that dogmatism - OO as well as
anti-OO is always a poor guide. OO wasn't invented as a marketing buzz
but to support programming styles that emerged in non-OO languages to
control the increasing complexity of programs.
so you get a nice program with separate data structures and functions
that operate on these data structures, with modules as containers for
both (again ideally separated). Very simple to do and maintain no matter
what OO preachers tell you...
The bad thing about OO preachers is not OO but preaching. And you
are preaching, too ;)
--
---
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
---
--
http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
[EMAIL PROTECTED] wrote: Then why was C++ invented? What you have described can be done in C, Pascal, and Fortran 90, all of which are generally classified as procedural programming languages. As Lutz and Ascher say in Learning Python, in object-based programming one can pass objects around, use them in expressions, and call their methods. To qualify as being truly object-oriented (OO), though, objects need to also participate in something called an inheritance hierarchy. Again, behavioural inheritiance is something which can be done manually via delegation or function tables. What a language with OO support adds is special syntax for something that you could have done anyway - the OO support just makes it easier and clearer (well, C++ aside). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Davor wrote: data structures and functions that operate on these data structures Eh? What do you think a class is? Py data = range(10) Py list.extend(data, range(5)) Py list.sort(data) Py print data [0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 6, 7, 8, 9] The fact that data.extend(range(5)) and data.sort() are alternative spellings for the second and third lines doesn't change the fact that a class is just a data structure grouped with a bunch of functions that operate on that data structure. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
[EMAIL PROTECTED] schrieb:
Davor is right: even if
you do not want to use it, the stuff is *there* and somebody in your
team will. So definitely there is an audience of programmers that just
do not have an use for all the sophistication and actually are
penalized by it.
No, because Python does not enforce using advanced concepts. You
can write programs that are as simple as in 1991. A group of developers
always has to find some kind of common style with a chance that some
are penalized. This can happen with every language.
There is not much than can be done at the Python level. But I would
see with interest a Python spinoff geared towards simplicity.
I think this would be useless because advanced concepts exist for
a reason. A simplified spin-off would aquire advanced concepts
over time and would just become a clone of Python.
--
---
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
---
--
http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
[EMAIL PROTECTED] wrote: Furthermore, if in Python the algorithm for the reverse function applies to many kinds of objects, it just needs to be coded once, whereas a reverse method would have to provided for each class that uses it (perhaps through inheritance). Indeed, this is why Python not only provides the list.reverse() method to reverse a list in place, but also provides the reversed() function to reverse any sequence: Py lst = list(ABCDEFGHIJ) Py lst.reverse() Py print .join(lst) JIHGFEDCBA Py print .join(reversed(lst)) ABCDEFGHIJ Ditto list.sort() and sorted(). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Peter Maas: [EMAIL PROTECTED] schrieb: Davor is right: even if you do not want to use it, the stuff is *there* and somebody in your team will. So definitely there is an audience of programmers that just do not have an use for all the sophistication and actually are penalized by it. No, because Python does not enforce using advanced concepts. You can write programs that are as simple as in 1991. A group of developers always has to find some kind of common style with a chance that some are penalized. This can happen with every language. No. In theory C++ could be kept as simple as C but in practice it is not. There is not much than can be done at the Python level. But I would see with interest a Python spinoff geared towards simplicity. I think this would be useless because advanced concepts exist for a reason. A simplified spin-off would aquire advanced concepts over time and would just become a clone of Python. And then we will need another simplified spinoff ;) There is always a fight between simplificity and complexity. Some complexity is not needed, and I am sure even in Python something could be dropped. But it is difficult to find what can be removed. Remember that Saint-Exupery quote? Something like a work of art is finished when there is nothing left to remove? M.S. -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
[EMAIL PROTECTED] wrote: ... Some complexity is not needed, and I am sure even in Python something could be dropped. But it is difficult to find what can be removed. Remember that Saint-Exupery quote? Something like a work of art is finished when there is nothing left to remove? Saint-Éxupery was an engineer (and a pioneer of flight) and so he was referring to a designer (and no doubt had in mind those planes...), not to an artist (not his fault if he's better remembered as a novelist;-). As for what can be removed from Python, one could start at http://www.python.org/peps/pep-3000.html -- while each of us will find there some complexity one loves and uses often (be it lambda, buffer, reload, ...), it's a good start. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
PA [EMAIL PROTECTED] wrote: Yes. But even with the best tool and the best intents, projects still fail. In fact, most IT projects are considered failures: http://www.economist.com/business/PrinterFriendly.cfm?Story_ID=3423238 The main thesis of the article you quote (although it acknowledges that other think differently) is that better tools (including iterative, NOT waterfall, development; and, agile programming approaches, more generally) are the way to mitigate that horrid track record. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
[EMAIL PROTECTED] wrote: There is not much than can be done at the Python level. But I would see with interest a Python spinoff geared towards simplicity. I think this would be useless because advanced concepts exist for a reason. A simplified spin-off would aquire advanced concepts over time and would just become a clone of Python. And then we will need another simplified spinoff ;) There is always a fight between simplificity and complexity. Some complexity is not needed, and I am sure even in Python something could be dropped. But it is difficult to find what can be removed. Remember that Saint-Exupery quote? Something like a work of art is finished when there is nothing left to remove? M.S. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. I know this quote because it is the motto of the F programming language http://www.fortran.com/F/ , a simplified spinoff of Fortran 95. -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Thanks, that was it! ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Davor wrote: 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 nicesimple scripting language before seeing all this OO stuff that was added in over time) Many people have answered your question already, but I thought I would share my opinion as well, since I think I understand where you are coming from. What attracted me to Python was not OO at all but the fact that it was somewhat similar to PHP (which I was using heavily at the time) but allowed me to encode certain higher-order programming techniques that PHP simply could not express. In short, I had become interested in functional programming after reading David Mertz's Charming Python tutorials, and after x attempts at trying to port the ideas to PHP, I finally gave up in frustration and started learning Python. At the time, I was decidedly anti-OO. I grew up around a very liberal, punk-rock, nonconformist culture, and the amount of hype around OO made it too easy to hate (and, I suppose, it still does). PHP at the time was 90% procedural; the prevaling attitude (which seems to have changed with the advent of PHP5) was that procedural code is all you need to solve most problems. With web scripting, it kind of makes sense, because (IMHO) objects really don't have much value unless you can hold onto them long enough for them to be useful, and many web scripts just pipe data from one place to another. Packing the data into objects is kind of like putting your possessions into boxes so that you can move them from one room to another and immediately unpack. So, I guess you could say, I learned Python in spite of its rich support for OO. =) It wasn't until I had to implement a large (to me), complex, graphical user interface, that I finally had to get off of my soapbox and realize that I had no better way to create sophisticated GUIs than OO. There are surely non-OO ways to build fancy GUIs, like functional-reactive programming, but a) I don't understand them, and b) I had to get my project done, and used the tools I had and the techniques I knew. At that time, I started learning about Smalltalk and Alan Kay's emphasis on the messaging aspect of OO, and it started making a lot more sense. One of the most difficult tasks sometimes is getting various parts of the screen to update when the user changes a field or clicks a button--in a way that is manageable and doesn't devolve into spaghetti. Aside from GUIs, however, I am rarely confronted with a task where I *need* OO. As a method for encoding abstract data types, it works, but it seems like more fashion than substance. As many have pointed out, the difference between method(obj, args) and obj.method(args) is subtle, and often inconsequential. In Python, you can program with just modules and functions/procedures, and never bother with the fact that you are using objects. Sure, a module is an object, and so is a procedure, but it's not all up in your face like, say, Java's arcane restriction that everything belong to some class. It has been said of Perl programmers that they often dislike abstraction. Sometimes, I really sympathize with this viewpoint. I hate having to use a class that offers no value to the problem whatsoever, merely because an API is hard-wired to use instances of that class. No abstraction can often be better than a bad abstraction, and when it comes to debugging, the last thing you want is a bunch of black boxes. These days, I do use classes and objects in Python, but mainly as a code organization technique, and only when I actually want my code organized that way. I tend to start with the problem at hand, building procedures to remove redundancy and keep my code small and simple. If I start noticing that a lot of procedures revolve around a particular data structure, I refactor them into a class. This way, I avoid creating abstractions that don't fit. It's much more mechanical than any feigned attempt at modeling the real world. I think that functional programming (FP) is a very powerful methodology that can solve a lot of the same problems as OO, and does some things a lot better. FP and OO can live in harmony to some extent, but there are some places where they contradict each other. For instance, FP offers a mind-blowingly powerful tool called pattern matching, which is like a switch/case statement on steroids. OO dogma insists that this violates encapsulation, and that any form of switch/case is evil... replace conditional with polymorphism... replace conditional with polymorphism... replace conditional with polymorphism... replhic On the other hand, implementing something as seemingly simple as a __str__ method in
Re: python without OO
Davor wrote: so you get a nice program with separate data structures and functions that operate on these data structures, with modules as containers for both (again ideally separated). Very simple to do and maintain [...] Replace modules with classes in the above quote, and you have the very essence of object-oriented programming. (What you describe here *is* object-oriented programming, you're just trying to avoid the 'class' statement and use module-objects where 'traditional' OO would use class instances.) Jeff Shannon Technician/Programmer Credit International -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Timo Virkkala wrote: This guy has got to be a troll. No other way to understand. -- Timo Virkkala Not a troll, just another case of premature optimization run amok. -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Davor [EMAIL PROTECTED] wrote: 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... You _gotta_ be kidding -- what do you think, e.g., Wirth's Algorithms plus Data Structures Equals Programs *IS* all about? Alex -- http://mail.python.org/mailman/listinfo/python-list
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 On Tue, 25 Jan 2005 12:38:13 -0700, Brent W. Hughes [EMAIL PROTECTED] wrote: I'd like to get a character from stdin, perform some action, get another character, etc. If I just use stdin.read(1), it waits until I finish typing a whole line before I can get the first character. How do I deal with this? This is exactly what you need: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/134892 Title: getch()-like unbuffered character reading from stdin on both Windows and Unix 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_module_names if 'msvcrt' in bims: # Windows from msvcrt import getch elif 'termios' in bims: # Unix import tty, termios def getch(): fd = sys.stdin.fileno() old_settings = termios.tcgetattr(fd) try: tty.setraw(sys.stdin.fileno()) ch = sys.stdin.read(1) finally: termios.tcsetattr(fd, termios.TCSADRAIN, old_settings) return ch else: raise NotImplementedError, '... fill in Mac Carbon code here' Davor [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] 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 nicesimple scripting language before seeing all this OO stuff that was added in over time) Thanks, Davor 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.fileno() old_settings = termios.tcgetattr(fd) try: tty.setraw(sys.stdin.fileno()) ch = sys.stdin.read(1) finally: termios.tcsetattr(fd, termios.TCSADRAIN, old_settings) return ch class _GetchWindows: def __init__(self): import msvcrt def __call__(self): import msvcrt return msvcrt.getch() getch = _Getch() -- http://mail.python.org/mailman/listinfo/python-list
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 :
somestring = 'fish'
if somestring.startswith('f'):
print 'It does'
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
On 25 Jan 2005 13:49:48 -0800, Davor [EMAIL PROTECTED] wrote: 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 nicesimple scripting language before seeing all this OO stuff that was added in over time) Thanks, Davor 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. :) -- http://mail.python.org/mailman/listinfo/python-list -- Premshree Pillai http://www.livejournal.com/~premshree -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Hello Davor, Also, is anyone aware of any scripting language that could be considered as Python minus OO stuff? 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 [EMAIL PROTECTED] http://tebeka.bizhat.com The only difference between children and adults is the price of the toys -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Davor wrote: 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 nicesimple scripting language before seeing all this OO stuff that was added in over time) Thanks, Davor 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Davor schrieb:
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.
So you think f.write('Hello world') is bloated and file_write(f,'Hello
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__.keys():
ps += '%s: %s\n' % (e, str(self.__dict__[e]))
return ps
class person(printable):
def __init__(self, name, age, sex):
self.name = name
self.age = age
self.sex = sex
class invoice(printable):
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 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
---
--
http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Davor [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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 nicesimple scripting languages free of object oriented contamination. not really, what I need that Python has and bashdos 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, ... The irony here is that the OO approach woven into the warp and woof of Python is what make 1-6 possible. 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... Again, there is nothing additional about the OO in Python. It is the very foundation upon which it is built. ... anyhow, I guess I'll have to constrain what can be included in the code through different policies rather than language limitations... 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Peter Maas wrote:
Davor schrieb:
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.
So you think f.write('Hello world') is bloated and
file_write(f,'Hello 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
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 ...
--
http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Peter Maas [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Davor schrieb:
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.
So you think f.write('Hello world') is bloated and file_write(f,'Hello
world')
is not? This is the minimum amount of OO you will see when using Python.
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.
print *** Davor's evolution towards an OO programmer ***
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Le mercredi 26 Janvier 2005 02:43, Jeff Shannon a écrit : 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 These lines precisely express my thoughts. Most of the difficulties in OO in Java/C++ comes from the all mighty goal of preserving type safety. Type safety is certainly a very desirable goal but it, sometimes, leads to very complex code only to achieve it. The prize is just too high. The design patterns that were supposed to save time through high code reuse oftenly becomes a maintenance nightmare. Something that no one in the company can understand except a few. Instead of trying to fix some domain specific code, you end up trying to fix a supposedly highly reusable code that, oh well, you have to adapt. This is espeacially true if the system had been designed by a big OO-design-patterns enthusiastic programmer geek. I am not saying that design patterns are bad. I think that they are an invaluable gift to OO. I'm only saying that they have indeed a perniciuous and pervert effect in the real world industry. People become religious about it and forget to think about a simple solution ... Being dynamically typed, these kind monster patterns are much less probable. And the Python philosophy and culture is the very contrary to that trend. I've been involved in C++/Java projects for the last 8 years. The first time I met Python, I've been frigthen by its lack of static type safety. But over the time, I've been convinced by seeing clean Python code over and over again. In the end, I could appreciate that being simple leads the way to less bugs, which type safety was supposed to prevent ... Coming from the C++ community, Python had been just like fresh air. It changed me from the nightmare derscribed in that discussion thread. When I think that comapnies pay big money for these kind of monsters after having seen a few ppt slides about it, it makes me shiver. Regards, Francis Girard FRANCE -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
On Jan 26, 2005, at 20:39, Francis Girard wrote: When I think that comapnies pay big money for these kind of monsters after having seen a few ppt slides about it, it makes me shiver. Right... but... since when does an implementation language of any sort save a project from its own doom? Project fails for many reasons but seldomly because one language is better or worst than another one. Cheers -- PA http://alt.textdrive.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Le mercredi 26 Janvier 2005 20:47, PA a écrit : Project fails for many reasons but seldomly because one language is better or worst than another one. I think you're right. But you have to choose the right tools that fit your needs. But I think that's what you meant anyway. Cheers Cheers too, Francis Girard FRANCE -- PA http://alt.textdrive.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
On Wednesday 26 January 2005 18:55, Terry Reedy wrote: 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. I think so too. M.E. Farmer's reflections on management was also a shining piece of gold in this thread. Cheers, Frans -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
On Jan 26, 2005, at 21:35, Francis Girard wrote: Project fails for many reasons but seldomly because one language is better or worst than another one. I think you're right. But you have to choose the right tools that fit your needs. But I think that's what you meant anyway. Yes. But even with the best tool and the best intents, projects still fail. In fact, most IT projects are considered failures: http://www.economist.com/business/PrinterFriendly.cfm?Story_ID=3423238 Cheers -- PA http://alt.textdrive.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Le mercredi 26 Janvier 2005 21:44, PA a écrit : On Jan 26, 2005, at 21:35, Francis Girard wrote: Project fails for many reasons but seldomly because one language is better or worst than another one. I think you're right. But you have to choose the right tools that fit your needs. But I think that's what you meant anyway. Yes. But even with the best tool and the best intents, projects still fail. In fact, most IT projects are considered failures: http://www.economist.com/business/PrinterFriendly.cfm?Story_ID=3423238 Well, let's go back home for some gardening. My wife will be happy. Cheers -- PA http://alt.textdrive.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
In [EMAIL PROTECTED], Frank Bechmann (w) wrote: know what's funny: in the Lua mailing list there is currently a discussion about adding OO to Lua. From my quick glance at the language last year I recall that one can access elements of tables (in Python: dict()) with this syntax: ``tbl.attr`` and it's also possible to put functions into those tables. So it's already a prototype based OO language. Remember: you need objects for an OO language -- classes are optional! Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Nick Coghlan wrote: 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. Then why was C++ invented? What you have described can be done in C, Pascal, and Fortran 90, all of which are generally classified as procedural programming languages. As Lutz and Ascher say in Learning Python, in object-based programming one can pass objects around, use them in expressions, and call their methods. To qualify as being truly object-oriented (OO), though, objects need to also participate in something called an inheritance hierarchy. Whether true OOP is a Good Thing is arguable and depends on the situation. -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
This guy has got to be a troll. No other way to understand. -- Timo Virkkala -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Timo Virkkala wrote: This guy has got to be a troll. No other way to understand. not really - it was not my intention at all - but it seems people get upset whenever this OO stuff is mentioned - and what I did not expect at all at this forum as I believed Python people should not be so OO hardcore (seems not all as quite a few have indicated in their replies)... Nevertheless, I think the discussion has several quite good points! -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Davor == Davor [EMAIL PROTECTED] writes: Davor not really - it was not my intention at all - but it seems Davor people get upset whenever this OO stuff is mentioned - and Davor what I did not expect at all at this forum as I believed Davor Python people should not be so OO hardcore (seems not all Davor as quite a few have indicated in their Davor replies)... Nevertheless, I think the discussion has Davor several quite good points! -- Davor http://mail.python.org/mailman/listinfo/python-list Consider the case of a list, say x = [1,2,3,4] suppose you wanted to reverse the list, so that x becomes [4,3,2,1]. In a procedural language, one might do x = reverse(x) In an OO language such as python, one might do x.reverse() Is the OO way more obscure and complicated, etc? Not really -- it's only a minor syntactical difference. One of the core ideas behind OO programming is that data (the contents of the list 1,2,3,4) and methods (sorting, reversing) are bound together into a single entity, the object. On the face of it, this is rather sensible. You may rightly recoil against unnecessary abstraction and complexity, abuse of multiple inheritance and so on. That's perfectly sensible. But object orientation is probably not the bogey man here. python values readable code that is as simple as possible (but no simpler!) as you seem to. Focus on the actual problem, which is probably not OO programming, but colleagues who are making a design more complex than need be. Indeed, the third chant in the mantra of python is Simple is better than complex. John-Hunters-Computer:~ python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type help, copyright, credits or license for more information. import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
I'd like to thank everyone for their replies. The main important lesson I got is: Python does not have that many issues with misuse of OO as compared to Java/C++ because it's *dynamically* typed language and extremely powerful *dictionary* data structure. I browsed docs a bit today, and they also confirm what I have believed - that OO is totally secondary in Python. In fact, object/classes/metaclasses are nothing but *dictionaries with identity* in python. Love this approach. In fact, you can very easily implement your own *OO model* completely separate of Python's OO model... Now I actually strongly believe that Python's author has introduced the whole OO model just to attract and make happy OO population... In fact, *Python's dynamic type checking mechanisms + dictionary is way more powerful than Java/C++'s static type checking mechanisms + their OO mechanisms* and you can definitely be more productive using Python's structured programming than Java/C++ OO programming :-)... and Python is probably the best example why we should have skipped OO all together.. --- second, instead of playing with OO plagued design principles do as follows: 1. separate data, functionality, and structure from each other as much as you can (in Python only valid structural element I've seen so far is module - ignore objects classes!) 2. do not assume any have identity (even if the underlying language model provides and uses one) - so don't pass them around and crazy stuff... so you get a nice program with separate data structures and functions that operate on these data structures, with modules as containers for both (again ideally separated). Very simple to do and maintain no matter what OO preachers tell you... Davor -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
John Hunter wrote: Davor == Davor [EMAIL PROTECTED] writes: Davor not really - it was not my intention at all - but it seems Davor people get upset whenever this OO stuff is mentioned - and Davor what I did not expect at all at this forum as I believed Davor Python people should not be so OO hardcore (seems not all Davor as quite a few have indicated in their Davor replies)... Nevertheless, I think the discussion has Davor several quite good points! -- Davor http://mail.python.org/mailman/listinfo/python-list Consider the case of a list, say x = [1,2,3,4] suppose you wanted to reverse the list, so that x becomes [4,3,2,1]. In a procedural language, one might do x = reverse(x) In an OO language such as python, one might do x.reverse() Is the OO way more obscure and complicated, etc? Not really -- it's only a minor syntactical difference. One of the core ideas behind OO programming is that data (the contents of the list 1,2,3,4) and methods (sorting, reversing) are bound together into a single entity, the object. On the face of it, this is rather sensible. I think the OO way is slightly more obscure. It's obvious what x = reverse(x) does, but it is not clear unless you have the source code whether x.reverse() reverses x or if it returns a reversed list. If x.reverse() does the former, a disadvantage relative to the procedural approach is that a function can be used in an expression. It is clearer and more concise to write z = reverse(x) + reverse(y) than x.reverse() y.reverse() z = x + y Furthermore, if in Python the algorithm for the reverse function applies to many kinds of objects, it just needs to be coded once, whereas a reverse method would have to provided for each class that uses it (perhaps through inheritance). -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
The object-oriented programming paradigm has an undeserved reputation as being complicated; most of the complexity of languages such as C++ and Java has nothing to do with their object orientation but comes instead from the type declarations and the mechanisms to work around them. This is a prime example of how Scheme's approach of removing restrictions compares with the piling feature on top of feature needed in other languages, such as the C++ template mechanism. Handbook of Programming Languages, Volume IV: Functional and Logic Programming Languages Peter H. Salus, editor 1998 page 63 Similarly, now, Java's generics! -- Regards, Casey -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
beliavsky == beliavsky [EMAIL PROTECTED] writes: beliavsky I think the OO way is slightly more obscure. It's beliavsky obvious what x = reverse(x) does, but it is not clear beliavsky unless you have the source code whether x.reverse() You don't need to read the src, you just need to read the docs help([].reverse) Help on built-in function reverse: reverse(...) L.reverse() -- reverse *IN PLACE* beliavsky reverses x or if it returns a reversed list. If beliavsky x.reverse() does the former, a disadvantage relative to beliavsky the procedural approach is that a function can be used beliavsky in an expression. It is clearer and more concise to beliavsky write beliavsky z = reverse(x) + reverse(y) The distinction is not OO versus procedural, it is a decision about how you choose to write reverse. The python list implementers of the reverse object method could have decided to return a new reversed list rather than do the reverse in place and return None. Then you could have done z = x.reverse() + y.reverse() They could have chosen to reverse the list *in place* and also returned a reference to self rather than None, in which case you could do the above as well. w/o digging up the transcripts from the python-dev mailing list, my guess is that they choose to do it in place for efficiency in memory and cpu, and chose not to return self to prevent user confusion. Ie, if a user was allowed to do 'z = x.reverse() + y.reverse()' they might be surprised to find the side effect of in place modification. Likewise, I could easily write a procedural in place reverse that returns None, in which case 'z = reverse(x) + reverse(y)' would not do what you suggest. My point is that whether a function/method such as reverse operates in place or on a copy, and whether it returns None or a reference to a list is independent of OO vs procedural style and is motivated by considerations of efficiency, readability, and usability. beliavsky Furthermore, if in Python the algorithm for the reverse beliavsky function applies to many kinds of objects, it just beliavsky needs to be coded once, whereas a reverse method would beliavsky have to provided for each class that uses it (perhaps beliavsky through inheritance). True, a generic reverse procedure/function can be applied to any data structure that supports iteration. In the case of python, however, some iterable data structures are mutable (lists, dicts) and some are not (strings, tuples). For mutable sequences, an in place reverse is likely to be more efficient in memory and perhaps CPU than a generic reverse which returns a new copy. So a specialized method reverse applicable to lists (but not strings and tuples) can be a big win. Fortunately, python supports both, allowing you to define a general reverse that works for any object that supports the sequence protocol, as well as to define an object specific reverse method that may be faster in time and space. JDH -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
beliavsky == beliavsky [EMAIL PROTECTED] writes: beliavsky I think the OO way is slightly more obscure. It's beliavsky obvious what x = reverse(x) does, but it is not clear beliavsky unless you have the source code whether x.reverse() beliavsky reverses x or if it returns a reversed list. What make it so clear to you that reverse(x) will always return a reversed list rather than reversing x in place and return nothing? beliavsky It is clearer and more concise to write beliavsky z = reverse(x) + reverse(y) beliavsky than beliavsky x.reverse() beliavsky y.reverse() beliavsky z = x + y This isn't anything to do with OO programming. It is something about using in interface that your audience expects. You have exactly the same problem whether you are using procedural or OO style. It might be a case for functional programming, but that's something off-topic. beliavsky Furthermore, if in Python the algorithm for the reverse beliavsky function applies to many kinds of objects, it just beliavsky needs to be coded once, whereas a reverse method would beliavsky have to provided for each class that uses it (perhaps beliavsky through inheritance). That the reverse() wants to be a function doesn't mean that the thing that reverse() operate on doesn't want to be an object. So this isn't very clear a problem about OO style vs. procedural style, but instead a problem about generic programming style vs. concrete programming style. On the other hand, if the thing that reverse() operate on isn't an object sharing the same interface, it will be more clumsy to implement a generic reverse() that works for all the different kinds of object---even if they share similar interfaces. Try to implement a generic reverse in C when the different type of containers are encoded as different style struct's accessible from different function, and you will understand what I mean. So this is, marginally, a case *for* OO style. Regards, Isaac. -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
On Wed, 2005-01-26 at 22:28 -0500, Davor wrote: I browsed docs a bit today, and they also confirm what I have believed - that OO is totally secondary in Python. In fact, object/classes/metaclasses are nothing but *dictionaries with identity* in python. Love this approach. I was really impressed with the design of the language, especially this bit. I first got it when reading Learning Python 2nd Ed (well *after* I'd been using Python for a while, but it's always good to read even intro books to fill out obvious things you might've missed). I love the way the same It's just a dictionary search principle applies to inheritance, scoped variable lookups, etc. In Python, even metaclasses just operate on the class dictionary. How pleasantly simple :-) - especially how the step from class factory to metaclass is so small and approachable. I also love the way I can chuck a bunch of objects into a functionally styled processing pipeline, say a series of functions that each just return the result of a listcomp/genexp. -- Craig Ringer -- http://mail.python.org/mailman/listinfo/python-list
python without OO
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 nicesimple scripting language before seeing all this OO stuff that was added in over time) Thanks, Davor -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Davor wrote: 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? Sure, but you will got problem with libraries. Some of them are in fact frameworks and need some subclassing or other OO fluff. 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 nicesimple scripting language before seeing all this OO stuff that was added in over time) 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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
Davor [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is it possible to write purely procedural code in Python, ... Of course! or the OO constructs in both language and supporting libraries have got so embedded that it's impossible to avoid them? 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. Also, is anyone aware of any scripting language that could be considered as Python minus OO stuff? Anyone aware? Not I! (As you can see I'm completely new to Python and initially believed it's a nicesimple scripting language before seeing all this OO stuff that was added in over time) 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 nicesimple 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 nicesimple scripting languages free of object oriented contamination. Why would you use an object oriented language if you don't want to? Thomas Bartkus -- http://mail.python.org/mailman/listinfo/python-list
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: (note, I am not an experienced developer, nor the others I'll be working with (even though some think they are:-)) 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. so I prefer preemptively dealing with issue of everyone showing off their OO design skills) Work on that micro-management just a little bit more, that gets the code flowing ;) hth, M.E.Farmer -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
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 nicesimple scripting languages free of object oriented contamination. not really, what I need that Python has and bashdos 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
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 :-) 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 Perhaps pylint (http://www.logilab.org/projects/pylint) or its ilk can help you enforce a coding style Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
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 - 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... (note, I am not an experienced developer, nor the others I'll be working with (even though some think they are:-)) Don't worry we didn't get confused, it was quite clear ;) :-) Also you are telling me you don't have an OO problem, you have a problem with your managment and communication skills. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
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 - 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... 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
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
Re: python without OO
Davor wrote: [...] what I need that Python has and bashdos 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
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.) -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
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 -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
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. -- http://mail.python.org/mailman/listinfo/python-list
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 JavaC++ 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
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 -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: python without OO
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 | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
