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

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

Best practices to overcome python's dynamic data type nature

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

Contents

  Best practices to overcome python's dynamic data type nature Sam <lightaiyee@gmail.com> - 2014-02-14 08:10 -0800
    Re:Best practices to overcome python's dynamic data type nature Dave Angel <davea@davea.name> - 2014-02-14 11:42 -0500
    Re: Best practices to overcome python's dynamic data type nature Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-14 16:39 +0000
    Re: Best practices to overcome python's dynamic data type nature Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-14 16:43 +0000
    Re: Best practices to overcome python's dynamic data type nature Marko Rauhamaa <marko@pacujo.net> - 2014-02-14 18:54 +0200
      Re: Best practices to overcome python's dynamic data type nature Ethan Furman <ethan@stoneleaf.us> - 2014-02-14 09:02 -0800
      Re: Best practices to overcome python's dynamic data type nature Chris Angelico <rosuav@gmail.com> - 2014-02-15 06:42 +1100
    Re: Best practices to overcome python's dynamic data type nature Ethan Furman <ethan@stoneleaf.us> - 2014-02-14 08:32 -0800
      Re: Best practices to overcome python's dynamic data type nature Thomas Heller <theller@ctypes.org> - 2014-02-14 20:50 +0100
        Re: Best practices to overcome python's dynamic data type nature flebber <flebber.crue@gmail.com> - 2014-02-14 20:20 -0800
    Re: Best practices to overcome python's dynamic data type nature Gary Herron <gary.herron@islandtraining.com> - 2014-02-14 09:09 -0800

#66299 — Best practices to overcome python's dynamic data type nature

Dynamic data type has pros and cons. It is easier to program but also easier to create bugs. What are the best practices to reduce bugs caused by Python's dynamic data-type characteristic? Can the experienced Python programmers here advise?

Thank you.

[toc] | [next] | [standalone]

#66302

 Sam <lightaiyee@gmail.com> Wrote in message:
> Dynamic data type has pros and cons. It is easier to program but also easier to create bugs. What are the best practices to reduce bugs caused by Python's dynamic data-type characteristic? Can the experienced Python programmers here advise?
> 
> Thank you.
> 


Claiming that bugs are caused by pythons dynamics type data
 characteristic is like saying that's great, mistakes are caused
 bye for spell checkers.


-- 
DaveA

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

#66303

On 14/02/2014 16:10, Sam wrote:
> Dynamic data type has pros and cons. It is easier to program but also easier to create bugs. What are the best practices to reduce bugs caused by Python's dynamic data-type characteristic? Can the experienced Python programmers here advise?
>
> Thank you.
>

Bugs are caused by the programmer, regardless of the language.  The best 
way of know of avoiding bugs in Python is a combination of running 
Pylint in the Pydev editor as I type (I'd assume other IDEs let you do 
this as well) and testing, more testing and yet more testing.

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

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

#66304

On 14/02/2014 16:42, Dave Angel wrote:
>   Sam <lightaiyee@gmail.com> Wrote in message:
>> Dynamic data type has pros and cons. It is easier to program but also easier to create bugs. What are the best practices to reduce bugs caused by Python's dynamic data-type characteristic? Can the experienced Python programmers here advise?
>>
>> Thank you.
>>
>
>
> Claiming that bugs are caused by pythons dynamics type data
>   characteristic is like saying that's great, mistakes are caused
>   bye for spell checkers.
>
>

Shouldn't that be "spell chequers"? :)

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

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

#66305

Sam <lightaiyee@gmail.com>:

> Dynamic data type has pros and cons. It is easier to program but also
> easier to create bugs. What are the best practices to reduce bugs
> caused by Python's dynamic data-type characteristic? Can the
> experienced Python programmers here advise?

Here's some advice from a very experienced programmer: become a very
experienced programmer.

When you are comfortable with the freedoms a dynamic environment gives
you and know how to use them appropriately, you can perform miracles in
a short time.

I like Java a lot, but boy does the boilerplate get in your way. When
you start writing a feature, you have to produce 2000 lines of code
*before writing a single statement*! That's why experienced Java
programmers tend to resort to code generators.

I'm saying a language has a serious issue if you need a code generator
to use it.


Marko

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

#66309

On 02/14/2014 08:54 AM, Marko Rauhamaa wrote:
>
> Here's some advice from a very experienced programmer: become a very
> experienced programmer.

+1 QOTW

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

#66317

On Sat, Feb 15, 2014 at 3:54 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Sam <lightaiyee@gmail.com>:
>
>> Dynamic data type has pros and cons. It is easier to program but also
>> easier to create bugs. What are the best practices to reduce bugs
>> caused by Python's dynamic data-type characteristic? Can the
>> experienced Python programmers here advise?
>
> Here's some advice from a very experienced programmer: become a very
> experienced programmer.

Definitely.

> I like Java a lot, but boy does the boilerplate get in your way. When
> you start writing a feature, you have to produce 2000 lines of code
> *before writing a single statement*! That's why experienced Java
> programmers tend to resort to code generators.

Also this. It's been shown that, for any given programmer, the number
of bugs per thousand lines of code is approximately stable. This means
that, all other things being equal, a more expressive language will
help you write less buggy code. When you have to write 2000 lines of
boilerplate in a 200 line program, that's 2200 lines that might
potentially be wrong; if, instead, you use a language that requires
just 20 lines of boilerplate for the same number of lines of your
code, that gives you one tenth the total program size and, in very
rough figures, probably about a tenth the number of bugs.

It gets even better than that, though. The more expressive the
language, the easier it is to notice bugs when they do occur. Tell me,
can you see a couple of bugs in this code?

make_combined_color:
push bp
mov bp,sp
mov bx,[bp+8]
cmp bx,16
ja .err
lea ax,[color_data+bx*4+8]
pop bp
ret 8
.err:
; Handle error by returning 0
mov ax,0
pop bp
ret 8

color_data dw 110000, 001011
dw  000000h, 00007Fh, 007F00h, 007F7Fh, 7F0000h, 7F007Fh, 7F7F00h, C0C0C0h
dw 7F7F7Fh, 0000FFh, 00FF00h, 00FFFFh, FF0000h, FF00FFh, FFFF00h, FFFFFFh

No? Isn't it obvious? Hmm, okay. Well, here's a C version:

int color_data[] =
{0x000000,0x00007F,0x007F00,0x007F7F,0x7F0000,0x7F007F,0x7F7F00,0xC0C0C0,
0x7F7F7F,0x0000FF,0x00FF00,0x00FFFF,0xFF0000,0xFF00FF,0xFFFF00,0xFFFFFF};

int make_combined_color(int fg, int bg)
{
    if (fg>ARRAY_SIZE(color_data)) return 0;
    return color_data[fg];
}

If you know C, you should be able to spot a couple of errors here.
(Assume that ARRAY_SIZE gives you the number of elements in an array.
It's an easy enough macro to define, using sizeof.) Now here's the
high level equivalent:

array color_data=({0x000000,0x00007F,0x007F00,0x007F7F,0x7F0000,0x7F007F,0x7F7F00,0xC0C0C0,
0x7F7F7F,0x0000FF,0x00FF00,0x00FFFF,0xFF0000,0xFF00FF,0xFFFF00,0xFFFFFF});

int make_combined_color(int fg, int bg)
{
    return color_data[fg];
}

One of the bugs doesn't even exist now! It's a off-by-one error in
array bounds checking. With the high level code, I'm not checking my
own array bounds, so it's impossible for me to get that wrong. As to
the other bug, it's now patently obvious that it's taking two
arguments and ignoring one of them. That's not necessarily a problem,
but the name make_combined_color suggests that it should be, well,
combining something.

Every line of code you write could potentially have a bug in it. If
you can write less code to achieve your goals, then - all other things
being equal, which of course they never quite are - you'll generally
have less bugs. And of course, when you have something that looks
weird but is intentional (maybe the above function is _supposed_ to
ignore its bg argument, for some reason), you use a code comment.
Here's one of my favourites, just for its brevity:

gc->set_foreground(bg); //(sic)

It's clear from the context this code is in that it's correct to set
the display's foreground color to bg, but since it looks wrong at
first glance, it merits a comment :)

So use a language that lets you say things succinctly and readably
(sorry APL). You'll still make bugs, but you'll be able to spot them
in subsequent editing.

Also: Use source control. Get familiar with a DVCS (I usually
recommend either git or hg for all new projects) and get used to
checking back on the origin of the code. This gives you two benefits:
Firstly, you can know exactly what was written when and why, which
helps hugely when you're trying to figure out whether something's
correct or not. And secondly - more subtly but perhaps more
importantly - it frees you from the need to write all that sort of
thing in code comments. You don't need to retain the history of a
block of code by commenting out the failed attempts; go back to source
control for that. You don't need to predict in advance which bits of
code you'll, in six months time, wonder about. (I guarantee you'll
predict wrong.) When you come to something that seems odd, you look it
up, and *then* add the comments. Consider it a YAGNI policy for
verbiage, if you like. Saves you a huge amount of trouble, and keeps
your source code lean and clean - which, see above, will tend to
reduce your bug count.

Huh. My primary point is "keep your code as short as possible"... and
look how long this post is. That's a textbook example of irony, right
there...

ChrisA

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

#66306

On 02/14/2014 08:10 AM, Sam wrote:
>
> Dynamic data type has pros and cons. It is easier to program but
>  also easier to create bugs. What are the best practices to reduce
>  bugs caused by Python's dynamic data-type characteristic? Can the
>  experienced Python programmers here advise?

Unit tests.

--
~Ethan~

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

#66318

Am 14.02.2014 17:32, schrieb Ethan Furman:
> On 02/14/2014 08:10 AM, Sam wrote:
>>
>> Dynamic data type has pros and cons. It is easier to program but
>>  also easier to create bugs. What are the best practices to reduce
>>  bugs caused by Python's dynamic data-type characteristic? Can the
>>  experienced Python programmers here advise?
>
> Unit tests.

Lint-like tools - there are a few - also help to discover bugs,
even before running or testing the code.  They also help in
other ways to write better code.

Myself I use the 'frosted' tool.

Thomas

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

#66359

Here's a great resource http://www.anrdoezrs.net/click-7079286-11260198?url=http%3A%2F%2Fshop.oreilly.com%2Fproduct%2F0636920029533.do%3Fcmp%3Daf-code-book-product_cj_9781449367794_%7BPID%7D&cjsku=0636920029533

Sayth

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

#66307

On 02/14/2014 08:10 AM, Sam wrote:
> Dynamic data type has pros and cons. It is easier to program but also easier to create bugs. What are the best practices to reduce bugs caused by Python's dynamic data-type characteristic? Can the experienced Python programmers here advise?
>
> Thank you.

The assumptions in that question are misleading.  In fact, Python, with 
it's dynamic nature and other features, allows me to write fewer lines 
of code with fewer bugs-per-line.  That's a win-win situation, not a 
problem which needs to be worked around.

Still, when bugs do creep into code, the best strategy to find them is a 
good testing strategy.

Gary Herron

[toc] | [prev] | [standalone]

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

csiph-web