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

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

Why Python is like C++

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

Contents

  Why Python is like C++ Roy Smith <roy@panix.com> - 2013-12-20 09:19 -0500
    Re: Why Python is like C++ Serhiy Storchaka <storchaka@gmail.com> - 2013-12-20 19:46 +0200
      Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-21 10:44 +1300
        Re: Why Python is like C++ Michael Torrie <torriem@gmail.com> - 2013-12-20 22:25 -0700
          Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-21 21:06 +1300
            Re: Why Python is like C++ Chris Angelico <rosuav@gmail.com> - 2013-12-21 19:17 +1100
            Re: Why Python is like C++ Christian Gollwitzer <auriocus@gmx.de> - 2013-12-21 11:19 +0100
              Re: Why Python is like C++ Tim Chase <tim@thechases.com> - 2013-12-21 08:52 -0600
                Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-22 13:17 +1300
              Re: Why Python is like C++ Tim Chase <python.list@tim.thechases.com> - 2013-12-21 08:43 -0600
                Re: Why Python is like C++ Roy Smith <roy@panix.com> - 2013-12-21 10:59 -0500
                  Re: Why Python is like C++ Tim Chase <python.list@tim.thechases.com> - 2013-12-21 10:29 -0600
                  Re: Why Python is like C++ Chris Angelico <rosuav@gmail.com> - 2013-12-22 06:04 +1100
                Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-22 13:27 +1300
              Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-22 13:14 +1300
            Re: Why Python is like C++ Michael Torrie <torriem@gmail.com> - 2013-12-21 08:46 -0700
              Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-22 13:36 +1300
    Re: Why Python is like C++ Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-21 05:34 +0000
      Re: Why Python is like C++ Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-21 21:09 +1300
        Re: Why Python is like C++ Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-21 08:22 +0000
      Re: Why Python is like C++ Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-21 11:37 +0000
        Re: Why Python is like C++ Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-21 12:12 +0000
    Re: Why Python is like C++ Dan Stromberg <drsalists@gmail.com> - 2013-12-21 00:18 -0800
      Re: Why Python is like C++ Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-21 11:51 +0000
      Re: Why Python is like C++ Roy Smith <roy@panix.com> - 2013-12-21 10:10 -0500
        Re: Why Python is like C++ Terry Reedy <tjreedy@udel.edu> - 2013-12-21 17:03 -0500
          Re: Why Python is like C++ Roy Smith <roy@panix.com> - 2013-12-21 17:28 -0500
            Re: Why Python is like C++ Terry Reedy <tjreedy@udel.edu> - 2013-12-21 19:20 -0500
    Re: Why Python is like C++ Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-21 08:42 +0000
    Re: Why Python is like C++ Gene Heskett <gheskett@wdtv.com> - 2013-12-21 14:05 -0500

Page 2 of 2 — ← Prev page 1 [2]

#62484

On Sat, 21 Dec 2013 05:34:51 +0000, Mark Lawrence wrote:

> On 20/12/2013 14:19, Roy Smith wrote:
>> http://xkcd.com/1306/
>>
>>
> I believe that to be a very superficial like.  They're unlike in that
> once C++ people have compiled their code they can head down to the pub,

Ah, the good ol' "It compiles, quick, ship it!" school of thought.


-- 
Steven

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

#62488

On 21/12/2013 11:37, Steven D'Aprano wrote:
> On Sat, 21 Dec 2013 05:34:51 +0000, Mark Lawrence wrote:
>
>> On 20/12/2013 14:19, Roy Smith wrote:
>>> http://xkcd.com/1306/
>>>
>>>
>> I believe that to be a very superficial like.  They're unlike in that
>> once C++ people have compiled their code they can head down to the pub,
>
> Ah, the good ol' "It compiles, quick, ship it!" school of thought.
>

Absolutely, everybody knows that successful compilation indicates bug 
free code, which is why statically typed languages are so vastly 
superior to dynamically typed ones, hence why the latter will never 
catch on.  Or do people around here know something I don't? :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

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

#62478

On Fri, Dec 20, 2013 at 9:34 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 20/12/2013 14:19, Roy Smith wrote:
>>
>> http://xkcd.com/1306/
>>
>
> I believe that to be a very superficial like.  They're unlike in that once
> C++ people have compiled their code they can head down to the pub, but
> Python people have to stay at work testing because the compiler hasn't
> caught all potential errors.

Python should be used with static analysis (EG pylint), IMO, for
reliability.  Python should also be used, IMO, with a good set of
automated unit, integration and system tests.

C++ should use automated tests too, but is often used without because
the compilers make it almost reasonable to do without.  The compilers
tend to make it so you don't need static analysis, but it's so cheap
to use static analysis that it's a good idea to do so.

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

#62485

On Sat, 21 Dec 2013 00:18:33 -0800, Dan Stromberg wrote:

> C++ should use automated tests too, but is often used without because
> the compilers make it almost reasonable to do without.

For some definition of "reasonable" that I haven't come across before. 
I'd like to see the compiler that can determine which of the following 
pseudo-code functions is buggy:


# Given the length of the shadow cast when the sun is at
# angle degrees measured from the horizontal, return the
# height of the thing casting the shadow.

def calculate_height(length:float, angle:float):float;
    if not 0.0 <= angle < 90.0:
        Error, "angle out of range"
    if not length >= 0.0:
        Error, "length cannot be negative"
    return length*sin(degrees_to_radian(angle))

def calculate_height(length:float, angle:float):float;
    if not 0.0 <= angle < 90.0:
        error("angle out of range")
    if not length >= 0.0:
        error("length cannot be negative")
    return length*tan(degrees_to_radian(angle))


-- 
Steven

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

#62496

In article <mailman.4462.1387614224.18130.python-list@python.org>,
 Dan Stromberg <drsalists@gmail.com> wrote:

> On Fri, Dec 20, 2013 at 9:34 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> 
> wrote:
> > On 20/12/2013 14:19, Roy Smith wrote:
> >>
> >> http://xkcd.com/1306/
> >>
> >
> > I believe that to be a very superficial like.  They're unlike in that once
> > C++ people have compiled their code they can head down to the pub, but
> > Python people have to stay at work testing because the compiler hasn't
> > caught all potential errors.
> 
> Python should be used with static analysis (EG pylint), IMO, for
> reliability.  Python should also be used, IMO, with a good set of
> automated unit, integration and system tests.
> 
> C++ should use automated tests too, but is often used without because
> the compilers make it almost reasonable to do without.  The compilers
> tend to make it so you don't need static analysis, but it's so cheap
> to use static analysis that it's a good idea to do so.

On the last large C++ project I worked on, we decided (i.e. obeyed a 
corporate mandate) to start using Coverity's static analysis tool on our 
15 year old codebase.  I learned a few things about static analysis then.

1) It finds bugs you would never find yourself.

2) If your code does tricky things, you can fool the static analyzer, 
leading to false positives.  Presumably, it also leads to false 
negatives, but you don't know about those :-(

3) If you're going to use static analysis, probably the best way is to 
start using it from day one.  Trying to duct-tape a static analysis step 
into your development process for a legacy codebase is probably more 
effort than it's worth.

4) I suspect static analysis does a lot better on a language like Java 
(which has introspection) than it does on C++.  One of the biggest 
problems is that the preprocessor means the code that compiles is not 
the code that you look at.

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

#62515

On 12/21/2013 10:10 AM, Roy Smith wrote:

> On the last large C++ project I worked on, we decided (i.e. obeyed a
> corporate mandate) to start using Coverity's static analysis tool on our
> 15 year old codebase.  I learned a few things about static analysis then.

CPython was about that old when Coverity started giving us reports on 
the C part of CPython (about 400000 loc). CPython is now essentially 
free of errors detected by Coverity.

> 1) It finds bugs you would never find yourself.

Coverity apparently found several for CPython.

> 2) If your code does tricky things, you can fool the static analyzer,
> leading to false positives.

One can define code patterns that are false positives, to silence such 
reports.

>  Presumably, it also leads to false
> negatives, but you don't know about those :-(

We use unit tests to find logic bugs ;-).

> 3) If you're going to use static analysis, probably the best way is to
> start using it from day one.  Trying to duct-tape a static analysis step
> into your development process for a legacy codebase is probably more
> effort than it's worth.

Some of the C coders on the development team thought it *was* for 
CPython. The fact that CPython has been compiled for, say, 20 different 
systems may have meant that it already depended less on 
'implementation-defined' behavior.

-- 
Terry Jan Reedy

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

#62516

In article <mailman.4486.1387663424.18130.python-list@python.org>,
 Terry Reedy <tjreedy@udel.edu> wrote:

> On 12/21/2013 10:10 AM, Roy Smith wrote:
> 
> > On the last large C++ project I worked on, we decided (i.e. obeyed a
> > corporate mandate) to start using Coverity's static analysis tool on our
> > 15 year old codebase.  I learned a few things about static analysis then.
> 
> CPython was about that old when Coverity started giving us reports on 
> the C part of CPython (about 400000 loc). CPython is now essentially 
> free of errors detected by Coverity.

How many of those errors were real, and how many were "I suppose, 
technically, this isn't quite correct but in real life, it's just never 
going to be an issue?"  I'm not being cynical here; I'm interested to 
know if it really helped.

> > 2) If your code does tricky things, you can fool the static analyzer,
> > leading to false positives.
> 
> One can define code patterns that are false positives, to silence such 
> reports.

Yes, we did some of those.

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

#62519

On 12/21/2013 5:28 PM, Roy Smith wrote:
> In article <mailman.4486.1387663424.18130.python-list@python.org>,
>   Terry Reedy <tjreedy@udel.edu> wrote:
>
>> On 12/21/2013 10:10 AM, Roy Smith wrote:
>>
>>> On the last large C++ project I worked on, we decided (i.e. obeyed a
>>> corporate mandate) to start using Coverity's static analysis tool on our
>>> 15 year old codebase.  I learned a few things about static analysis then.
>>
>> CPython was about that old when Coverity started giving us reports on
>> the C part of CPython (about 400000 loc). CPython is now essentially
>> free of errors detected by Coverity.
>
> How many of those errors were real, and how many were "I suppose,
> technically, this isn't quite correct but in real life, it's just never
> going to be an issue?"  I'm not being cynical here; I'm interested to
> know if it really helped.

http://search.gmane.org/ search gmane.comp.python.devel for 'Coverity' 
and you should get some relevant hits.


-- 
Terry Jan Reedy

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

#62479

On 21/12/2013 08:18, Dan Stromberg wrote:
> On Fri, Dec 20, 2013 at 9:34 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> On 20/12/2013 14:19, Roy Smith wrote:
>>>
>>> http://xkcd.com/1306/
>>>
>>
>> I believe that to be a very superficial like.  They're unlike in that once
>> C++ people have compiled their code they can head down to the pub, but
>> Python people have to stay at work testing because the compiler hasn't
>> caught all potential errors.
>
> Python should be used with static analysis (EG pylint), IMO, for
> reliability.  Python should also be used, IMO, with a good set of
> automated unit, integration and system tests.
>

I use the Pydev plugin for Eclipse and have Pylint turned on so that it 
automatically checks my code as I type, just awesome.  To me your second 
sentence above goes without saying.  And add in anything that can help 
improve quality.  This recipe 
http://code.activestate.com/recipes/578793-more-strict-unittests-using-a-validator/ 
only went up yesterday, haven't checked it out in detail but the idea 
seems impressive.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

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

#62507

On Saturday 21 December 2013 13:57:37 Tim Chase did opine:

> On 2013-12-21 08:43, Tim Chase wrote:
> > Then there's the 6502 assembly on that Apple with its 2 user-facing
> > registers (plus the Instruction Pointer and Stack Pointer), so I
> > guess you could say that it has 1-bit variable names ;-)
> 
> Doh, forgot momentarily that the 6502 had X, Y, and A, making THREE
> registers.  ooh, the luxury of 2-bit naming conventions! :-D
> 
> -tkc

And the HD63C09EP kicks them both clear out of the game. Too bad Hitachi is 
to this day, contractually enjoined from even admitting that the new 
registers it sports, or the new, much faster instructions it supports are 
actually in the chip. Like how about a 32 bit value, divided by a 16 bit 
value, 39 clocks worst case?  In a supposedly 8 bit cpu.  Lots of little 
surprises in that 40 pin block of epoxy that was supposed to be a work-a-
like of the Motorola MC6809EP.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Be cheerful while you are alive.
		-- Phathotep, 24th Century B.C.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web