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

#27380

On 19/08/12 09:55, Mark Lawrence wrote:
> On 19/08/2012 06:21, Robert Miles wrote:
>> On 7/23/2012 11:18 AM, Albert van der Horst wrote:
>>> In article <5006b48a$0$29978$c3e8da3$5496439d@news.astraweb.com>,
>>> Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

[snip]

>>>> that functions must only have one exit?

[snip[

>
> Surely the first check is your filing system to make sure that you've
> paid the utilties bills so you've got gas and or electricity to apply
> the heat. Either that or you hire Ray Mears to produce the spark needed
> to light the fire :)

I was wondering how long it would be ...

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

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

#27381

On 19/08/2012 12:50, lipska the kat wrote:
> On 19/08/12 09:55, Mark Lawrence wrote:
>> On 19/08/2012 06:21, Robert Miles wrote:
>>> On 7/23/2012 11:18 AM, Albert van der Horst wrote:
>>>> In article <5006b48a$0$29978$c3e8da3$5496439d@news.astraweb.com>,
>>>> Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>
> [snip]
>
>>>>> that functions must only have one exit?
>
> [snip[
>
>>
>> Surely the first check is your filing system to make sure that you've
>> paid the utilties bills so you've got gas and or electricity to apply
>> the heat. Either that or you hire Ray Mears to produce the spark needed
>> to light the fire :)
>
> I was wondering how long it would be ...
>
> lipska
>

Six days shalt thou labour... :)

-- 
Cheers.

Mark Lawrence.

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

#25531

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

Silly me, the word processor would have caught it!

~Ethan~

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

#25533

On Tue, Jul 17, 2012 at 1:07 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> 'type-bondage' is the requirement to restrict function inputs and output to
> one declared type, where the type declaration mechanisms are usually quite
> limited.

This is interesting, I hadn't expected that sort of definition. So
Haskell is not a type-bondage language?

(i.e. it lets you write functions that accept any type via parametric
polymorphism, or any type that supports an interface via type
classes).

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

You write obj.compareTo(other) < 0  instead of using obj < other, and
your methods only work on objects (that support the comparable
interface). Otherwise, no different than Python, I guess.

Would Java not be a type-bondage language if everything was an object?

-- Devin

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

#25535

On 17/07/2012 19:43, Ethan Furman wrote:
> 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? :-)
>
> Silly me, the word processor would have caught it!
>
> ~Ethan~

+1 laugh of the week

-- 
Cheers.

Mark Lawrence.

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

#25537

On 17/07/2012 19:43, Ethan Furman wrote:
> 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? :-)
>
> Silly me, the word processor would have caught it!
>
> ~Ethan~
No compiler can find as many faults as publishing your code on a mailing 
list!!!
  :)

Ian

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

#25566

On Tue, 17 Jul 2012 09:52:59 -0400, Roy Smith wrote:

> you could write in Python:
> 
> # Type matching will get checked at run-time 
> def my_function(mpf, ot):
>    assert isinstance(mpf, MassivelyParallelFrobinator) 
>    assert isinstance(ot, OtherThing)

Keep in mind that assertions are not guaranteed to run. Code like the 
above is buggy, because if Python is run under the -O (optimize) flag, 
assertions will be stripped out.

Assertions are mostly useful for two things:

1) "This cannot possibly happen, but just in case it does..."

If you've ever written something like this:

if x%2 == 0:
    do_spam()
elif x%2 == 1:
    do_ham()
else:
    # This can't happen!
    print("something unexpected happened")
    sys.exit()


that is better written as:

if x%2 == 0:
    do_spam()
else:
    assert x%2 == 1, "something unexpected happened"
    do_ham()


2) To check your internal reasoning in a function or method.

For example:

def foo(something):
    n = len(something)
    x = math.sqrt(x)
    # We expect that x must be less than half of n. 
    # E.g. n=100 gives 10 < 50, which is correct.
    assert x < n//2
    process(n, x)


Run with the -O flag, the (hopefully!) redundant test will be stripped 
out; without the flag, the test will check your logic for you and fail if 
the stated condition is not met.

For bonus points, can you see the mistake? The stated condition is wrong. 
Without the assert, the process() code could go off and potentially 
silently do the wrong thing, but the assert guards against that 
possibility. And once I've had a bug report that my app raises an 
AssertionError, I will go back and think more carefully about the 
assertion that sqrt(n) is always less than half of n.


> but that's just not the way people write code in Python.

Better is to use explicit type checks and raise an exception yourself:

    if not isinstance(x, int):
        raise TypeError('expected an int, got %r' % x)

Better still is to duck-type whenever you can.


-- 
Steven

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

#25568

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

> On Tue, 17 Jul 2012 09:52:59 -0400, Roy Smith wrote:
> 
> > you could write in Python:
> > 
> > # Type matching will get checked at run-time 
> > def my_function(mpf, ot):
> >    assert isinstance(mpf, MassivelyParallelFrobinator) 
> >    assert isinstance(ot, OtherThing)
> 
> Keep in mind that assertions are not guaranteed to run. Code like the 
> above is buggy, because if Python is run under the -O (optimize) flag, 
> assertions will be stripped out.

One could equally say that "code like the above is efficient, because if 
Python is run under the -O (optimize) flag, assertions will be stripped 
out" :-)

> Better is to use explicit type checks and raise an exception yourself:
> 
>     if not isinstance(x, int):
>         raise TypeError('expected an int, got %r' % x)

Maybe, but that's two lines where one does just fine.  If you're going 
to go for type-bondage, you might as well be efficient and succinct 
about it.

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

#25569

On Wed, 18 Jul 2012 09:07:22 -0400, Roy Smith wrote:

>> Keep in mind that assertions are not guaranteed to run. Code like the
>> above is buggy, because if Python is run under the -O (optimize) flag,
>> assertions will be stripped out.
> 
> One could equally say that "code like the above is efficient, because if
> Python is run under the -O (optimize) flag, assertions will be stripped
> out" :-)

You seem to have missed my point. Asserts *should* be used for checks 
which are optional. In this case, the fact that assert is optimized away 
is a feature: you have the added safety of a guard against some 
programming errors, while still being able to optimize that code on 
request. This is what assert is for. You get no argument from me about 
that -- my code is bulging with assertions.

But where you *need* an explicit check to run, assert is not suitable, 
because you cannot control whether or not it will run. The caller, not 
you, controls that, by passing -O to the python interpreter.

If you have a public function or method that can be called by any other 
piece of code, and it has required pre-conditions that need to be checked 
(not necessarily a type-check), then DO NOT USE ASSERT.

If you use assert, then sometimes that pre-condition will not happen, and 
the caller can pass garbage into your function. The pre-condition will be 
violated, and your function will silently go off and do the wrong thing 
without warning.

If you're lucky, your program will fail somewhere else, probably far away 
from where the error actually occurs, and you will merely have to spend 
hours or days trying to debug it.

If you're unlucky, your program won't fail, it will just calculate 
garbage, or otherwise do the wrong thing.

Besides, there is another reason not to use assert: it gives the wrong 
exception. If the error is a type error, you should raise TypeError, not 
ValueError, or ZeroDivisionError, or IndexError, or AssertionError. Using 
assert because it saves a line of code is lazy, sloppy programming.



>> Better is to use explicit type checks and raise an exception yourself:
>> 
>>     if not isinstance(x, int):
>>         raise TypeError('expected an int, got %r' % x)
> 
> Maybe, but that's two lines where one does just fine.

But one line (assert) does *not* do just fine under the conditions I am 
talking about.

If you need the check to run, then assert is not suitable, because it is 
not guaranteed to run. It's as simple as that.


-- 
Steven

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

#25581

On 07/18/2012 08:58 AM, Steven D'Aprano wrote:
> <SNIP>
>
>
> 2) To check your internal reasoning in a function or method.
>
> For example:
>
> def foo(something):
>     n = len(something)
>     x = math.sqrt(x)
>     # We expect that x must be less than half of n. 
>     # E.g. n=100 gives 10 < 50, which is correct.
>     assert x < n//2
>     process(n, x)
>
>
> <SNIP>
> For bonus points, can you see the mistake? The stated condition is wrong. 
> Without the assert, the process() code could go off and potentially 
> silently do the wrong thing, but the assert guards against that 
> possibility. And once I've had a bug report that my app raises an 
> AssertionError, I will go back and think more carefully about the 
> assertion that sqrt(n) is always less than half of n.
>
>

There are actually two bugs in that function.  One is in the assertion,
but more importantly, there's a typo earlier.  One that would give a
traceback, so it would be caught quickly.

UnboundLocalError: local variable 'x' referenced before assignment

Once you change the argument of sqrt() to n, then you come to the
problem you were expecting;  if n has a value of 1, 2, or 3, 4, or 5 the
assertion will fire.

-- 

DaveA

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

#25599

On Wed, 18 Jul 2012 12:33:01 -0400, Dave Angel wrote:

> On 07/18/2012 08:58 AM, Steven D'Aprano wrote:

>> <SNIP>
>> For bonus points, can you see the mistake?
[...]
>>
> There are actually two bugs in that function.  One is in the assertion,
> but more importantly, there's a typo earlier.  One that would give a
> traceback, so it would be caught quickly.
> 
> UnboundLocalError: local variable 'x' referenced before assignment

Good catch :)



-- 
Steven

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

#25565

On Tue, 17 Jul 2012 12:01:21 +0100, Lipska the Kat wrote:

> For the past 9 years I have been developing in Java
[...]
> Anyway, I'm looking at Python as a rapid prototyping language. I have an
> idea and just want to get it down in basic outline code as quickly as
> possible before it departs my aging brain... 

A couple of good resources for you to read, written by a top Python 
developer who also knows Java backwards:

http://dirtsimple.org/2004/12/python-is-not-java.html
http://dirtsimple.org/2004/12/java-is-not-python-either.html


You will occasionally (i.e. about sixteen times a day) read some Python 
programmer tossing out comments like "Flat is better than nested", often 
in quotes. P.J. Eby does this at least twice in the first link above. 
What the hell are they talking about?

They're talking about the Zen of Python, a list of a dozen or so slightly 
tongue in cheek mottoes meant to encapsulate the (often deliberately 
contradictory) coding philosophy that Python developers should aspire 
too. At the interactive Python prompt, enter "import this" (without the 
quotes) and be enlightened.

Keeping the Zen in mind as an ideal is incredibly useful. Arguing over 
whose opinion is more true to the Zen is a waste of time.


> I'm not used to using
> variables without declaring their type ... (well I used to do Visual
> Basic many years ago) It just seems so weird, 

Compared to Java, or Haskell, or Ada, Python may seem like an incredibly 
sloppy language. A lot of that sloppiness comes from the lack of compile-
time type-checking. And that's probably true: Haskell's type checker can 
detect infinite loops, by Jove! Python won't even warn you that you're 
about to blow away a built-in function. (Don't worry though, you can 
easily get it back again.)

(But at least Python isn't Perl, or PHP.)

While Python doesn't (can't!) check the type of data at compile-time, but 
it does check the type of data at run-time. This ain't assembly language, 
where there's only one type, bytes! I came from a Pascal background, and 
at first I found the lack of type declarations rather concerning. But 
soon I found it liberating.

Especially once I started using Python interactively, at the REPL.

Most arguments about which is better, compile-time type checking or run-
time type checking, miss the point: both have advantages, and 
disadvantages. Which is "better" depends on what you want to do.

Python is deliberately designed to be *fast to write*. It gives up a 
little bit of safety for that. But not as much as you might think. Type 
errors are less frequent than other errors (errors of logic, bad data, 
etc.). And so in the time it might take a Java programmer to satisfy the 
compiler's insistence on type correctness, a Python programmer has 
probably written the program *and* the unittests and given the customer 
the first iteration of the application.

At least, that's the theory.

But you probably already know that. After all, that's why Python is the 
rapid-application-development language, not Java.


> and what's this obsession
> with 'correct' indentation of code ???

Nearly everyone rights correctly indented code anyway. At least, those 
who don't, you don't want on your project. Python just takes it one step 
further, and makes correctly indented code mandatory rather than optional.

The plus side is, no more style wars over where the braces go, no more 
hunting for lost braces. The downside is, if you paste code into a dumb 
application (like many email clients!) that strips whitespace, your code 
will break. So don't do that.

http://stromberg.dnsalias.org/~strombrg/significant-whitespace.html



-- 
Steven

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

#25570

On 2012-07-17, Lipska the Kat <lipska@lipskathekat.com> wrote:

> and what's this obsession with 'correct' indentation of code ???

If you can explain to us Java's obsession with 'correct' placemnt of
curly-braces, then you've explained indentation in python.

Unless you're asking about the tabs vs. spaces argument.  In that
case, people who use 4 spaces per level are 'correct'; people who use
a different number of spaces are a bit less correct; people who use
tabs are wrong; and people who mix spaces and tabs -- well, we don't
talk about them in polite company.

-- 
Grant Edwards               grant.b.edwards        Yow! NEWARK has been
                                  at               REZONED!!  DES MOINES has
                              gmail.com            been REZONED!!

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

#25573

On 18/07/12 15:34, Grant Edwards wrote:
> On 2012-07-17, Lipska the Kat<lipska@lipskathekat.com>  wrote:
>
>> and what's this obsession with 'correct' indentation of code ???
>
> If you can explain to us Java's obsession with 'correct' placemnt of
> curly-braces, then you've explained indentation in python.

I'm not getting into the curly braces wars. Life is just too short.

> Unless you're asking about the tabs vs. spaces argument.  In that
> case, people who use 4 spaces per level are 'correct'; people who use
> a different number of spaces are a bit less correct; people who use
> tabs are wrong;

hmm, I've been using tabs ... still, why use one key press when you can 
use 4 ;-).  Actually I quite like this aspect of Python, it's rapidly 
growing on me. Wonder if I could introduce this in a future release of 
Java ... nah, I'd be dead within a week %-(

> and people who mix spaces and tabs -- well, we don't
> talk about them in polite company.
>


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

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

#25576

On Thu, Jul 19, 2012 at 12:48 AM, Lipska the Kat
<lipska@lipskathekat.com> wrote:
> hmm, I've been using tabs ... still, why use one key press when you can use
> 4 ;-).  Actually I quite like this aspect of Python, it's rapidly growing on
> me. Wonder if I could introduce this in a future release of Java ... nah,
> I'd be dead within a week %-(

First let's get Python working properly. The "from __future__ import
braces" statement still doesn't work on any of the released versions.
After that, we can consider fixing Java to do the converse. We must
meet half way, you know.

As to tab vs spaces: I'm a fan of tabs, myself. There was an argument
over the matter last year at work, and we settled on tabs because the
one guy who reckons 1-2 space indent is plenty was then able to just
set his editor to two-space tabs, and the rest of us could use a more
reasonable width. Using tab characters in the file gives this
flexibility. It separates the lexical structure ("this is three blocks
in") from the visual display ("draw these glyphs 35mm from the left
margin").

ChrisA

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

#25578

On 18/07/12 16:09, Chris Angelico wrote:
> On Thu, Jul 19, 2012 at 12:48 AM, Lipska the Kat
> <lipska@lipskathekat.com>  wrote:
>> hmm, I've been using tabs ...

snip

> We must meet half way, you know.

Seems reasonable to me, I'll let you suggest it ;-)

> As to tab vs spaces: I'm a fan of tabs, myself. There was an argument
> over the matter last year at work, and we settled on tabs because the
> one guy who reckons 1-2 space indent is plenty was then able to just
> set his editor to two-space tabs, and the rest of us could use a more
> reasonable width. Using tab characters in the file gives this
> flexibility. It separates the lexical structure ("this is three blocks
> in") from the visual display ("draw these glyphs 35mm from the left
> margin").

OK, I'll set my tab to 4 spaces ...

Lipska

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

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

#25597

On Wed, 18 Jul 2012 15:48:28 +0100, Lipska the Kat wrote:

> On 18/07/12 15:34, Grant Edwards wrote:

>> Unless you're asking about the tabs vs. spaces argument.  In that case,
>> people who use 4 spaces per level are 'correct'; people who use a
>> different number of spaces are a bit less correct; people who use tabs
>> are wrong;
> 
> hmm, I've been using tabs ... still, why use one key press when you can
> use 4 ;-).  

My editor lets me add four spaces with a single key press, and delete 
them again with another single key press.

Personally, I think tabs make more sense for indents than spaces, but for 
compatibility with others who are not as enlightened and insist on using 
broken tools that cannot deal with tabs, I have reluctantly standardised 
on spaces for indentation.


-- 
Steven

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

#25600

On 19/07/2012 02:14, Steven D'Aprano wrote:
> On Wed, 18 Jul 2012 15:48:28 +0100, Lipska the Kat wrote:
>
>> On 18/07/12 15:34, Grant Edwards wrote:
>
>>> Unless you're asking about the tabs vs. spaces argument.  In that case,
>>> people who use 4 spaces per level are 'correct'; people who use a
>>> different number of spaces are a bit less correct; people who use tabs
>>> are wrong;
>>
>> hmm, I've been using tabs ... still, why use one key press when you can
>> use 4 ;-).
>
> My editor lets me add four spaces with a single key press, and delete
> them again with another single key press.
>
> Personally, I think tabs make more sense for indents than spaces, but for
> compatibility with others who are not as enlightened and insist on using
> broken tools that cannot deal with tabs, I have reluctantly standardised
> on spaces for indentation.
>
"""Thus spake the Lord: Thou shalt indent with four spaces. No more, no 
less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent 
thou
two, excepting that thou then proceed to four. Tabs are right out."""
  -- Georg Brandl

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

#25654

MRAB wrote:

> """Thus spake the Lord: Thou shalt indent with four spaces. No
> more, no less.
> Four shall be the number of spaces thou shalt indent, and the
> number of thy indenting shall be four. Eight shalt thou not indent,
> nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right
> out.""" 
>   -- Georg Brandl

    	Yes, and the Lord was Wrong.

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
	--author unknown

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

#25574

On 7/18/2012 9:34 AM, Grant Edwards wrote:
>  people who us tabs are wrong
Don't make me get my flamethrower!
> and people who mix spaces and tabs -- well, we don't
> talk about them in polite company.
Mixing can make sense, but not in Python.

*hides*
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803

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

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

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

csiph-web