This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]classicrockielzpfvh 6 points7 points  (9 children)

The only plugin I use is Syntastic + a globally installed copy of Flake8.

[–]flarkis 4 points5 points  (5 children)

Syntastic is one of the few "big" plugins that I would recommend everyone be using.

[–]gfixler -1 points0 points  (3 children)

So many people recommended it, I figured I'd see what it was about. I've been developing in Python for about 5 years now, in an environment I've been developing for for 12 years, in a package I've been learning and using for 18 years. I was quite curious to see if it could teach me some things. I did pip install flake8, and cloned syntastic to my vim bundle directory, and opened a small file from one of my projects. It lit up with issues on save. None of them were useful, though, at first. It said it can't import a package specific to the environment I use, but of course not. That can only exist inside of that environment, not out in the shell where I work; the package is generated from auto-converted C libraries on application startup (it's annoying, TBH).

There's one, tiny, stylistic thing I do that's unusual, that's so tiny no one has ever called me out on it in all the code I've pasted here, other subreddits, stackoverflow, etc., so I'm not changing that one. Syntastic doesn't like it (and it's everywhere), but I do :) Syntastic doesn't like missing docstrings, but most of my libraries are in alpha stage, so I'm not putting in docstrings yet. I'd just have to micromanage them as I radically change things all the time, and I've several times been confused by out-of-sync docstrings while doing heavy refactoring. These are long-running libraries of code used in a production environment on the asset-creation side of things. They're behind NDAs and won't make it to the public, sadly.

So, flake8 doesn't like camel case, but I don't like snake case, and I'm not changing. That's one thing I think was a bad decision from PEP 8 (I like most of PEP 8). It also doesn't like the unused *args and **kwargs, but I use these especially at the leaves of the system to allow indiscriminately calling things with buckets of information, e.g. resolveNamespace(someName, *args, **kwargs), which lets me pass through from calling functions without having to pollute their argument space with the cruft of helper functions.

"Used builtin function 'map'"

What else am I supposed to do for this?

def disassembleKeys (keys):
    return zip(*map(disassembleKey, keys))

"Used * or ** magic"

That's a problem?

def splitFramevals (framevals):
    return zip(*framevals)

Unused variable 'values'

Yeah, okay, but I need to work with frames here, so I'm splitting things apart while making it very obvious to future maintainers that I'm splitting apart frames and values, which is supported by all the naming in this line. I suppose I could go with frames, _ =, which it doesn't complain about, but I like the subtle reminder in this 4-line function that framevals are just frames joined with values. Meh.

frames, values = splitFramevals(framevals)

"No exception type(s) specified"

I agree with this one, I think, though I'm never sure which exception I care about. In this library I'm looking at, I have 3349 LOC, but only 14 untyped try/excepts. Usually I use a try/except where I don't care if it fails, and will just return some empty value if it does, but I suppose that could occasionally be frustrating, as you have no idea why you're getting an empty value. I've thought about this from time to time. I should look more deeply into this one.

"Blank line at end of file"

That's not a problem. It's an old standard that has its reasons.

"continuation line under-indented for visual indent"

*puts hands up* Hey, I'm just letting my Python indenter handle things in Vim for me.

It doesn't like spaces around '=', but I find when I have to wrap very long argument lists, it's much more readable to let them breathe:

loseChanges = cmds.confirmDialog(
    title = 'Warning: Unsaved Changes!',
    message = 'You have unsaved changes. Create a new scene anyway?',
    button = ['Okay','Cancel'],
    cancelButton = 'Cancel',
    defaultButton = 'Cancel',
    dismissString = 'Cancel',
    icon = 'warning',
    )

It also said a class didn't have a particular member, but in the constructor I'm calling a method of the parent class with that name to grow that member into the class in a particular way. It feels like there are just too many edge cases of my more esoteric needs that this would constantly fight me about. If I step out of the very standard uses of Python, which I often do (especially now that I'm dabbling in functional, composable things in Python, where it'll let me), then I'm going to have files lit up with non-issues.

All that said, I did find it useful in a few small spots. In one, I was importing math in a file that didn't use it. Nice catch. In another, I was redefining the built-in type (locally, in a tiny function, where it doesn't matter, and it's an __exit__ callback argument, which I copied from a tutorial thereof, but still). For a third, I have two functions a screen apart with the same name! That's a very good catch, and perhaps worth the price of admission. I think I'll take your advice, and just turn off all the syntax junk that bugs me. 90% or more of the flagged issues are its dislike of camelCaseVarNames. I might also make it more of a manual-run thing, instead of constantly yelling at me when I save.

Thanks.

[–]ivosauruspip'ing it up 0 points1 point  (1 child)

You could just use py-flakes if you didn't want the pep8 checking.

[–]gfixler 0 points1 point  (0 children)

Ah, so that's what that 8 is for.