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

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

Re: Strange Behavior

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Strange Behavior robertw89@googlemail.com - 2014-06-02 20:05 +0200
    Re: Strange Behavior Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-03 00:22 +0000
      Re: Strange Behavior Chris Angelico <rosuav@gmail.com> - 2014-06-03 10:30 +1000
      Re: Strange Behavior Igor Korot <ikorot01@gmail.com> - 2014-06-02 17:49 -0700
      Choosing good names for things is difficult (was: Strange Behavior) Ben Finney <ben@benfinney.id.au> - 2014-06-03 10:57 +1000
        Re: Choosing good names for things is difficult (was: Strange Behavior) Rustom Mody <rustompmody@gmail.com> - 2014-06-02 19:06 -0700
          Re: Choosing good names for things is difficult (was: Strange Behavior) Chris Angelico <rosuav@gmail.com> - 2014-06-03 13:33 +1000
      Re: Strange Behavior Peter Otten <__peter__@web.de> - 2014-06-03 10:01 +0200
        Re: Strange Behavior Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-03 11:44 +0000

#72437 — Re: Strange Behavior

[Multipart message — attachments visible in raw view] — view raw

I invoked the wrong bug.py :/ , works fine now (this happens to me when im
a bit tired sometimes...).
Im unsure about the "real" bugreport, will investigate if I find some time
and motivation.

[toc] | [next] | [standalone]

#72451

On Mon, 02 Jun 2014 20:05:29 +0200, robertw89 wrote:

> I invoked the wrong bug.py :/ , works fine now (this happens to me when
> im a bit tired sometimes...).

Clarity in naming is an excellent thing. If you have two files called 
"bug.py", that's two too many.

Imagine having fifty files called "program.py". Which one is which? How 
do you know? Programs should be named by what they do (think of Word, 
which does word processing, or Photoshop, which does photo editing), or 
when that isn't practical, at least give them a unique and memorable name 
(Outlook, Excel). The same applies to files demonstrating bugs.


-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#72452

On Tue, Jun 3, 2014 at 10:22 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 02 Jun 2014 20:05:29 +0200, robertw89 wrote:
>
>> I invoked the wrong bug.py :/ , works fine now (this happens to me when
>> im a bit tired sometimes...).
>
> Clarity in naming is an excellent thing. If you have two files called
> "bug.py", that's two too many.
>
> Imagine having fifty files called "program.py". Which one is which? How
> do you know? Programs should be named by what they do (think of Word,
> which does word processing, or Photoshop, which does photo editing), or
> when that isn't practical, at least give them a unique and memorable name
> (Outlook, Excel). The same applies to files demonstrating bugs.

Heh. I agree, but I've been guilty of this exact problem myself.
Suppose you have a program that segfaults when given certain input, so
you take the input that crashes it, and progressively simplify it
until you have a minimal test-case. What do you call the file that
you're editing? What if you have a few different variants? I've had a
few called "boom" and "boom2" and "booooooom" and so on, because
there's really nothing else to call it - if I knew what the cause of
the crash was, I wouldn't be naming the testcase files, I'd be fixing
the problem.

ChrisA

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

#72453

On Mon, Jun 2, 2014 at 5:30 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Jun 3, 2014 at 10:22 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Mon, 02 Jun 2014 20:05:29 +0200, robertw89 wrote:
>>
>>> I invoked the wrong bug.py :/ , works fine now (this happens to me when
>>> im a bit tired sometimes...).
>>
>> Clarity in naming is an excellent thing. If you have two files called
>> "bug.py", that's two too many.
>>
>> Imagine having fifty files called "program.py". Which one is which? How
>> do you know? Programs should be named by what they do (think of Word,
>> which does word processing, or Photoshop, which does photo editing), or
>> when that isn't practical, at least give them a unique and memorable name
>> (Outlook, Excel). The same applies to files demonstrating bugs.
>
> Heh. I agree, but I've been guilty of this exact problem myself.
> Suppose you have a program that segfaults when given certain input, so
> you take the input that crashes it, and progressively simplify it
> until you have a minimal test-case. What do you call the file that
> you're editing? What if you have a few different variants? I've had a
> few called "boom" and "boom2" and "booooooom" and so on, because
> there's really nothing else to call it - if I knew what the cause of
> the crash was, I wouldn't be naming the testcase files, I'd be fixing
> the problem.


test1, test2, test3, .... testn.
At least it will be unique. ;-)

Thank you.

>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list

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

#72456 — Choosing good names for things is difficult (was: Strange Behavior)

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> On Mon, 02 Jun 2014 20:05:29 +0200, robertw89 wrote:
>
> > I invoked the wrong bug.py :/ , works fine now (this happens to me
> > when im a bit tired sometimes...).
>
> Clarity in naming is an excellent thing […] Programs should be named
> by what they do […] or when that isn't practical, at least give them a
> unique and memorable name […].

It's worth noting, along with this useful admonition, that naming things
well is one of the most difficult things to do.

It is especially difficult in computer software, while also being rather
more important than the typical problem of naming, because of the
simultaneous constraints that the names within computer software should
be:

* Memorable and evocative of the meaning to humans, who have a limited
  capacity for remembering large sets of different names exactly, but a
  high tolerance (even fondness) for multiple-meaning and ambiguous
  words.

  So, choosing unique names is difficult, and the set of memorable names
  is severely limited.

* Starkly unique and exact every time for the computer's use, without
  regard to meaning, and any name is just as memorable to a computer as
  any other.

  So, choosing unique meaningful names is crucially important in working
  with computer software.

That combination – difficult but important to do well – is a perennial
bugbear for programmers.


You can find many essays on the “naming things is difficult” theme, with
the most concise and pithy being attributed to Phil Karlton (RIP) of
Netscape in the 1990s. Another wit takes that to its logical conclusion:

    A well known aphorism attributed to Phil Karlton is:

        There are only two hard things in Computer Science: cache
        invalidation and naming things.

    I realized yesterday that this is really only one hard problem: much
    of the reason that naming things is hard is that changing names is
    hard, so you'd better name something right the first time. Why is it
    hard to rename things? Poor cache invalidation.

    <URL:http://www.jefftk.com/p/cache-invalidation>

-- 
 \              “In the long run, the utility of all non-Free software |
  `\      approaches zero. All non-Free software is a dead end.” —Mark |
_o__)                                                    Pilgrim, 2006 |
Ben Finney

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

#72458 — Re: Choosing good names for things is difficult (was: Strange Behavior)

On Tuesday, June 3, 2014 6:27:25 AM UTC+5:30, Ben Finney wrote:
> Steven D'Aprano  writes:

> > On Mon, 02 Jun 2014 20:05:29 +0200, robertw89 wrote:
> > > I invoked the wrong bug.py :/ , works fine now (this happens to me
> > > when im a bit tired sometimes...).
> > Clarity in naming is an excellent thing […] Programs should be named
> > by what they do […] or when that isn't practical, at least give them a
> > unique and memorable name […].

> It's worth noting, along with this useful admonition, that naming things
> well is one of the most difficult things to do.

> It is especially difficult in computer software, while also being rather
> more important than the typical problem of naming, because of the
> simultaneous constraints that the names within computer software should
> be:

> * Memorable and evocative of the meaning to humans, who have a limited
>   capacity for remembering large sets of different names exactly, but a
>   high tolerance (even fondness) for multiple-meaning and ambiguous
>   words.

>   So, choosing unique names is difficult, and the set of memorable names
>   is severely limited.

> * Starkly unique and exact every time for the computer's use, without
>   regard to meaning, and any name is just as memorable to a computer as
>   any other.

>   So, choosing unique meaningful names is crucially important in working
>   with computer software.

> That combination – difficult but important to do well – is a perennial
> bugbear for programmers.

Add to that the restriction to limited character sets such as ASCII
– a restriction that has only historical relevance 

Somewhat more seriously there is the complement to Ben/Steven's remarks:
Good software systems reduce the naming-demand.

Egs.
1. Computationally/algorithmically, these 2 are equivalent:
   a.
     desc = sqrt(b*b - 4*a*c)
   b. 
     left = b*b
     t1 = 4*a
     right = t1*c
     desc = left - right
     sqrt_desc = sqrt(desc) 

   However the naming load of the b is 5 times a – one of the main
   benefits of a high level language vs assembly
   In the same vein…
2. λ-expressions reduce the need to name functions.
3. Point-free style – or more on-topic "Tacit Programming" –
   reduces the need for function arguments
   http://en.wikipedia.org/wiki/Tacit_programming
4. Structured programming removes the need to name control points with labels
5. And problems like this one can be reduced by using the interpreter
   more and named program files less.  Of course even if you can check
   in the interpreter, to communicate with others/file a bug you may need to
   name a file.

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

#72460 — Re: Choosing good names for things is difficult (was: Strange Behavior)

On Tue, Jun 3, 2014 at 12:06 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> Add to that the restriction to limited character sets such as ASCII
> – a restriction that has only historical relevance

Wrong. The name has to fit inside the human's brain; if it's not
ASCII, that's not a problem.

ChrisA

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

#72487

Steven D'Aprano wrote:

> On Mon, 02 Jun 2014 20:05:29 +0200, robertw89 wrote:
> 
>> I invoked the wrong bug.py :/ , works fine now (this happens to me when
>> im a bit tired sometimes...).
> 
> Clarity in naming is an excellent thing. If you have two files called
> "bug.py", that's two too many.

In the case of the OP the code is likely to be thrown away once the bug is 
found. Putting all experiments into a single folder even with the overly 
generic name "bug" would have been "good enough" to avoid the problem.
 
> Imagine having fifty files called "program.py". Which one is which? How
> do you know? Programs should be named by what they do (think of Word,
> which does word processing, or Photoshop, which does photo editing), or
> when that isn't practical, at least give them a unique and memorable name
> (Outlook, Excel). The same applies to files demonstrating bugs.
 
Outlook and Excel are only good names because these are popular 
applications. If I were to name some private scripts in that style and not 
use them for a few months -- I don't think I'd have a clue what excel.py is 
meant to do. 

I have a few find_dupes dedupe_xxx compare_xxx scripts lying around and no 
idea which is which. So a reasonably clear name is not sufficient if there 
are other scripts that perform similar tasks.

One approach that seems to be working so far is to combine several scripts 
into one using argparse subparsers. This results in more frequent usage 
which means I can get away with short meaningless names, and infrequent 
actions are just one

$ xx -h

away.

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

#72508

On Tue, 03 Jun 2014 10:01:26 +0200, Peter Otten wrote:

> Steven D'Aprano wrote:
> 
>> On Mon, 02 Jun 2014 20:05:29 +0200, robertw89 wrote:
>> 
>>> I invoked the wrong bug.py :/ , works fine now (this happens to me
>>> when im a bit tired sometimes...).
>> 
>> Clarity in naming is an excellent thing. If you have two files called
>> "bug.py", that's two too many.
> 
> In the case of the OP the code is likely to be thrown away once the bug
> is found. Putting all experiments into a single folder even with the
> overly generic name "bug" would have been "good enough" to avoid the
> problem.

Depends on how many "bugs" the OP thinks he has found. (Hint: check on 
the python bug tracker.) And of course you can't have multiple files in 
the same directory unless they have different names, so a good naming 
system is still needed.

But as you point out later:

>> Imagine having fifty files called "program.py". Which one is which? How
>> do you know? Programs should be named by what they do (think of Word,
>> which does word processing, or Photoshop, which does photo editing), or
>> when that isn't practical, at least give them a unique and memorable
>> name (Outlook, Excel). The same applies to files demonstrating bugs.
>  
> Outlook and Excel are only good names because these are popular
> applications. If I were to name some private scripts in that style and
> not use them for a few months -- I don't think I'd have a clue what
> excel.py is meant to do.

... a good naming scheme has to take into account how often you use it. 
Scripts that you *literally* throw away after use don't need to be named 
with a lot of care, just enough to keep the different versions distinct 
while you use them. More generic scripts that you keep around need a bit 
more care -- I must admit I have far too many scripts called "make_avi" 
for slightly different video-to-AVI conversion scripts. But at least 
they're not all called "script.py".

Outlook and Excel are memorable names, but if you don't use them 
frequently, you may not associate the name with the application. In the 
Python world, we have memorable names like Psyco and Pyrex, but it took 
me *ages* to remember which one was which, because I didn't use them 
often enough to remember.

(Psycho is a JIT specialising compiler, now unmaintained and obsoleted by 
PyPy; Pyrex enables you to write C extensions using Python, also 
unmaintained, and obsoleted by Cython.)

[...]
> One approach that seems to be working so far is to combine several
> scripts into one using argparse subparsers. This results in more
> frequent usage which means I can get away with short meaningless names,
[...]


Very true, but the cost is added complexity in the script.


-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [standalone]

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

csiph-web