Right way of pep8 long maya commands

[yann19]

I am trying to do a pep8 documenting on my maya code.

As some of the scripting I have done are very long, I was wondering what is they right way that I should write?

http://pastebin.com/raw/PhnqqMhj

[yann19]

Oh and adding on one more questions - is it more common to write the full name of the flags or the short names of the flags?

Eg. cmds.camera(q=True) or cmds.camera(query=True)

[Justin Israel]

Are you meaning the style guide for docstrings? Like this thing?

https://www.python.org/dev/peps/pep-0257/

Other than that, I figure it has also somewhat to do with what documentation generator you may be using. If you play to use Sphinx to generate documentation from your source code, then you may choose to use either the restructedText format or the Google napolean format

But as far as pep8 is concerned, you should probably break those long lines up in your actual source code ;-)

Also, I don't know if there is any particular standard on using the short or long flag names. It is really your choice to do what you think is most readable. Maybe if you use a lot of those more obscure flags, then it might be good to be able to read the long form. But that is purely a suggestion

On Mon, Jul 11, 2016 at 5:00 PM yann19 <yang...@gmail.com> wrote:

Oh and adding on one more questions - is it more common to write the full name of the flags or the short names of the flags?

Eg. cmds.camera(q=True) or cmds.camera(query=True)

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/98e1fd5c-1591-4736-b4f1-ac0725cdb4c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Geordie Martinez]

RE: the code

well honestly I'd make all that pyside/PyQt instead of maya.cmds UI. it's just much easier to maintain and edit.

RE: Pep 8. 

There was a pretty decent short PyCon video on PEP8 being a **guide** and not a rule book by Raymond Hettinger.

https://youtu.be/ARN52Mi1f3Q

Personally, I'm not a stickler for the ```underscore_variable_naming_convention```. I prefer ```camelCase``` because it's what I started out using. The hardcore pythonistas (#chadvernon) would frown on my statement, but It's good enough for PyQt and Pyside so it's good enough for me. 

On Mon, Jul 11, 2016 at 4:00 PM, yann19 <yang...@gmail.com> wrote:

Oh and adding on one more questions - is it more common to write the full name of the flags or the short names of the flags?

Eg. cmds.camera(q=True) or cmds.camera(query=True)

--

You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

[yann19]

Hi Justin, for now I am not using any generator, more of a manual workflow of documenting it into pep8 form.

I did chance upon that particular link you have put, while I am able to document it as follows, I am still having confusions on how to 'break' up my lines (kindly see the paste bin link in my first post)

I have seen some whom break it it by placing it 4 spaces after the first bracket while some places it directly at the same 'column' under the first flag

[yann19]

Hi Geordie, the reason why this come was not using pyqt, first it was not done by me and I am trying to keep the code as original as possible since I would not want to mess it up.

Truth be told, rather than saying I am not a fan of _underscore_variable, like what you have mentioned, I am still very much in scripting and hence I have been creating some new functions in camel case since I am used to that and easier to type but those will soon be changed to pep8 for such as variable_name

Have just modified the code to use the long names for easier clarification but that simply means making my lines longer which is not part of pep8 style and as mentioned in my reply to Justin, currently I am having troubles 'breaking' the lines up, not doc strings

[Fredrik Averpil]

I'd recommend installing a linter in your favorite editor/IDE to serve as a guide on how to format your code. For PEP8 and the line breakings you mention I'm using "flake8". I use that in Sublime Text and I highly recommend it for anyone writing Python. Flake8 is available in most advanced editors where you would typically write Python code.

I figured I'd also mention that PEP8 says you should only use camelCase "in contexts where that's already the prevailing style". And by that I do not mean to bash anyone's coding style, but if you were under my code review, I would kindly ask you to fix it ;)

Cheers!

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/815d97df-9832-4480-ab07-f85e2c8e77af%40googlegroups.com.

[Cesar Saez]

In my view it's almost always better to stick to the style of the API your code interact with the most, so it all looks homogeneous and familiar.

In this case pyqt/pyside is camel case, the entire maya api is camel case, maya commands are camel case (and a terrible example for anyone wanting to design an API, but you get the idea)... therefore my maya code is camel case.

Same with qt stuff  and getters/setters vs attributes/properties, qt is all about getters and setters so if I'm coding any kind of reusable view/model it makes sense to follow that style instead of going pythonic and being foreign to anyone using your library.

tl:dr; It's not about following rules but making it easier for the next guy reading/using your code, make it familiar and consistent :)

Other than that I agree with Fredrik, use a linter (and configure your version control system to run the linter on submission before code reviews), don't waste your time on this when your editor can show you the mismatches in realtime as you go... you will eventually get familiar with the style and the linter warning will dissapear, but your first week will be all about "rules" you never thought about. Also, and this comes from experience, feel free to ignore a few rules if it doesn't make sense in your codebase, most linters have options to blacklist rules per project (i.e. current/modern styleguides have moved to 120 chars per line instead of the good ol' 79 chars, or set a different number of blank lines before a function so you can use some spacing within your function without visually merging the code blocks).

Cheers!

C.

[Justin Israel]

On Tue, 12 Jul 2016, 4:01 AM Cesar Saez <ces...@gmail.com> wrote:

In my view it's almost always better to stick to the style of the API your code interact with the most, so it all looks homogeneous and familiar.

I agree with this. I tend to make it conform with the existing predominant api

--

You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPamJi85EiFY%2BXT7%3D6X_3gomXUgi-5%2Btq2eZV44pDzcsaeF%3Dmw%40mail.gmail.com.

[Marcus Ottosson]

In my view it’s almost always better to stick to the style of the API your code interact with the most

…

I tend to make it conform with the existing predominant api

That could work, but personally, I think one should write code that conforms to surrounding code. Such as, other projects in an organisation. Regardless of which libraries which happen to be used internally.

Put another way, I think that one should write code such that it creates the least amount of friction for whomever is most likely to read it apart from yourself.

On this mailing list for example, there is really only one choice; PEP08. Likewise for open source projects. Simply because without a pervasive style, there is only one style that matters apart from your opinion. And unless you are working alone, your opinion doesn’t matter.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2KHvhS-8fBcvCEF5SO5xFuGiM8fhw39m%3D1pAboNdy02A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

​

--

Marcus Ottosson
konstr...@gmail.com

[Mahmoodreza Aarabi]

Hey man

i'm using SublimeText  + Anaconda Pep8 Linter as its package, it is very good.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBqGLEynDVZcc%2BXd4ux0nx3%3DMbW2PCgpAXSVHOwBTDgzQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Bests,

madoodia

[yann19]

Hi all, very much appreciated for the replies. Still a bit confused about making my code more pep8 etc, not to mentioned when to use camelCase or vaiable_name too

Currently this is a portion of my code: HERE

And I have edited it to be this like : HERE

Kindly feel free to tell me if I am doing it right or wrong?

[yann19]

And an off topic question, as my code contains tons of maya ui / layout commands...

How complicated will it be if I try to replace those with PyQt code?

[Justin Israel]

On Fri, Jul 15, 2016 at 7:20 AM yann19 <yang...@gmail.com> wrote:

Hi all, very much appreciated for the replies.

Like some have mentioned, I am having issues whether to use camelCase or not, though at certain pep8 docs seem to be implying that I can mix those underscores etc. such as 

class pepTest(object):
    def _init_(self):
        self.randomValue = 10
        ...
    def getMayaVersion(self):
        maya_version = str(mc.about(v = True))

And that is probably the root of my confusion...
Still not sure what is right or wrong...

Are you referring to the __init__() ? If so, that is one of the magic methods, which are surrounded by double underscores. The camelCase / snake_case thing isn't really applicable to that. Similarly, you can make _protectedMethods and __privateMethods

 

Also an off topic question - how complicated will it be to change all maya ui layout commands into pyqt format (just so you know, I have an entire ui that is made up of maya commands)

"Complicated" is relative to whether you have ever written pyqt in the past. If you have, then it is easy to rewrite a layout that uses native Maya UI into pyqt. If you have never done it before, then you will have to learn pyqt first.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/f051c7bf-18ba-4dc5-8a30-eb6450260912%40googlegroups.com.

[yann19]

yep, that is what I am referring to, especially those single or double underscores right at the front of the function name etc.

However can I mix around, like what I did for that code example?

I used to do a bit of pyqt coding... just debating if I should change it to pyqt or not

[Justin Israel]

On Fri, 15 Jul 2016, 12:44 PM yann19 <yang...@gmail.com> wrote:

yep, that is what I am referring to, especially those single or double underscores right at the front of the function name etc.

However can I mix around, like what I did for that code example?

It is pretty simple. Just be consistent. 

The leading single and double underscore thing doesn't count. It has an actual purpose in the language as opposed to stylistic concerns 

I used to do a bit of pyqt coding... just debating if I should change it to pyqt or not

--

You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/27f2879f-635b-4331-8c44-ff111a1a4428%40googlegroups.com.