Is Python an object based programming langauge?

[Bengt Richter]

On Wed, 13 Mar 2002 13:59:28 +0100, anton at vredegoor.doge.nl (Anton Vredegoor) wrote:

>On 11 Mar 2002 07:31:55 -0800, drevenhaug at hotmail.com (Graz Bukanoff)
>wrote:
>
>>Is Python an object based programming langauge?
>
>Short answer:
>
>Yes, but at least for me there can be some confusion originating from
>factors that have to do with graphical user interfaces.
>
>Long answer:
>
>Some modern programming IDE's (integrated development environments)
>are trying to adapt the way user thinks to the way the computer works.
>A computer is a thing that is in an infinite loop where sometimes
>events can trigger certain actions. 
>
>For example in the old days of Borland Pascal or Borland C it was easy
>to write a program that did certain things and then exited. 
>
>Now with modern Delphi or C++ Builder its a real accomplishment to
>write such a program. It goes directly against the paradigm of always
Sorry, but that is not true of Delphi. Did you ever work Delphi from
the command line? You can easily write console apps that do not use GUI windows:
---
 [17:10] V:\Dwk\bare>type bare.dpr
 program bare;
 {$APPTYPE CONSOLE}
 uses sysutils;
 begin
   Writeln('Hello World ;-)')
 end.

 [17:10] V:\Dwk\bare>dcc32 bare.dpr
 Delphi for Win32  Version 10.0  Copyright (c) 1983,97 Borland International
 bare.DPR(7)
 8 lines, 0.08 seconds, 26328 bytes code, 2145 bytes data.

 [17:10] V:\Dwk\bare>bare
 Hello World ;-)

 [17:11] V:\Dwk\bare>dirf "bare.*(dpr|exe)" .
 02-03-13  17:09         94 V:\Dwk\bare\bare.DPR
 02-03-13  17:10     36,352 V:\Dwk\bare\bare.exe
---

This is on NT4 using Delphi 3.
GUI IDE or command line, don't diss Delphi either way ;-)

>creating a form (a form is a container for graphical objects) whether
>one needs one or not, and since forms are reacting to events one has
>to generate an exiting event. In this view it's also natural to view
>graphical things on the screen as objects, and to have objects react
>to events. (user clicks button)
>
>This idea has become very pervasive and can  be seen in other IDE's
>that are of the GUI kind (graphical user interface). In python most of
>the time objects are not connected to graphical elements on the
>screen. In Delphi, C++ Builder and Visual Basic there are also non
>graphical objects, but these IDE's *start* with graphical objects and
>introduce other objects later.
Not unless that's the way you want to use it. 
>
>In python it is the other way around: It is possible to have graphical
>objects and infinite loops and events but a starting python script is
>often more like the "old" way of programming. This makes it easy to
>try things out. Complex loops and graphics can be added later.
>
Ditto for Delphi.

>Both ways of designing programs have some advantages. Different ways
>of viewing objects -as graphics reacting to events or as
>datacontainers reacting to methodcalls-  can be appropriate. A program
>can be nongraphic but still be object oriented and reacting to events,
>for example a webserver. The resulting confusion sometimes leads to
>not recognizing the object oriented (or object based?) nature of other
>language-IDE combinations.
>
You could also look at the graphics as visual side effects of
"datacontainers reacting to methodcalls" in an OO-designed GUI ;-)

>On the other hand its entirely possible that the source of the
>confusion is something completely different.
>
Well, please don't add to the confusion about Delphi's capabilities ;-)
You could put someone off that might like it ;-)

BTW, note the compile time. It's not a fluke. Big programs go very fast too.
Coming from C++ you will wonder if it actually compiled or not ;-)

Oops, this wasn't sent... here we go.

Regards,
Bengt Richter
(No association with Borland).