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

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

pylint woes

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

Contents

  pylint woes DFS <nospam@dfs.com> - 2016-05-07 12:51 -0400
    Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 03:01 +1000
      Re: pylint woes DFS <nospam@dfs.com> - 2016-05-07 21:16 -0400
        Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 11:36 +1000
          Re: pylint woes DFS <nospam@dfs.com> - 2016-05-07 22:15 -0400
            Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 12:50 +1000
              Re: pylint woes DFS <nospam@dfs.com> - 2016-05-10 18:36 -0400
                Re: pylint woes MRAB <python@mrabarnett.plus.com> - 2016-05-11 02:02 +0100
        Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-07 19:14 -0700
          Re: pylint woes DFS <nospam@dfs.com> - 2016-05-07 23:04 -0400
            Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-07 20:46 -0700
              Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 10:26 -0400
            Re: pylint woes Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-05-08 08:50 +0300
              Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 10:25 -0400
                Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-09 00:36 +1000
                  Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 11:06 -0400
                    Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-08 08:15 -0700
                      Re: pylint woes Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-09 13:17 +1200
                        Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-09 12:18 +1000
                        Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 22:58 -0400
                    Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-09 01:15 +1000
                      Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 17:06 -0400
                Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-08 08:11 -0700
                Re: pylint woes Steven D'Aprano <steve@pearwood.info> - 2016-05-09 01:51 +1000
                  Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 17:04 -0400
                    Re: pylint woes Steven D'Aprano <steve@pearwood.info> - 2016-05-09 13:09 +1000
        Re: pylint woes MRAB <python@mrabarnett.plus.com> - 2016-05-08 03:21 +0100
        Re: pylint woes Steven D'Aprano <steve@pearwood.info> - 2016-05-08 21:36 +1000
          Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 17:24 -0400
            Re: pylint woes Joel Goldstick <joel.goldstick@gmail.com> - 2016-05-08 17:39 -0400
            Re: pylint woes Steven D'Aprano <steve@pearwood.info> - 2016-05-09 13:46 +1000
    Re: pylint woes Michael Selik <michael.selik@gmail.com> - 2016-05-07 18:42 +0000
    Re: pylint woes Peter Pearson <pkpearson@nowhere.invalid> - 2016-05-07 18:43 +0000
      Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 17:05 -0400
    Re: pylint woes Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-07 11:52 -0700
      Re: pylint woes DFS <nospam@dfs.com> - 2016-05-07 23:38 -0400
        Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 13:56 +1000
        Re: pylint woes Peter Otten <__peter__@web.de> - 2016-05-08 16:19 +0200
    Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-07 12:21 -0700
    Re: pylint woes Stephen Hansen <me@ixokai.io> - 2016-05-07 12:23 -0700
    Re: pylint woes Terry Reedy <tjreedy@udel.edu> - 2016-05-07 15:40 -0400
      Re: pylint woes DFS <nospam@dfs.com> - 2016-05-07 23:28 -0400
        Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 13:51 +1000
          Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 00:40 -0400
            Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 14:55 +1000
        Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-07 20:55 -0700
        Re: pylint woes Ian Kelly <ian.g.kelly@gmail.com> - 2016-05-07 23:09 -0600
        Re: pylint woes Peter Otten <__peter__@web.de> - 2016-05-08 16:12 +0200
    Re: pylint woes Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-07 12:43 -0700
    Re: pylint woes Ray Cote <rgacote@appropriatesolutions.com> - 2016-05-07 15:52 -0400
    Re: pylint woes Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-07 13:20 -0700
    Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 07:56 +1000
    Re: pylint woes Terry Reedy <tjreedy@udel.edu> - 2016-05-07 21:44 -0400
    Re: pylint woes Steven D'Aprano <steve@pearwood.info> - 2016-05-08 13:25 +1000
      Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 00:10 -0400
        Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 14:21 +1000
        Re: pylint woes "D'Arcy J.M. Cain" <darcy@VybeNetworks.com> - 2016-05-08 08:50 -0400
        Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 23:01 +1000
          Re: pylint woes Larry Hudson <orgnut@yahoo.com> - 2016-05-08 13:45 -0700
            Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-09 08:07 +1000
              Re: pylint woes Larry Hudson <orgnut@yahoo.com> - 2016-05-08 18:28 -0700
          Re: pylint woes Dan Sommers <dan@tombstonezero.net> - 2016-05-08 20:49 +0000
            Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-09 08:10 +1000
        Re: pylint woes Steven D'Aprano <steve@pearwood.info> - 2016-05-09 03:25 +1000
          Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 17:16 -0400
            Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-08 14:38 -0700
              Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 17:46 -0400
                Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-08 15:05 -0700
                  Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 18:24 -0400

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

#108402

On 05/08/2016 03:07 PM, Chris Angelico wrote:
> On Mon, May 9, 2016 at 6:45 AM, Larry Hudson via Python-list
> <python-list@python.org> wrote:
>> On 05/08/2016 06:01 AM, Chris Angelico wrote:
>> [snip...]
>>>
>>> ...                                          I like to recommend a
>>> little thing called "IIDPIO debugging" - If In Doubt, Print It Out.
>>> That means: If you have no idea what a piece of code is doing, slap in
>>> a print() call somewhere. It'll tell you that (a) the code is actually
>>> being executed, and (b) whatever info you put between the parens
>>> (ideally, some key variable or parameter)...
>>
>>
>> My personal variation of IIPPID debugging is to use input() instead of
>> print().  For example:
>>
>>      input('x = {}, y = {} --> '.format(x, y))
>>
>> Then the program stops at this point so you can examine the values.  <Enter>
>> will continue the program or ^C will abort (if you see what the problem is
>> now).  Of course this can't be used in all situations, but it's handy where
>> it can.
>>
>> Note that my personal preference is to stick that "-->" as a prompt at the
>> end, but obviously this (or a similar marker) is optional.
>
> Neat technique. Not something to use *every* time (and not always
> sensible - eg you don't normally want to stall out a GUI thread), but
> definitely worth keeping in the arsenal.
>
> ChrisA
>

Agreed.  As I said in my post, it is certainly not a universally valid approach, but I do find 
it useful in many cases.

      -=- Larry -=-

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

#108383

On Sun, 08 May 2016 23:01:55 +1000, Chris Angelico wrote:

> ... I like to recommend a little thing called "IIDPIO debugging" - If
> In Doubt, Print It Out.  That means: If you have no idea what a piece
> of code is doing, slap in a print() call somewhere. It'll tell you
> that (a) the code is actually being executed, and (b) whatever info
> you put between the parens (ideally, some key variable or
> parameter). Part A is often the important bit :) ...

Having spent a long time developing embedded systems, I wholeheartedly
agree.  In spirit.  Isn't that what the logging module is for?  Fine
grained control, as centralized or distributed as is warranted, over
program output?

> ... The trouble with a verbose flag controlling all print() calls is
> that IIDPIO debugging suddenly doesn't work; plus, it's easy to copy
> and paste code to some other module and not notice that you don't have
> a verbosity check at the top, and then wonder why disabling verbose
> doesn't fully work. Both problems are solved by having a dedicated
> spam function, which will simply error out if you didn't set it up
> properly.

Hey!  That sounds just like the logging module....  ;-)

Dan

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

#108394

On Mon, May 9, 2016 at 6:49 AM, Dan Sommers <dan@tombstonezero.net> wrote:
> On Sun, 08 May 2016 23:01:55 +1000, Chris Angelico wrote:
>
>> ... I like to recommend a little thing called "IIDPIO debugging" - If
>> In Doubt, Print It Out.  That means: If you have no idea what a piece
>> of code is doing, slap in a print() call somewhere. It'll tell you
>> that (a) the code is actually being executed, and (b) whatever info
>> you put between the parens (ideally, some key variable or
>> parameter). Part A is often the important bit :) ...
>
> Having spent a long time developing embedded systems, I wholeheartedly
> agree.  In spirit.  Isn't that what the logging module is for?  Fine
> grained control, as centralized or distributed as is warranted, over
> program output?
>
>> ... The trouble with a verbose flag controlling all print() calls is
>> that IIDPIO debugging suddenly doesn't work; plus, it's easy to copy
>> and paste code to some other module and not notice that you don't have
>> a verbosity check at the top, and then wonder why disabling verbose
>> doesn't fully work. Both problems are solved by having a dedicated
>> spam function, which will simply error out if you didn't set it up
>> properly.
>
> Hey!  That sounds just like the logging module....  ;-)

Absolutely. I say "print" in IIDPIO because it's a word that people
understand across languages, across frameworks, etc, etc, but when you
start doing more of it, the logging module is definitely superior - if
you need just one reason to use it, it would be to *leave those prints
in place* so the next person doesn't need to reach for IIDPIO at all.

(Also, I teach print() because it's one less module to explain. But
experienced programmers should get some familiarity with it.)

ChrisA

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

#108376

On Sun, 8 May 2016 02:10 pm, DFS wrote:

> I mean I always use tab after :
> 
> The program won't run otherwise.  If I use spaces, 100% of the time it
> throws:
> 
> IndentationError: unindent does not match any outer indentation level

Then you should be more careful about your spaces. If you indent by four
spaces, you have to outdent by four -- not three, not five, but four.

The best way to do this is to use an editor that will count the spaces for
you. Any decent programmer's editor will allow you to set the TAB key to
indent by X spaces, and the Shift-TAB key to dedent by the same amount. If
you're counting spaces yourself, you're just making more work for yourself.

Or use tabs -- that's acceptable as well.

Just don't mix tabs and spaces in the same file.


>>> +-------------------------+------------+
>>> |bad-whitespace           |65          | mostly because I line up =
>>>                                           signs:
>>>                                           var1  = value
>>>                                           var10 = value
>>
>> Yuck. How much time do you waste aligning assignments whenever you add or
>> delete or edit a variable?
> 
> Lots.  It takes hours to add or delete 3 whitespaces.

Yes, you're right. It takes you five minutes to line everything up the first
time. Then you change the name of a variable, and now you have to realign
everything -- that's an extra minute gone. Then you add another line, and
have to realign again, another couple of minutes. Over the lifespan of the
program, you'll probably have spent multiple hours wasting time realigning
blocks of assignments.


>>> +-------------------------+------------+
>>> |trailing-whitespace      |59          | heh!
>>> +-------------------------+------------+
>>> |multiple-statements      |23          | do this to save lines.
>>>                                           Will continue doing it.
>>
>> Why? Do you think that there's a world shortage of newline characters? Is
>> the Enter key on your keyboard broken?
> 
> I do it because I like it.
> 
> if verbose: print var
> 
> python doesn't complain.

Hmmm. Well, that's not too bad. I thought you mean something like:

addr = getaddress(key); addr[2] = addr.upper(); print addr

which is just horrible.




-- 
Steven

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

#108387

On 5/8/2016 1:25 PM, Steven D'Aprano wrote:
> On Sun, 8 May 2016 02:10 pm, DFS wrote:


>>>> +-------------------------+------------+
>>>> |bad-whitespace           |65          | mostly because I line up =
>>>>                                           signs:
>>>>                                           var1  = value
>>>>                                           var10 = value
>>>
>>> Yuck. How much time do you waste aligning assignments whenever you add or
>>> delete or edit a variable?
>>
>> Lots.  It takes hours to add or delete 3 whitespaces.
>
> Yes, you're right. It takes you five minutes to line everything up the first
> time. Then you change the name of a variable, and now you have to realign
> everything -- that's an extra minute gone. Then you add another line, and
> have to realign again, another couple of minutes. Over the lifespan of the
> program, you'll probably have spent multiple hours wasting time realigning
> blocks of assignments.


Do you actually believe what you just wrote?

If yes, you should quit programming.

If not, why did you say it?







>>>> +-------------------------+------------+
>>>> |trailing-whitespace      |59          | heh!
>>>> +-------------------------+------------+
>>>> |multiple-statements      |23          | do this to save lines.
>>>>                                           Will continue doing it.
>>>
>>> Why? Do you think that there's a world shortage of newline characters? Is
>>> the Enter key on your keyboard broken?
>>
>> I do it because I like it.
>>
>> if verbose: print var
>>
>> python doesn't complain.
>
> Hmmm. Well, that's not too bad. I thought you mean something like:
>
> addr = getaddress(key); addr[2] = addr.upper(); print addr
>
> which is just horrible.


I was surprised to see the PEP8 guide approve of:

"Yes: if x == 4: print x, y; x, y = y, x"

https://www.python.org/dev/peps/pep-0008/#pet-peeves

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

#108389

On Sun, May 8, 2016, at 02:16 PM, DFS wrote:
> I was surprised to see the PEP8 guide approve of:
> 
> "Yes: if x == 4: print x, y; x, y = y, x"
> 
> https://www.python.org/dev/peps/pep-0008/#pet-peeves

That is not approving of that line of code as something to mimic, its
speaking *only* about *whitespace*.

ALL its saying is, "don't put spaces before commas, colons or
semicolons". You can infer nothing else about it.

-- 
Stephen Hansen
  m e @ i x o k a i . i o

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

#108391

On 5/8/2016 5:38 PM, Stephen Hansen wrote:
> On Sun, May 8, 2016, at 02:16 PM, DFS wrote:
>> I was surprised to see the PEP8 guide approve of:
>>
>> "Yes: if x == 4: print x, y; x, y = y, x"
>>
>> https://www.python.org/dev/peps/pep-0008/#pet-peeves
>
> That is not approving of that line of code as something to mimic, its
> speaking *only* about *whitespace*.
>
> ALL its saying is, "don't put spaces before commas, colons or
> semicolons". You can infer nothing else about it.


I can infer that it's 100% approved of, since he used it as an example.

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

#108392

On Sun, May 8, 2016, at 02:46 PM, DFS wrote:
> On 5/8/2016 5:38 PM, Stephen Hansen wrote:
> > On Sun, May 8, 2016, at 02:16 PM, DFS wrote:
> >> I was surprised to see the PEP8 guide approve of:
> >>
> >> "Yes: if x == 4: print x, y; x, y = y, x"
> >>
> >> https://www.python.org/dev/peps/pep-0008/#pet-peeves
> >
> > That is not approving of that line of code as something to mimic, its
> > speaking *only* about *whitespace*.
> >
> > ALL its saying is, "don't put spaces before commas, colons or
> > semicolons". You can infer nothing else about it.
> 
> I can infer that it's 100% approved of, since he used it as an example.

Not if you don't want to be a fool.

And at this point I'm signing out from helping you.

-- 
Stephen Hansen
  m e @ i x o k a i . i o

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

#108396

On 5/8/2016 6:05 PM, Stephen Hansen wrote:
> On Sun, May 8, 2016, at 02:46 PM, DFS wrote:
>> On 5/8/2016 5:38 PM, Stephen Hansen wrote:
>>> On Sun, May 8, 2016, at 02:16 PM, DFS wrote:
>>>> I was surprised to see the PEP8 guide approve of:
>>>>
>>>> "Yes: if x == 4: print x, y; x, y = y, x"
>>>>
>>>> https://www.python.org/dev/peps/pep-0008/#pet-peeves
>>>
>>> That is not approving of that line of code as something to mimic, its
>>> speaking *only* about *whitespace*.
>>>
>>> ALL its saying is, "don't put spaces before commas, colons or
>>> semicolons". You can infer nothing else about it.
>>
>> I can infer that it's 100% approved of, since he used it as an example.
>
> Not if you don't want to be a fool.

Why would you label the author of that style guide - Guido van Rossum - 
a fool?




> And at this point I'm signing out from helping you.


A fool and a fool are soon parted.

[toc] | [prev] | [standalone]

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

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

csiph-web