[Tutor] Good Taste Question: Using SQLite3 in Python

[Alan Gauld]

On 29/04/15 22:11, Roel Schroeven wrote:
> Alan Gauld schreef op 2015-04-29 18:43:
>> On 29/04/15 17:03, Jugurtha Hadjar wrote:
>>> http://docs.python-guide.org/en/latest/writing/style/#create-an-ignored-variable
>>>
>>
>> I've seen this before and strongly disagree with it.
>
> I disagree with your disagreement. I'll try to explain.
>
>> They are ambiguous, difficult to remember, easy to overlook
>
> I'm not sure what exactly you mean by that.

If something exists in a function, over time somebody will use it.
Especially during debugging, priont is a dangerous tool in these cases.
Simple fact of life. If it exists it should be visible (not too
short or incongruous) Trying to visually scan for _ or even
__ is hard. Also different fonts make _ and __ hard to
distinguish.

>> and if you change your mind and decide you need to use it later
>  > it's a whole new name to go back and introduce
>
> True, but I don't see how that is a problem. At that point the variable
> is only used at one point, so you only have to rename it at that one place.

It is if its only used once - see below.
Renaming the wrong variable (especially ising search./replace
in the editor) is a very common way to introduce new bugs into
working code! Having spent nearly 10 years running 3 different 
maintenance teams I know how easy it is for new programmers(*)
to start changing things they don;t understand, especially
when under time pressure.

(*)And maintenance teams are almost always comprised of a
combination of new or very old (read jaded) programmers.
The top players are reserved for the exciting new stuff!

>> (or worse be tempted to use the  meaningless symbol).
>
> That would be bad indeed, but I think a very minimal amount of
> discipline is enough to avoid that.

Its almost impossible,  A maintenance team is usually working
on a ratio of 10-50,000 lines of code per programmer per project
and typically 3-5 projects. So if you have to hold 50-150,000
lines of code in mind its very easy to slip something in as
a 'quick fix' intending to fix it next time then forget about
it. Especially if you have to check in two bug fixes before
you get to go home tonight....

Maintenance programmers are rarely the people who wrote the
code, and they rarely have much personal pride invested in
the code they have to fix. Even if they are the original
developer they will have moved on to new projects and
fixing 5 year old code is a low priority. Its all about
human nature.


> The whole point of ignored variables is that you don't use them.

That's the point when they are created, but too often a
use is found for these things. The original author is never in a 
position to say 'this will never be used in the future'
that's just too idealistic. And the original author is
very unlikely to be the long tem maintainer. Even in
open-source where people tend to stick with projects
for a few years its not true. In commercial code the
author probably leaves the company within 6 months of
writing the code. He may never even see it go into
production...

> use them, they're not exactly ignored variables. It doesn't matter if
> you use __ once or twice or many times more; all of them are to be ignored.

Absolutely. nothing can be guaranteed to be ignored over
time, to start out with tat asumption is tom lay the seeds
of chaos later.

>  > (looking different is good - you can
>  > detect it easily, looking similar is very, very, bad!)...
>  > its just a horror story waiting to trip you up.
>
> I'm not sure in what way __ can lead to horror stories. Do you have an
> example to fuel my imagination?

None in Python - I've never run a Python maintenance squad,
but I have led assembler, C/C++, SQL, Perl and COBOL: teams.
In every case there have been attempts to use variables that
had been intended to be unused - in some cases randomly 
initialized/unassigned, reassigned etc. I once saw a C
function with the same dummy variable use 4 times - although
that did have a name, but it was a placeholder like x.

But in Perl I've seen the infamous $_ abused many times
(although that's slightly different since it magically takes
on certain values, implicit rather than explicit) Python tries
to avoid these things but the whole _/__ variable scheme is
IMHO one of its worst features.

>  > It's far better to have a short meaningful name that is never
>  > used than a bland, meaningless, generic symbol.
>
> By 'short meaningful name', do you mean something like 'dummy' or
> 'ignorethis' as in
>
> basename, dummy, ext = filename.rpartition('.')
>
> or rather something like
>
> basename, separator, ext = filename.rpartition('.')
>

The latter. or even 'sep' as shorter than 'separator'. At least
it gives some clue to its meaning and can be used later
if needed. Because its not expected to be used typing the
few extra characters once doesn't hurt. But it makes
scaffold code, debug code and extension code much easier
to write.

> In the first case, I prefer __ over dummy exactly because to me it's
> clearer at a glance that the name is one-use only and the value is to be
> ignored.

The intent may be clearer but dummy is much easier to
scan, search for and spot visually.

> In the second case, using a 'real' name like 'separator' means I now
> have to mentally keep track of it since as far as I can see at that
> point it might be used later in the code.

It will get reused anyhow, just accept that and give it a sensible name. 
If you don't intend to use it ignore it.

> To me, using _ or __ decreases the cognitive load because they tell me I
> don't have to remember anything about them, since they're not going to
> be used later. Read and forget.

But they will be. Almost for certain. It's human nature and the nature 
of code maintenance. If it's there somebody will find a use for it. The 
fact that 5 or 10 years earlier the author didn't intend for it to be 
used is immaterial.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos