Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #25473 > unrolled thread

Encapsulation, inheritance and polymorphism

Back to article view | Back to comp.lang.python

Contents

  Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-17 09:45 +0100
    Re: Encapsulation, inheritance and polymorphism Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-17 06:03 -0400
      Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-17 12:24 +0100
        Re: Encapsulation, inheritance and polymorphism Larry Hudson <orgnut@yahoo.com> - 2012-07-18 00:10 -0700
    Re: Encapsulation, inheritance and polymorphism Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-17 11:30 +0200
      Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-17 12:01 +0100
        Re: Encapsulation, inheritance and polymorphism Dave Angel <d@davea.name> - 2012-07-17 07:23 -0400
        Re: Encapsulation, inheritance and polymorphism Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-17 06:37 -0500
          Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-17 12:44 +0100
            Re: Encapsulation, inheritance and polymorphism Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-17 06:53 -0500
            Re: Encapsulation, inheritance and polymorphism Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-17 14:35 +0100
          Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-17 15:01 +0100
            Re: Encapsulation, inheritance and polymorphism Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-17 09:16 -0500
              Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-17 15:26 +0100
            Re: Encapsulation, inheritance and polymorphism Terry Reedy <tjreedy@udel.edu> - 2012-07-17 13:30 -0400
            Re: Encapsulation, inheritance and polymorphism Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-17 12:57 -0500
        Re: Encapsulation, inheritance and polymorphism Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-17 14:18 +0200
        Re: Encapsulation, inheritance and polymorphism Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-17 14:29 +0100
        Re: Encapsulation, inheritance and polymorphism Roy Smith <roy@panix.com> - 2012-07-17 09:52 -0400
          Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-17 15:23 +0100
            Re: Encapsulation, inheritance and polymorphism Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-17 17:26 +0100
              Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-17 17:46 +0100
            Re: Encapsulation, inheritance and polymorphism Terry Reedy <tjreedy@udel.edu> - 2012-07-17 13:07 -0400
              Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-17 20:29 +0100
                Re: Encapsulation, inheritance and polymorphism Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-17 20:39 +0100
                  Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-17 20:52 +0100
                  Re: Encapsulation, inheritance and polymorphism John Ladasky <john_ladasky@sbcglobal.net> - 2012-08-18 23:05 -0700
                  Re: Encapsulation, inheritance and polymorphism John Ladasky <john_ladasky@sbcglobal.net> - 2012-08-18 23:05 -0700
                Re: Encapsulation, inheritance and polymorphism Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-17 18:57 -0400
            Re: Encapsulation, inheritance and polymorphism Ethan Furman <ethan@stoneleaf.us> - 2012-07-17 10:29 -0700
            Re: Encapsulation, inheritance and polymorphism Chris Angelico <rosuav@gmail.com> - 2012-07-18 04:01 +1000
            Re: Encapsulation, inheritance and polymorphism Tim Chase <python.list@tim.thechases.com> - 2012-07-17 12:51 -0500
            Re: Encapsulation, inheritance and polymorphism Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-17 19:18 +0100
              Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-17 19:36 +0100
                Re: Encapsulation, inheritance and polymorphism Andrew Cooper <amc96@cam.ac.uk> - 2012-07-18 01:46 +0100
                  Re: Encapsulation, inheritance and polymorphism rusi <rustompmody@gmail.com> - 2012-07-17 20:54 -0700
                  Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-18 10:06 +0100
                    Re: Encapsulation, inheritance and polymorphism Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-18 14:01 +0200
                    Re: Encapsulation, inheritance and polymorphism "BartC" <bc@freeuk.com> - 2012-07-19 01:41 +0100
                  Re: Encapsulation, inheritance and polymorphism Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-18 13:05 +0000
                    Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-18 15:40 +0100
                      Re: Encapsulation, inheritance and polymorphism Chris Angelico <rosuav@gmail.com> - 2012-07-19 01:04 +1000
                        Re: Encapsulation, inheritance and polymorphism Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-19 01:22 +0000
                          Re: Encapsulation, inheritance and polymorphism Chris Angelico <rosuav@gmail.com> - 2012-07-19 15:09 +1000
                      Re: Encapsulation, inheritance and polymorphism Ethan Furman <ethan@stoneleaf.us> - 2012-07-18 08:32 -0700
                        Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-18 16:49 +0100
                      Re: Encapsulation, inheritance and polymorphism Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-19 01:34 +0000
                        Re: Encapsulation, inheritance and polymorphism rusi <rustompmody@gmail.com> - 2012-07-18 23:09 -0700
                          Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-19 09:56 +0100
                            Re: Encapsulation, inheritance and polymorphism rusi <rustompmody@gmail.com> - 2012-07-19 08:58 -0700
                          Re: Encapsulation, inheritance and polymorphism Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-19 12:59 +0000
                            Re: Encapsulation, inheritance and polymorphism Roy Smith <roy@panix.com> - 2012-07-19 09:06 -0400
                              Re: Encapsulation, inheritance and polymorphism Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-20 07:24 +0000
                                Re: Encapsulation, inheritance and polymorphism rusi <rustompmody@gmail.com> - 2012-07-20 01:21 -0700
                            Re: Encapsulation, inheritance and polymorphism Paul Rudin <paul.nospam@rudin.co.uk> - 2012-07-19 18:22 +0100
                            Re: Encapsulation, inheritance and polymorphism Tim Chase <python.list@tim.thechases.com> - 2012-07-19 13:20 -0500
                            Re: Encapsulation, inheritance and polymorphism Chris Angelico <rosuav@gmail.com> - 2012-07-20 04:28 +1000
                            Re: Encapsulation, inheritance and polymorphism Tim Chase <python.list@tim.thechases.com> - 2012-07-19 13:50 -0500
                              Re: Encapsulation, inheritance and polymorphism Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-20 08:11 +0000
                                Re: Encapsulation, inheritance and polymorphism Erik Max Francis <max@alcyone.com> - 2012-07-20 02:08 -0700
                                  Re: Encapsulation, inheritance and polymorphism "BartC" <bc@freeuk.com> - 2012-07-20 11:28 +0100
                                    Re: Encapsulation, inheritance and polymorphism Erik Max Francis <max@alcyone.com> - 2012-07-21 14:32 -0700
                                      Re: Encapsulation, inheritance and polymorphism Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-23 16:36 +0000
                            Re: Encapsulation, inheritance and polymorphism Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-19 16:47 -0400
                              Re: Encapsulation, inheritance and polymorphism John Gordon <gordon@panix.com> - 2012-07-19 21:01 +0000
                                Re: Encapsulation, inheritance and polymorphism Chris Angelico <rosuav@gmail.com> - 2012-07-20 08:20 +1000
                                  Re: Encapsulation, inheritance and polymorphism John Gordon <gordon@panix.com> - 2012-07-19 22:23 +0000
                                  Re: Encapsulation, inheritance and polymorphism Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-20 08:27 +0000
                                    Re: Encapsulation, inheritance and polymorphism Virgil Stokes <vs@it.uu.se> - 2012-07-20 11:05 +0200
                                      Re: Encapsulation, inheritance and polymorphism Hans Mulder <hansmu@xs4all.nl> - 2012-07-20 19:45 +0200
                                      Re: Encapsulation, inheritance and polymorphism Erik Max Francis <max@alcyone.com> - 2012-07-21 14:28 -0700
                                    Re: Encapsulation, inheritance and polymorphism Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-20 13:57 -0400
                                Re: Encapsulation, inheritance and polymorphism Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-19 15:13 -0600
                                Re: Encapsulation, inheritance and polymorphism Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-19 17:30 -0400
                                Re: Encapsulation, inheritance and polymorphism Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-20 10:00 +0100
                      Re: Encapsulation, inheritance and polymorphism Terry Reedy <tjreedy@udel.edu> - 2012-07-19 02:11 -0400
                    Re: Encapsulation, inheritance and polymorphism Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-23 16:18 +0000
                      Re: Encapsulation, inheritance and polymorphism Chris Angelico <rosuav@gmail.com> - 2012-07-24 02:15 +1000
                      Re: Encapsulation, inheritance and polymorphism Robert Miles <robertmiles@teranews.com> - 2012-08-19 00:21 -0500
                        Re: Encapsulation, inheritance and polymorphism Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-19 09:55 +0100
                          Re: Encapsulation, inheritance and polymorphism lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-19 12:50 +0100
                            Re: Encapsulation, inheritance and polymorphism Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-19 13:06 +0100
            Re: Encapsulation, inheritance and polymorphism Ethan Furman <ethan@stoneleaf.us> - 2012-07-17 11:43 -0700
            Re: Encapsulation, inheritance and polymorphism Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-17 15:05 -0400
            Re: Encapsulation, inheritance and polymorphism Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-17 20:33 +0100
            Re: Encapsulation, inheritance and polymorphism Ian <hobson42@gmail.com> - 2012-07-17 19:59 +0100
          Re: Encapsulation, inheritance and polymorphism Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-18 12:58 +0000
            Re: Encapsulation, inheritance and polymorphism Roy Smith <roy@panix.com> - 2012-07-18 09:07 -0400
              Re: Encapsulation, inheritance and polymorphism Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-18 14:31 +0000
            Re: Encapsulation, inheritance and polymorphism Dave Angel <d@davea.name> - 2012-07-18 12:33 -0400
              Re: Encapsulation, inheritance and polymorphism Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-19 01:23 +0000
        Re: Encapsulation, inheritance and polymorphism Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-18 12:43 +0000
        Re: Encapsulation, inheritance and polymorphism Grant Edwards <invalid@invalid.invalid> - 2012-07-18 14:34 +0000
          Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-18 15:48 +0100
            Re: Encapsulation, inheritance and polymorphism Chris Angelico <rosuav@gmail.com> - 2012-07-19 01:09 +1000
              Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-18 16:36 +0100
            Re: Encapsulation, inheritance and polymorphism Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-19 01:14 +0000
              Re: Encapsulation, inheritance and polymorphism MRAB <python@mrabarnett.plus.com> - 2012-07-19 02:28 +0100
                Re: Encapsulation, inheritance and polymorphism "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2012-07-19 16:52 +0000
          Re: Encapsulation, inheritance and polymorphism Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-18 10:00 -0500
    Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-17 13:01 +0100
      Re: Encapsulation, inheritance and polymorphism Terry Reedy <tjreedy@udel.edu> - 2012-07-17 13:24 -0400
        Re: Encapsulation, inheritance and polymorphism Lipska the Kat <lipska@lipskathekat.com> - 2012-07-17 19:21 +0100
      Re: Encapsulation, inheritance and polymorphism MRAB <python@mrabarnett.plus.com> - 2012-07-17 18:43 +0100
      Re: Encapsulation, inheritance and polymorphism Tim Chase <python.list@tim.thechases.com> - 2012-07-17 12:56 -0500
      Re: Encapsulation, inheritance and polymorphism Arnaud Delobelle <arnodel@gmail.com> - 2012-07-18 11:35 +0100

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#25571

On 18/07/12 14:05, Steven D'Aprano wrote:
> On Wed, 18 Jul 2012 01:46:31 +0100, Andrew Cooper wrote:
>
>> Take for example a Linux system call handler.  The general form looks a
>> little like (substituting C for python style pseudocode)
>>
>> if not (you are permitted to do this):
>>      return -EPERM
>> if not (you've given me some valid data):
>>      return -EFAULT
>> if not (you've given me some sensible data):
>>      return -EINVAL
>> return actually_try_to_do_something_with(data)
>>I’m feeling a bit fed uI’m feeling a bit fed uI’m feeling a bit fed u
>> How would you program this sort of logic with a single return statement?
>
> That's not terribly hard.
>
> if not (you are permitted to do this):
>      result = -EPERM
> elif not (you've given me some valid data):
>      result = -EFAULT
> elif not (you've given me some sensible data):
>      result = -EINVAL
> else:
>      result = actually_try_to_do_something_with(data)
> return result
>
>
> A better example would involve loops. I used to hate programming in some
> versions of Pascal without a break statement: I needed a guard variable
> to decide whether or not to do anything in the loop!
>
> # pseudo-code
> for i in 1 to 100:
>      if not condition:
>          do_something_useful()
>
>
> Even with a break, why bother continuing through the body of the function
> when you already have the result? When your calculation is done, it's
> done, just return for goodness sake. You wouldn't write a search that
> keeps going after you've found the value that you want, out of some
> misplaced sense that you have to look at every value. Why write code with
> unnecessary guard values and temporary variables out of a misplaced sense
> that functions must only have one exit?

Object Oriented programming is all about encapsulating human concepts in 
a way that makes sense to human beings. Make no mistake, it is NEVER the 
case that a software system is written for any other reason than to 
serve human beings. OO is more than just the mechanics of writing code, 
it's a state of mind.

OO was 'invented' to address the many problems that beset increasingly 
complex software systems. The main problem was maintainability. 
Encapsulating a concept in a clear and concise way makes the code easier 
to understand. Sometimes this means writing code that is not 'optimal' 
for the machine. Good code should be readable as well as efficient but I 
contend that it is better to write something that is clear, concise and 
well encapsulated than always go for the 'meanest dog in the scrapyard' 
approach where a developer is determined to write unreadable code that 
shows how jolly clever he is. More often than not he is forced to admit 
six months down the line that he has no idea what his code does as he 
'forgot' to comment it.

I speak from bitter experience. This approach works for me. I have 
thousands of lines of code operating every day 'in the wild', everything 
from flight booking systems to real time odds arbitrage. Any developer 
who 'gets' OO can read and modify my code and I am very proud of this 
fact ... and I have never been forced to admit that I don't know what I 
wrote six months ago.

If you are writing embedded systems that must have a very limited memory 
footprint then there is a case for conciseness over readability but even 
then it has to be maintainable

Python looks like an interesting language and I will certainly spend 
time getting to know it but at the moment it seems to me that calling it 
an Object Oriented language is just plain misleading.

There, I've said it, trolls and flamers beware, I take no prisoners.

Lipska

-- 
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.

[toc] | [prev] | [next] | [standalone]

#25575

On Thu, Jul 19, 2012 at 12:40 AM, Lipska the Kat
<lipska@lipskathekat.com> wrote:
> Python looks like an interesting language and I will certainly spend time
> getting to know it but at the moment it seems to me that calling it an
> Object Oriented language is just plain misleading.

Python isn't object oriented in the way Java is ("EVERYTHING has to be
in a class! Look, it's all OO now!"). It simply says that, well,
what's the difference? That integer you're holding. That's an object.
Your function is an object. The module you're in, your "global scope",
is an object too, and can be passed around. Python doesn't care about
buzzwords, it cares about making code.

Of course, the simplicity of Python's object model has its costs too.
Every little integer has to be memory-managed and garbage-collected
(eg in CPython, they're all refcounted). That has a performance hit.
But not all that big a hit, and it is so handy when you want your
function to be able to accept, and distinguish between, different
types of object - you don't have to write one version that takes an
integer and a different one that takes a heap object.

ChrisA

[toc] | [prev] | [next] | [standalone]

#25598

On Thu, 19 Jul 2012 01:04:50 +1000, Chris Angelico wrote:

> Python isn't object oriented in the way Java is ("EVERYTHING has to be
> in a class! Look, it's all OO now!").

Actually, Python is more object-oriented than Java. In Python, everything 
is an object. We have no distinction between boxed and unboxed integers, 
for example -- all integers are boxed, always.

(Of course, data structures written in C, for example the array type, can 
encapsulate unboxed native ints. But the array itself is still an object.)

On the other hand, Python doesn't force you to program using an object-
oriented style. If you want to write functional code like Haskell, you 
can. If you want to write Pascal-style procedural code, you can. If you 
prefer an imperative style closer to shell scripting, go right ahead. The 
only one of the major paradigms that Python doesn't naturally support is 
logic programming.

So Python is simultaneously more *and* less object-oriented than Java.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#25605

On Thu, Jul 19, 2012 at 11:22 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Thu, 19 Jul 2012 01:04:50 +1000, Chris Angelico wrote:
>
>> Python isn't object oriented in the way Java is ("EVERYTHING has to be
>> in a class! Look, it's all OO now!").
>
> Actually, Python is more object-oriented than Java. In Python, everything
> is an object. We have no distinction between boxed and unboxed integers,
> for example -- all integers are boxed, always.

That was my point. Less hype about OO but everything really is an object.

ChrisA

[toc] | [prev] | [next] | [standalone]

#25577

Lipska the Kat wrote:
> On 18/07/12 14:05, Steven D'Aprano wrote:
>> Even with a break, why bother continuing through the body of the function
>> when you already have the result? When your calculation is done, it's
>> done, just return for goodness sake. You wouldn't write a search that
>> keeps going after you've found the value that you want, out of some
>> misplaced sense that you have to look at every value. Why write code with
>> unnecessary guard values and temporary variables out of a misplaced sense
>> that functions must only have one exit?
> 
> Object Oriented programming is all about encapsulating human concepts in 
> a way that makes sense to human beings. Make no mistake, it is NEVER the 
> case that a software system is written for any other reason than to 
> serve human beings. OO is more than just the mechanics of writing code, 
> it's a state of mind.

I must admit I have no idea how we went from discussing Single Exit 
functions to the One True Purpose of Object Oriented Programming;  are 
you saying that SE is one of the basic tenets of OO?


> OO was 'invented' to address the many problems that beset increasingly 
> complex software systems. The main problem was maintainability. 
> Encapsulating a concept in a clear and concise way makes the code easier 
> to understand. Sometimes this means writing code that is not 'optimal' 
> for the machine. Good code should be readable as well as efficient but I 
> contend that it is better to write something that is clear, concise and 
> well encapsulated than always go for the 'meanest dog in the scrapyard' 
> approach where a developer is determined to write unreadable code that 
> shows how jolly clever he is. More often than not he is forced to admit 
> six months down the line that he has no idea what his code does as he 
> 'forgot' to comment it.

And one of the many reasons I love Python is that it is so easy to write 
clear, readable, and sometimes concise code (nested list comps are still 
a challenge for me).

. . .

> Python looks like an interesting language and I will certainly spend 
> time getting to know it but at the moment it seems to me that calling it 
> an Object Oriented language is just plain misleading.

Since *everything* in Python is an object, how can you /not/ call it an 
OO language?  Sure, you don't have to use everything as an object -- 
plain functions exist -- kinda ;)  Even functions live in some 
namespace: len() lives in __builtin__, any top level function lives in 
its module, etc.  Oh, and namespaces are objects.

It seems to me that Python is more about providing tools, and then 
staying out of your way.

That works for me.  Maybe it will work for you, too.

~Ethan~

[toc] | [prev] | [next] | [standalone]

#25579

On 18/07/12 16:32, Ethan Furman wrote:
> Lipska the Kat wrote:
>> On 18/07/12 14:05, Steven D'Aprano wrote:
>>> Even with a break, why bother continuing through the body of the
>>> function
>>> when you already have the result? When your calculation is done, it's
>>> done, just return for goodness sake. You wouldn't write a search that
>>> keeps going after you've found the value that you want, out of some
>>> misplaced sense that you have to look at every value. Why write code
>>> with
>>> unnecessary guard values and temporary variables out of a misplaced
>>> sense
>>> that functions must only have one exit?
>>
>> Object Oriented programming is all about encapsulating human concepts
>> in a way that makes sense to human beings. Make no mistake, it is
>> NEVER the case that a software system is written for any other reason
>> than to serve human beings. OO is more than just the mechanics of
>> writing code, it's a state of mind.
>
> I must admit I have no idea how we went from discussing Single Exit
> functions to the One True Purpose of Object Oriented Programming; are
> you saying that SE is one of the basic tenets of OO?

It's my fault, I get carried away sometimes. Maintainable code is one of 
the basic tenets of OO, it all seems so clear to me and I get frustrated 
when I think that others don't see the 'beauty' ... but then I come to 
my senses and realise that there is always another way to do things.

>> Python looks like an interesting language and I will certainly spend
>> time getting to know it but at the moment it seems to me that calling
>> it an Object Oriented language is just plain misleading.
>
> Since *everything* in Python is an object, how can you /not/ call it an
> OO language?

Obviously I can't. I can't make a call as I haven't studied the language 
yet. I just can't get my head around duck typing at the moment as it is 
just so ... different.

> Sure, you don't have to use everything as an object --
> plain functions exist -- kinda ;) Even functions live in some namespace:
> len() lives in __builtin__, any top level function lives in its module,
> etc. Oh, and namespaces are objects.
>
> It seems to me that Python is more about providing tools, and then
> staying out of your way.
>
> That works for me. Maybe it will work for you, too.

I hope so and thank you for being so calm and reasonable in your response.

>
> ~Ethan~

Lipska


-- 
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.

[toc] | [prev] | [next] | [standalone]

#25601

On Wed, 18 Jul 2012 15:40:00 +0100, Lipska the Kat wrote:
[...]
>> Even with a break, why bother continuing through the body of the
>> function when you already have the result? When your calculation is
>> done, it's done, just return for goodness sake. You wouldn't write a
>> search that keeps going after you've found the value that you want, out
>> of some misplaced sense that you have to look at every value. Why write
>> code with unnecessary guard values and temporary variables out of a
>> misplaced sense that functions must only have one exit?
> 
> Object Oriented programming is all about encapsulating human concepts in
> a way that makes sense to human beings. Make no mistake, it is NEVER the
> case that a software system is written for any other reason than to
> serve human beings. OO is more than just the mechanics of writing code,
> it's a state of mind.

Um, yes?

I'm no sure what this has to do with single-exit functions/methods. You 
can just as easily write multi-exit methods in an OO language as in a non-
OO language. So long as your language has a return statement which exits 
the function, you can have more than one.

I am aware that some languages enforce a single exit point, but that 
seems to be an unnecessary restriction to me.

Of course it does require discipline and/or sense to not write crap code: 
if you have a 300 line function or method, whether it has dozens of exits 
or just one, that is crap code in any language. But if the choice is to 
write a 20 line function with three exits, or a 30 line function with a 
single exit, there would have to be a good reason to prefer the single-
exit version.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#25608

On Jul 19, 6:34 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Wed, 18 Jul 2012 15:40:00 +0100, Lipska the Kat wrote:
> > Object Oriented programming is all about encapsulating human concepts in
> > a way that makes sense to human beings. Make no mistake, it is NEVER the
> > case that a software system is written for any other reason than to
> > serve human beings. OO is more than just the mechanics of writing code,
> > it's a state of mind.
>
> Um, yes?

Its not so much a question of language as in programming as language
as in layman-speak.
One characteristic with our field is that we take ordinary words and
then distort them so much the original meaning is completely lost.

Take 'computer' for example.  For Turing a computer was a
mathematician doing a computation with a pen and paper.  He then
showed how to de-skill the mathematician so much that a machine could
do what he was doing.  In trying that he also hit upon the limits of
such 'de-skilling' -- human-computers routinely detect infinite loops,
whereas machine-computers can never do so (in full generality).

Ironically the important lesson is lost and today 'computer' is
synonymous with machine.

Here is Dijkstra on similar distortions with 'user' and
'intelligent':
http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD618.html

'Object' (and OO) are similar messes.

In layman-speak and object is well, a thing.

- subject to space-laws like can only exist at one place at a time,
there cannot be two objects at the same place and time etc.
- subject to time-laws like coming into existence at some time and
going out at some other
- connotes inanimateness unlike other 'creatures' or 'beings'.

When this metaphor works (for example as in guis and simulation) then
we have success-stories like smalltalk and simula.

When it doesn't the success is poorer. eg a programmer writing math
software in/on a OO system may for example 'clone' a matrix.  This may
be good science-fiction; its bad math.

And one of the most pervasive (and stupidist) metaphors is the parent-
child relation of classes.
Just for the record, in the normal world 'creatures/beings' reproduce
and therefore inherit.
Objects dont.

[toc] | [prev] | [next] | [standalone]

#25614

On 19/07/12 07:09, rusi wrote:
> On Jul 19, 6:34 am, Steven D'Aprano<steve
> +comp.lang.pyt...@pearwood.info>  wrote:
>> On Wed, 18 Jul 2012 15:40:00 +0100, Lipska the Kat wrote:
>>> Object Oriented programming is all about encapsulating human concepts in
>>> a way that makes sense to human beings. Make no mistake, it is NEVER the
>>> case that a software system is written for any other reason than to
>>> serve human beings. OO is more than just the mechanics of writing code,
>>> it's a state of mind.
>>
>> Um, yes?

> Its not so much a question of language as in programming as language
> as in layman-speak.
> One characteristic with our field is that we take ordinary words and
> then distort them so much the original meaning is completely lost.
>
> Take 'computer' for example.  For Turing a computer was a
> mathematician doing a computation with a pen and paper.  He then
> showed how to de-skill the mathematician so much that a machine could
> do what he was doing.  In trying that he also hit upon the limits of
> such 'de-skilling' -- human-computers routinely detect infinite loops,
> whereas machine-computers can never do so (in full generality).
>
> Ironically the important lesson is lost and today 'computer' is
> synonymous with machine.
>
> Here is Dijkstra on similar distortions with 'user' and
> 'intelligent':
> http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD618.html
>
> 'Object' (and OO) are similar messes.

Well this is all very interesting.

The terminology is quite concise if you allow it to be
Take "An Object is an instance of a Class"

A Class describes a human concept (be it concrete like a 'Parrot' or 
more abstract like a 'Session') an Object is an actual representation of 
that concept that exists in the memory of a computer (what else should 
we call it). Objects don't exist in the mind of a human, concepts do. A 
class is a way of representing that concept so that other humans can 
understand it. That's it, really, there is no more, anything else is 
implementation.

> In layman-speak and object is well, a thing.

But we are not talking in 'layman-speak' we are discussing concepts that 
are familiar to us in the 'language of the domain' at least I though we 
were. Academic twiddling with the distorted meaning of words spun by 
vested interests is all very interesting I'm sure but doesn't really 
advance the discussion does it?

> - subject to space-laws like can only exist at one place at a time,
> there cannot be two objects at the same place and time etc.
> - subject to time-laws like coming into existence at some time and
> going out at some other
> - connotes inanimateness unlike other 'creatures' or 'beings'.

Well here I have to agree with you. Anyone who invents a 'Person' Class 
should be dismissed forthwith. Parrots are OK though.

> When this metaphor works (for example as in guis and simulation) then
> we have success-stories like smalltalk and simula.
>
> When it doesn't the success is poorer. eg a programmer writing math
> software in/on a OO system may for example 'clone' a matrix.  This may
> be good science-fiction; its bad math.
>
> And one of the most pervasive (and stupidist) metaphors is the parent-
> child relation of classes.
> Just for the record, in the normal world 'creatures/beings' reproduce
> and therefore inherit.

But we are not talking about the 'real world' are we, we are talking 
about representing complex interacting human concepts in a way that can 
be understood by humans and translated into a form that can be executed 
on a binary machine

 > Objects dont.

Well they do, it's a fact, you can call a method on a sub class that 
only exists in the super class. What else would you call it.

Well it's been fun but I have bills to pay so I suppose I'd better do 
some work. TTFN


-- 
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.

[toc] | [prev] | [next] | [standalone]

#25631

On Jul 19, 1:56 pm, Lipska the Kat <lip...@lipskathekat.com> wrote:
> Academic twiddling with the distorted meaning of words spun by
> vested interests is all very interesting I'm sure but doesn't really
> advance the discussion does it?

Well lets back up the discussion a bit. You coming from a Java
background have one view of what OO means. Others coming from a python
background have a different view. In particular you said:

> Python looks like an interesting language and I will certainly spend
> time getting to know it but at the moment it seems to me that calling it
> an Object Oriented language is just plain misleading.


> On 19/07/12 07:09, rusi wrote:
> > In layman-speak and object is well, a thing.
>
> But we are not talking in 'layman-speak' we are discussing concepts that
> are familiar to us in the 'language of the domain' at least I though we
> were.


> > And one of the most pervasive (and stupidist) metaphors is the parent-
> > child relation of classes.
> > Just for the record, in the normal world 'creatures/beings' reproduce
> > and therefore inherit.
>
> But we are not talking about the 'real world' are we, we are talking
> about representing complex interacting human concepts in a way that can
> be understood by humans and translated into a form that can be executed
> on a binary machine

So when multiple technical understandings are in conflict it seems
reasonable to find a frame in which the different viewpoints could
resolve.  The ultimate such frame is the completely de-jargonized
frame ie laymanspeak.  [How far one can/should go toward that ultimate
is another quesion]

[toc] | [prev] | [next] | [standalone]

#25621

On Wed, 18 Jul 2012 23:09:13 -0700, rusi wrote:

> Its not so much a question of language as in programming as language as
> in layman-speak.
> One characteristic with our field is that we take ordinary words and
> then distort them so much the original meaning is completely lost.

All technical fields have jargon. Those jargon terms are often more 
precise than the ordinary terms they are derived from, or have a slightly 
different meaning, or both.

This is not unique to programming, nor is it anything to be disturbed by. 
Words change. What matters is whether the new meanings cause confusion or 
clarity.


> Take 'computer' for example.  For Turing a computer was a mathematician
> doing a computation with a pen and paper.  He then showed how to
> de-skill the mathematician so much that a machine could do what he was
> doing.  In trying that he also hit upon the limits of such 'de-skilling'
> -- human-computers routinely detect infinite loops, whereas
> machine-computers can never do so (in full generality).

Do they really? I doubt that. Human-computers *sometimes* detect infinite 
loops, but there's no evidence that they can detect ∞-loops in full 
generality, or even that they are better at it than electrical computers.

In fact, the sheer number of accidental ∞-loops programmed by human 
beings suggests that people *cannot* routinely detect them, at least not 
without special training, and even then not *routinely*.

Generally people detect ∞-loops with an extremely simple-minded 
heuristic: "if the loop hasn't finished by now, it will never finish".

The fact that we don't, as a general rule, program our computers to 
detect ∞-loops does not mean that they cannot do so at least as well as 
humans, and probably better, when we bother to program them to.

For example, both ML and Haskell can, under some circumstances, report a 
type-error for an infinite loop, *at compile time*.

http://static.usenix.org/publications/library/proceedings/vhll/full_papers/koenig.a

If you think that people can routinely detect infinite loops, then 
perhaps you would care to tell me whether this is an infinite loop or not:

i = 1
while not is_perfect(i):
    i += 2
print "odd perfect number discovered"


where is_perfect() returns True if the integer argument is perfect, and 
False otherwise.

http://mathworld.wolfram.com/PerfectNumber.html
http://mathworld.wolfram.com/OddPerfectNumber.html


 
[...]
> 'Object' (and OO) are similar messes.
> 
> In layman-speak and object is well, a thing.

Define "thing".

Is a cloud a thing? What about a fog bank? An ocean?

A desert? The atmosphere?

Is the paint on your car a thing?

I have an axe that has been passed down for generations through my 
family, from my father, his father before him, and his father, and his 
father before him. Occasionally we replace the handle, or put on a new 
head, but that axe is almost as good as the day my great-great-
grandfather made it.

Is that axe a thing?

Just because laymen toss around a word, doesn't mean that it is a well-
defined, meaningful word.


> When it doesn't the success is poorer. eg a programmer writing math
> software in/on a OO system may for example 'clone' a matrix.  This may
> be good science-fiction; its bad math.

In what way is it bad maths?



> And one of the most pervasive (and stupidist) metaphors is the parent-
> child relation of classes.
> Just for the record, in the normal world 'creatures/beings' reproduce
> and therefore inherit.

Incorrect. In the normal world, "inherit" is used for at least four 
senses:

1) to inherit wealth, property, a title, debts etc. from an ancestor 
   upon their death;

2) to receive or take by birth, to have by nature, physical or mental
   qualities, e.g. "he inherited his tendency to melancholy from his
   father";

3) to come into possession of, e.g. "the meek shall inherit the earth";

4) to receive from a predecessor, e.g. "the Prime Minister has inherited
   an economy in dire straits".

It is clear that the sense of inheritance used in OO programming is sense 
#2, to have by nature.


> Objects dont.

Irrelevant.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#25623

In article <500804cc$0$29978$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> On Wed, 18 Jul 2012 23:09:13 -0700, rusi wrote:
> 
> > Its not so much a question of language as in programming as language as
> > in layman-speak.
> > One characteristic with our field is that we take ordinary words and
> > then distort them so much the original meaning is completely lost.
> 
> All technical fields have jargon. Those jargon terms are often more 
> precise than the ordinary terms they are derived from, or have a slightly 
> different meaning, or both.

Heh.  This reminds me of one of my current pet peeves.  I've run across 
documentation for more than one Python project (django is the one that 
comes to mind, but I'm sure there's others) which misuse words like 
"set" and "list".  They're often used in the generic sense of "a 
collection of things", but they're also the names of specific Python 
data types.  It can sometimes get confusing trying to figure out which 
meaning they intended.

[toc] | [prev] | [next] | [standalone]

#25672

On Thu, 19 Jul 2012 09:06:45 -0400, Roy Smith wrote:

> Heh.  This reminds me of one of my current pet peeves.  I've run across
> documentation for more than one Python project (django is the one that
> comes to mind, but I'm sure there's others) which misuse words like
> "set" and "list".  They're often used in the generic sense of "a
> collection of things", but they're also the names of specific Python
> data types.  It can sometimes get confusing trying to figure out which
> meaning they intended.

Now that is confusing!

Writing good documentation is *hard*. I often end up writing more 
documentation than code, sometimes by a factor of two. Fortunately I love 
to write. As may be obvious.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#25679

On Jul 20, 12:24 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> I often end up writing more
> documentation than code, sometimes by a factor of two. Fortunately I love
> to write. As may be obvious.

Now, now! Really??

[toc] | [prev] | [next] | [standalone]

#25637

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> For example, both ML and Haskell can, under some circumstances, report a 
> type-error for an infinite loop, *at compile time*.

... and in Charity all programs are guaranteed to terminate. Of course
it's not Turing complete.

<http://en.wikipedia.org/wiki/Charity_(programming_language)>

[toc] | [prev] | [next] | [standalone]

#25638

> If you think that people can routinely detect infinite loops, then 
> perhaps you would care to tell me whether this is an infinite loop or not:
> 
> i = 1
> while not is_perfect(i):
>     i += 2
> print "odd perfect number discovered"
> 
> 
> where is_perfect() returns True if the integer argument is perfect, and 
> False otherwise.

Sure it terminates...If you don't run out of RAM to represent the
number "i" in question, there's also this "heat death of the
universe" limit I keep hearing about ;-)

-tkc

[toc] | [prev] | [next] | [standalone]

#25639

On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase
<python.list@tim.thechases.com> wrote:
> Sure it terminates...If you don't run out of RAM to represent the
> number "i" in question, there's also this "heat death of the
> universe" limit I keep hearing about ;-)

I'd be more worried about the heat death of your computer, it's likely
to be sooner. How many people have access to a computer that'll still
be running in ten years, much less a thousand? And while a thousand
years is extremely large, it still falls pitifully short of
infinity[1], or even the heat death of the universe.

ChrisA
[1] http://tools.ietf.org/html/rfc2795

[toc] | [prev] | [next] | [standalone]

#25640

On 07/19/12 13:28, Chris Angelico wrote:
> On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase
> <python.list@tim.thechases.com> wrote:
>> Sure it terminates...If you don't run out of RAM to represent the
>> number "i" in question, there's also this "heat death of the
>> universe" limit I keep hearing about ;-)
> 
> I'd be more worried about the heat death of your computer, it's likely
> to be sooner. How many people have access to a computer that'll still
> be running in ten years, much less a thousand?

Just putting a maximum bound on the problem, providing a time-frame
in which I can be fairly certain that the program will have
terminated. :-)

-tkc

[toc] | [prev] | [next] | [standalone]

#25677

On Thu, 19 Jul 2012 13:50:36 -0500, Tim Chase wrote:

> On 07/19/12 13:28, Chris Angelico wrote:
>> On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase
>> <python.list@tim.thechases.com> wrote:
>>> Sure it terminates...If you don't run out of RAM to represent the
>>> number "i" in question, there's also this "heat death of the universe"
>>> limit I keep hearing about ;-)
>> 
>> I'd be more worried about the heat death of your computer, it's likely
>> to be sooner. How many people have access to a computer that'll still
>> be running in ten years, much less a thousand?
> 
> Just putting a maximum bound on the problem, providing a time-frame in
> which I can be fairly certain that the program will have terminated. :-)

I'm reminded of Graham's Number, which is so large that there aren't 
enough molecules in the universe to write it out as a power tower 
a^b^c^d^..., or even in a tower of hyperpowers a^^b^^c^^d^^... It was the 
provable upper bound to a question to which experts in the field thought 
the most likely answer was ... six.

(The bounds have since been reduced: the lower bound is now 13, and the 
upper bound is *much* smaller than Graham's Number but still 
inconceivably ginormous.)

http://en.wikipedia.org/wiki/Graham%27s_number



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#25687

On 07/20/2012 01:11 AM, Steven D'Aprano wrote:
> On Thu, 19 Jul 2012 13:50:36 -0500, Tim Chase wrote:
>
>> On 07/19/12 13:28, Chris Angelico wrote:
>>> On Fri, Jul 20, 2012 at 4:20 AM, Tim Chase
>>> <python.list@tim.thechases.com>  wrote:
>>>> Sure it terminates...If you don't run out of RAM to represent the
>>>> number "i" in question, there's also this "heat death of the universe"
>>>> limit I keep hearing about ;-)
>>>
>>> I'd be more worried about the heat death of your computer, it's likely
>>> to be sooner. How many people have access to a computer that'll still
>>> be running in ten years, much less a thousand?
>>
>> Just putting a maximum bound on the problem, providing a time-frame in
>> which I can be fairly certain that the program will have terminated. :-)
>
> I'm reminded of Graham's Number, which is so large that there aren't
> enough molecules in the universe to write it out as a power tower
> a^b^c^d^..., or even in a tower of hyperpowers a^^b^^c^^d^^... It was the
> provable upper bound to a question to which experts in the field thought
> the most likely answer was ... six.
>
> (The bounds have since been reduced: the lower bound is now 13, and the
> upper bound is *much* smaller than Graham's Number but still
> inconceivably ginormous.)

You don't even need to go that high.  Even a run-of-the-mill googol 
(10^100) is far larger than the total number of elementary particles in 
the observable Universe.

-- 
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Jabber erikmaxfrancis
   I think it is safe to say that no one understands quantum mechanics.
    -- Richard P. Feynman

[toc] | [prev] | [next] | [standalone]

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

Back to top | Article view | comp.lang.python

csiph-web