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 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#25508

On 17/07/2012 15:23, Lipska the Kat wrote:
> On 17/07/12 14:52, Roy Smith wrote:
>> In article<-8SdnVrXGqie25jNnZ2dnUVZ7qKdnZ2d@bt.com>,
>>   Lipska the Kat<lipska@lipskathekat.com>  wrote:
>>
>>> I'm not used to using variables without declaring their type
>>
>> If you truly wanted to recreate this type-bondage style of programming
>> in Python, it's easy enough to do.
>
> snip
>
> Well 'type-bondage' is a strange way of thinking about compile time type
> checking and making code easier to read (and therefor debug) but
> I'm not about to get into some religious war about declaring a variables
> type. I'll just say that I prefer to devote testing efforts to the real
> danger area which in my experience is 'user' input.

Why waste time testing, I thought that the compiler looked after 
everything? :)  But seriously you might want to look at the unittest 
module in the standard library.  There's also a separate mailing list 
for Python testing and I'm sure there's a wiki that compares the 
available tesing tools.  Google and ye shall find!!!

> Clients look dimly on runtime errors however they occur and if I can
> leave it to the compiler to check as much as possible then I'll take that.
>
> I do understand however that compiling an intepreted language doesn't
> really make sense however i'm sure there are interpreted languages that
> allow pre-execution type checking ... aren't there ? Oh yes, there's one
> called Java :-)

There are tools available to help here such as pylint, pychecker and 
pyflakes.  For other modules check out pypi at http://pypi.python.org/pypi

>
> Still, I'm sure you're only kidding around with me :-)

Kidding around on a Python mailing list, never, how dare you Sir, simply 
wouldn't be cricket :-)

>
> Lipska
>

-- 
Cheers.

Mark Lawrence.

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

#25513

On 17/07/12 17:26, Mark Lawrence wrote:
> On 17/07/2012 15:23, Lipska the Kat wrote:
>> On 17/07/12 14:52, Roy Smith wrote:

snip

>>
>> Still, I'm sure you're only kidding around with me :-)
>
> Kidding around on a Python mailing list, never, how dare you Sir, simply
> wouldn't be cricket :-)

As in "The batsman of the Kalahari" no doubt :-)

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

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

#25515

On 7/17/2012 10:23 AM, Lipska the Kat wrote:

> Well 'type-bondage' is a strange way of thinking about compile time type
> checking and making code easier to read (and therefor debug

'type-bondage' is the requirement to restrict function inputs and output 
to one declared type, where the type declaration mechanisms are usually 
quite limited.

 >>> def max(a, b):
	if a <= b: return a
	return b

 >>> max(1,3)
1
 >>> max(3.3, 3.1)
3.1
 >>> max('ab', 'aa')
'aa'
 >>> max([1,1], [1,0])
[1, 0]

and so on, indefinitely. How easy is it to write the same in Java?
Similarly, list.sort sorts any list as long as a < b works for all pairs 
of items in the list.

Function max works for any two objects as long as 'a <= b' works. So the 
'type' of a and b is 'mutually comparable with <='.  How do you declare 
that in Java? How do you declare the type 'non-negative number'? In 
python, putting 'if input >= 0:' as the top effectively 'declares' that 
input must be a number and greater than 0.

> but I'm not about to get into some religious war about declaring a variables
> type.

In Python, *all* data items have a class (type). Names in code do not 
have a type. When they become data items, they are strings. 'Variable' 
is a somewhat fuzzy term or concept in Python.

Since every object is an instance of some class, every class is a 
subclass of class 'object', and an instance of a class is an instance of 
all its classess superclasses; every object is an instance of 'object'. 
So 'object' is the type of all inputs until further restricted. id(ob) 
produces an integer for all objects. str(ob) is intented to produce a 
string representation for all objects. The print functions calls str on 
all its inputs.

> I'll just say that I prefer to devote testing efforts to the real
> danger area which in my experience is 'user' input.
> Clients look dimly on runtime errors however they occur and if I can
> leave it to the compiler to check as much as possible then I'll take that.

import ast
a = ast.literal_eval(input('enter a value: '))
b = ast.literal_eval(input('enter a comparable value: ')
try:
     print('the max of those two is ', max(a,b))
except TypeError:
     print(a, ' and ', b, ' are not comparable')

I suppose

> Still, I'm sure you're only kidding around with me :-)

How easy was it to write max, or a universal sort in Java?

-- 
Terry Jan Reedy

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

#25534

On 17/07/12 18:07, Terry Reedy wrote:
> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>
>> Well 'type-bondage' is a strange way of thinking about compile time type
>> checking and making code easier to read (and therefor debug
>

snip

>
> How easy was it to write max, or a universal sort in Java?
>
Well java.lang.Math.max() (or min() depending on what you want) might do 
it and as for sorting ... java.utils.Collections.sort will sort anything 
that implements the java.util.Comparable interface. All the standard 
numerical classes implement Comparable by default so there is nothing to 
do really.

Lipska

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

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

#25536

On 17/07/2012 20:29, Lipska the Kat wrote:
> On 17/07/12 18:07, Terry Reedy wrote:
>> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>>
>>> Well 'type-bondage' is a strange way of thinking about compile time type
>>> checking and making code easier to read (and therefor debug
>>
>
> snip
>
>>
>> How easy was it to write max, or a universal sort in Java?
>>
> Well java.lang.Math.max() (or min() depending on what you want) might do
> it and as for sorting ... java.utils.Collections.sort will sort anything
> that implements the java.util.Comparable interface. All the standard
> numerical classes implement Comparable by default so there is nothing to
> do really.
>
> Lipska
>

I would like to spend more time on this thread, but unfortunately the 44 
ton artic carrying "Java in a Nutshell Volume 1 Part 1 Chapter 1 
Paragraph 1 Sentence 1" has just arrived outside my abode and needs 
unloading :-)

-- 
Cheers.

Mark Lawrence.

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

#25538

On 17/07/12 20:39, Mark Lawrence wrote:
> On 17/07/2012 20:29, Lipska the Kat wrote:
>> On 17/07/12 18:07, Terry Reedy wrote:
>>> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>>>

snip

>>> How easy was it to write max, or a universal sort in Java?
>>>
>> Well java.lang.Math.max() (or min() depending on what you want) might do
>> it and as for sorting ... java.utils.Collections.sort will sort anything
>> that implements the java.util.Comparable interface. All the standard
>> numerical classes implement Comparable by default so there is nothing to
>> do really.
>>
>> Lipska
>>
>
> I would like to spend more time on this thread, but unfortunately the 44
> ton artic carrying "Java in a Nutshell Volume 1 Part 1 Chapter 1
> Paragraph 1 Sentence 1" has just arrived outside my abode and needs
> unloading :-)

:-)))))))

LOL (and I did) but the pay is FANTASTIC, particularly if you 'get' OO.


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

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

#27348

On Tuesday, July 17, 2012 12:39:53 PM UTC-7, Mark Lawrence wrote:

> I would like to spend more time on this thread, but unfortunately the 44 
> ton artic carrying "Java in a Nutshell Volume 1 Part 1 Chapter 1 
> Paragraph 1 Sentence 1" has just arrived outside my abode and needs 
> unloading :-)

That reminds me of a remark I made nearly 10 years ago:

"Well, I followed one friend's advice and investigated Java, perhaps a little too quickly.  I purchased Ivor Horton's _Beginning_Java_2_ book.  It is reasonably well-written.  But how many pages did I have to read before I got through everything I needed to know, in order to read and write files?  Four hundred!  I need to keep straight detailed information about objects, inheritance, exceptions, buffers, and streams, just to read data from a text file???

I haven't actually sat down to program in Java yet.  But at first glance, it would seem to be a step backwards even from the procedural C programming that I was doing a decade ago.  I was willing to accept the complexity of the Windows GUI, and program with manuals open on my lap.  It is a lot harder for me to accept that I will need to do this in order to process plain old text, perhaps without even any screen output."

https://groups.google.com/d/topic/bionet.software/kk-EGGTHN1M/discussion

Some things never change!  :^)

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

#27353

On Tuesday, July 17, 2012 12:39:53 PM UTC-7, Mark Lawrence wrote:

> I would like to spend more time on this thread, but unfortunately the 44 
> ton artic carrying "Java in a Nutshell Volume 1 Part 1 Chapter 1 
> Paragraph 1 Sentence 1" has just arrived outside my abode and needs 
> unloading :-)

That reminds me of a remark I made nearly 10 years ago:

"Well, I followed one friend's advice and investigated Java, perhaps a little too quickly.  I purchased Ivor Horton's _Beginning_Java_2_ book.  It is reasonably well-written.  But how many pages did I have to read before I got through everything I needed to know, in order to read and write files?  Four hundred!  I need to keep straight detailed information about objects, inheritance, exceptions, buffers, and streams, just to read data from a text file???

I haven't actually sat down to program in Java yet.  But at first glance, it would seem to be a step backwards even from the procedural C programming that I was doing a decade ago.  I was willing to accept the complexity of the Windows GUI, and program with manuals open on my lap.  It is a lot harder for me to accept that I will need to do this in order to process plain old text, perhaps without even any screen output."

https://groups.google.com/d/topic/bionet.software/kk-EGGTHN1M/discussion

Some things never change!  :^)

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

#25543

On Tue, 17 Jul 2012 20:39:53 +0100, Mark Lawrence
<breamoreboy@yahoo.co.uk> declaimed the following in
gmane.comp.python.general:

> 
> I would like to spend more time on this thread, but unfortunately the 44 
> ton artic carrying "Java in a Nutshell Volume 1 Part 1 Chapter 1 
> Paragraph 1 Sentence 1" has just arrived outside my abode and needs 
> unloading :-)

	Blast, and here I thought the cubic foot (and then some) box of
O'Reilly Java books I have in storage was enough to permit one to become
productive in that slavish language [Ada is more "Gentle on My Mind"]
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#25518

Terry Reedy wrote:
> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
> 
>> Well 'type-bondage' is a strange way of thinking about compile time type
>> checking and making code easier to read (and therefor debug
> 
> 'type-bondage' is the requirement to restrict function inputs and output 
> to one declared type, where the type declaration mechanisms are usually 
> quite limited.
> 
>  >>> def max(a, b):
>     if a <= b: return a
>     return b


Surely you meant 'if a >= b: . . .'

No worries, I'm sure your unittests would have caught it.  ;)

~Ethan~

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

#25525

On Wed, Jul 18, 2012 at 12:23 AM, Lipska the Kat
<lipska@lipskathekat.com> wrote:
> Well 'type-bondage' is a strange way of thinking about compile time type
> checking and making code easier to read (and therefor debug) but
> I'm not about to get into some religious war about declaring a variables
> type.

There are options for that, but they aren't Python. (I'd like to see a
"from __future__ import variable_declarations", but it doesn't seem to
work. Yet.) If you're interested, I could tell you about a language
that has a lot of what you're looking for (including polymorphism and
even the ability to declare a variable that can contain "non-negative
integer" as a type), but it's off-topic for the forum. However, I
can't email you, as lipskathekat.com doesn't seem to exist... Email me
privately if you're interested, we can continue the discussion
off-list.

ChrisA

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

#25526

On 07/17/12 12:29, Ethan Furman wrote:
> Terry Reedy wrote:
>> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>>
>>> Well 'type-bondage' is a strange way of thinking about compile time type
>>> checking and making code easier to read (and therefor debug
>>
>> 'type-bondage' is the requirement to restrict function inputs and output 
>> to one declared type, where the type declaration mechanisms are usually 
>> quite limited.
>>
>>  >>> def max(a, b):
>>     if a <= b: return a
>>     return b
> 
> 
> Surely you meant 'if a >= b: . . .'
> 
> No worries, I'm sure your unittests would have caught it.  ;)

Or he could have meant "min" instead of "max".

Or he could have returned the wrong values:

  def max(a, b):
    if a <= b: return b
    return a

:-)

-tkc

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

#25528

On 17/07/2012 18:29, Ethan Furman wrote:
> Terry Reedy wrote:
>> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>>
>>> Well 'type-bondage' is a strange way of thinking about compile time type
>>> checking and making code easier to read (and therefor debug
>>
>> 'type-bondage' is the requirement to restrict function inputs and
>> output to one declared type, where the type declaration mechanisms are
>> usually quite limited.
>>
>>  >>> def max(a, b):
>>     if a <= b: return a
>>     return b
>
>
> Surely you meant 'if a >= b: . . .'
>
> No worries, I'm sure your unittests would have caught it.  ;)
>
> ~Ethan~

Wouldn't the compiler have caught it before the unittests? :-)

-- 
Cheers.

Mark Lawrence.

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

#25530

On 17/07/12 19:18, Mark Lawrence wrote:
> On 17/07/2012 18:29, Ethan Furman wrote:
>> Terry Reedy wrote:
>>> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>>>
>>>> Well 'type-bondage' is a strange way of thinking about compile time
>>>> type
>>>> checking and making code easier to read (and therefor debug
>>>
>>> 'type-bondage' is the requirement to restrict function inputs and
>>> output to one declared type, where the type declaration mechanisms are
>>> usually quite limited.
>>>
>>> >>> def max(a, b):
>>> if a <= b: return a
>>> return b
>>
>>
>> Surely you meant 'if a >= b: . . .'
>>
>> No worries, I'm sure your unittests would have caught it. ;)
>>
>> ~Ethan~
>
> Wouldn't the compiler have caught it before the unittests? :-)
>

Not unless the compiler could read your mind!
The syntax looks fine it's the semantics that are suspect. Wrong is a 
word that I try not to use as it tends to upset people, let's call them 
"differently right" ;-)

BTW having more than one return statement in a block is a little thing I 
know but it drives me nuts ... another "Pythonic" thing I'll have to get 
used to I suppose.

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

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

#25548

On 17/07/2012 19:36, Lipska the Kat wrote:
> On 17/07/12 19:18, Mark Lawrence wrote:
>> On 17/07/2012 18:29, Ethan Furman wrote:
>>> Terry Reedy wrote:
>>>> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>>>>
>>>>> Well 'type-bondage' is a strange way of thinking about compile time
>>>>> type
>>>>> checking and making code easier to read (and therefor debug
>>>>
>>>> 'type-bondage' is the requirement to restrict function inputs and
>>>> output to one declared type, where the type declaration mechanisms are
>>>> usually quite limited.
>>>>
>>>> >>> def max(a, b):
>>>> if a <= b: return a
>>>> return b
>>>
>>>
>>> Surely you meant 'if a >= b: . . .'
>>>
>>> No worries, I'm sure your unittests would have caught it. ;)
>>>
>>> ~Ethan~
>>
>> Wouldn't the compiler have caught it before the unittests? :-)
>>
> 
> Not unless the compiler could read your mind!
> The syntax looks fine it's the semantics that are suspect. Wrong is a
> word that I try not to use as it tends to upset people, let's call them
> "differently right" ;-)
> 
> BTW having more than one return statement in a block is a little thing I
> know but it drives me nuts ... another "Pythonic" thing I'll have to get
> used to I suppose.
> 

Its not a pythonic thing.  Its a common and very acceptable paradigm.

Mainly, it avoids complicated breaks from nested control structures, and
especially the 'style' of maintaining one boolean value called
"should_continue" or something equally silly.

My daily work involves C, x86 assembly, reading x86/PCI/ACPI/etc
specifications and cursing violently at some of the stupidity, Python,
Bash and C++, and this is one of the few styles which remains fairly
constant throughout.

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)

How would you program this sort of logic with a single return statement?
 This is very common logic for all routines for which there is even the
remotest possibility that some data has come from an untrusted source.

~Andrew

P.S. like the sig.

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

#25558

On Jul 18, 5:46 am, Andrew Cooper <am...@cam.ac.uk> wrote:
> On 17/07/2012 19:36, Lipska the Kat wrote:
>
>
>
>
>
>
>
>
>
> > On 17/07/12 19:18, Mark Lawrence wrote:
> >> On 17/07/2012 18:29, Ethan Furman wrote:
> >>> Terry Reedy wrote:
> >>>> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>
> >>>>> Well 'type-bondage' is a strange way of thinking about compile time
> >>>>> type
> >>>>> checking and making code easier to read (and therefor debug
>
> >>>> 'type-bondage' is the requirement to restrict function inputs and
> >>>> output to one declared type, where the type declaration mechanisms are
> >>>> usually quite limited.
>
> >>>> >>> def max(a, b):
> >>>> if a <= b: return a
> >>>> return b
>
> >>> Surely you meant 'if a >= b: . . .'
>
> >>> No worries, I'm sure your unittests would have caught it. ;)
>
> >>> ~Ethan~
>
> >> Wouldn't the compiler have caught it before the unittests? :-)
>
> > Not unless the compiler could read your mind!
> > The syntax looks fine it's the semantics that are suspect. Wrong is a
> > word that I try not to use as it tends to upset people, let's call them
> > "differently right" ;-)
>
> > BTW having more than one return statement in a block is a little thing I
> > know but it drives me nuts ... another "Pythonic" thing I'll have to get
> > used to I suppose.
>
> Its not a pythonic thing.  Its a common and very acceptable paradigm.
>
> Mainly, it avoids complicated breaks from nested control structures, and
> especially the 'style' of maintaining one boolean value called
> "should_continue" or something equally silly.
>
> My daily work involves C, x86 assembly, reading x86/PCI/ACPI/etc
> specifications and cursing violently at some of the stupidity, Python,
> Bash and C++, and this is one of the few styles which remains fairly
> constant throughout.
>
> 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)
>
> How would you program this sort of logic with a single return statement?
>  This is very common logic for all routines for which there is even the
> remotest possibility that some data has come from an untrusted source.

return (-EPERM if not_permitted else -EFAULT if non_valid else -EINVAL
if non_sensible else do_something)

Not that I recommend *doing* this :-)
[I recommend knowing about it]

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

#25561

On 18/07/12 01:46, Andrew Cooper wrote:
> On 17/07/2012 19:36, Lipska the Kat wrote:
>> On 17/07/12 19:18, Mark Lawrence wrote:
>>> On 17/07/2012 18:29, Ethan Furman wrote:
>>>> Terry Reedy wrote:
>>>>> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>>>>>

snip

>
> 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)
>
> How would you program this sort of logic with a single return statement?
>   This is very common logic for all routines for which there is even the
> remotest possibility that some data has come from an untrusted source.

Eeek! well if you insist (type bound)

someType -EPERM
someType -EFAULT
sometype -EINVAL
someType -EDOSOMETHING

//method
someType checkSomething(data){

someType result = -EINVAL //or your most likely or 'safest' result

if not (you are permitted to do this):
       result = -EPERM
if not (you've given me some valid data):
       result = -EFAULT
if not (you've given me some sensible data):
       result = -EINVAL
else
       result = -EDSOMETHING
	
       return result
}
//cohesive, encapsulated, reusable and easy to read

//later

if(checkSomething(data) == EDOSOMETHING){

	actually_try_to_do_something_with(data)
}
else{
	//who knows
}

What do you think ?

>
> ~Andrew
>
> P.S. like the sig.

thanks


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

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

#25564

Am 18.07.2012 11:06, schrieb Lipska the Kat:
> On 18/07/12 01:46, 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)
>>
>> How would you program this sort of logic with a single return statement?
>>   This is very common logic for all routines for which there is even the
>> remotest possibility that some data has come from an untrusted source.
>
> Eeek! well if you insist (type bound)
>
> someType -EPERM
> someType -EFAULT
> sometype -EINVAL
> someType -EDOSOMETHING
>
> //method
> someType checkSomething(data){
>
> someType result = -EINVAL //or your most likely or 'safest' result
>
> if not (you are permitted to do this):
>        result = -EPERM
> if not (you've given me some valid data):
>        result = -EFAULT
> if not (you've given me some sensible data):
>        result = -EINVAL
> else
>        result = -EDSOMETHING
>
>        return result
> }
> //cohesive, encapsulated, reusable and easy to read

This is a classic discussion topic, whether single exit (SE) functions 
should be used or not. There are two things I consider as problematic 
with them:
1. In the presence of exceptions, every function has at least two 
possible paths that can be taken out, one returns a value (or None, in 
Python), the other throws an exception. For that reason, trying to 
achieve SE is a dangerous illusion. The syscall handler above is C, 
which doesn't have exceptions like Java, C++ or Python, so it doesn't 
suffer those two paths.
2. The biggest problem with SE functions is that you often need to skip 
over lots of code before you finally find out that the fault at the very 
beginning causes nothing else to happen inside the function before it is 
finally returned to the caller. A typical symptom is deeply nested 
if-else structures. Another symptom is result variables that are checked 
multiple times to skip over effectively the rest of the function, which 
"unrolls" the nested if-else structures. Yet another symptom is a very 
fine granularity of microscopic functions, which is effectively a 
distributed nest of if-else structures.

Coming back to Python, this would look like this:

    if not /you are permitted to do this/:
        raise NotPermitted("go awai!")
    if not /you've given me valid data/:
        raise TypeError("unexpected input")
    if not /you're given me sensible data/:
        raise ValueError("invalid input")
    # do stuff here...

If you shoehorn this into an SE function (which you can't do if 
something in between might throw), then it probably looks like this:

    error = None
    if not /you are permitted to do this/:
        error = NotPermitted("go awai!")
    elif not /you've given me valid data/:
        raise TypeError("unexpected input")
    elif not /you're given me sensible data/:
        raise ValueError("invalid input")
    else:
        # do stuff here...
    if error:
        raise error
    else:
        return result


> //later
>
> if(checkSomething(data) == EDOSOMETHING){
>
>      actually_try_to_do_something_with(data)
> }
> else{
>      //who knows
> }

Interestingly, you suggest to divide the original function into one that 
verifies some conditions and one that does the actual work. Using an 
early return is to me like drawing a big red line inside a function by 
which it can be split into two sections. This makes it IMHO equally 
clear, even clearer since I don't have to locate and read that other 
function. My bioware parses this so that if the first part succeeds, the 
second part can be read independently thereof, which reduces the amount 
of info to keep in mind at a time.

Also, when changing code, I don't have to locate other places where the 
utility function (checkSomething) is called (Python allows local 
functions, which can be very(!!) useful). Since the code is inline, I 
know that only this one function is affected. Yes, this is in direct 
contrast to the reusability you mentioned. Neither ease of change nor 
reusability are goals in and of themselves though, so this is not a 
black-or-white question and a compromise can be good enough. It's a 
question of taste, experience, phase of the moon, coffeination levels etc.

:)

Uli

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

#25595

"Lipska the Kat" <lipska@lipskathekat.com> wrote in message 
news:c76dnV778_sw4ZvNnZ2dnUVZ8uKdnZ2d@bt.com...
> On 18/07/12 01:46, Andrew Cooper wrote:

>> 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)
>>
>> How would you program this sort of logic with a single return statement?
>>   This is very common logic for all routines for which there is even the
>> remotest possibility that some data has come from an untrusted source.


> someType result = -EINVAL //or your most likely or 'safest' result
>
> if not (you are permitted to do this):
>       result = -EPERM
> if not (you've given me some valid data):
>       result = -EFAULT
> if not (you've given me some sensible data):
>       result = -EINVAL
> else
>       result = -EDSOMETHING
>
>       return result
> }
> //cohesive, encapsulated, reusable and easy to read

But, it works differently from the above. Perhaps replace some of those "if" 
statements with "elif".

The "return" version is handy because it provides a quick escape mechanism 
without cluttering up the rest of code with extra variables.

-- 
Bartc 

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

#25567

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)
> 
> 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?



-- 
Steven

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

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

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

csiph-web