← Back to team overview

kicad-developers team mailing list archive

Re: Python script offered as example for Action Plugin and wxFormBuilder integration

 

On 8/12/2017 11:59 AM, Greg Smith wrote:
> Where should I submit a (likely short) style guide for review? 

The KiCad developer's mailing list.

> 
> I have recently reviewed PEP8 and updated the code for KiPadCheck and LayerViewSet to be compliant, so I can write a short document about the KiCad Python style for others to review.

Our developer docs are written using Doxygen's markdown format.  Once
you have you initial draft, please submit it to this mailing list for
review.  Once we have it finalized, it can be merged into the master
branch.  Thank you taking on this task.  It's one of those things we
knew we would have to address at some point.

> 
> There are other guides similar to style guides that might be relevant as well.
> 
> PEP8 is great, and it already allows the main exception KiCad will probably need to specify: case of function names. PEP8 primarily suggests lower_case_with_underscore_separators, yet many of KiCad python methods seems to be specified as CamelCase.

This is most likely because our C++ source policy is CamelCase or
lower_case_with_underscore_separators.  The same policy seems reasonable
for the kicad python code as well.

> 
> PEP8 essentially recommends "do this [specific thing], unless you need to do something else for consistency".
> 
> Greg S.
> 
>> On Aug 12, 2017, at 10:43 AM, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> I think PEP8 is great for us.  Let's just add a line that says "We use
>> PEP8 as our Python style guide."
>>
>> Adam Wolf
>>
>>> On Sat, Aug 12, 2017 at 10:27 AM, Strontium <strntydog@xxxxxxxxx> wrote:
>>> Hello Wayne and Greg,
>>>
>>> Can I suggest just adopting PEP8 for Python code formatting.  Its clean,
>>> well documented, and there are plenty of linters to check conformance.  And
>>> if there is anything in PEP8 that is annoying for KiCad development (cant
>>> imagine what) just specify an exclusion or exception.
>>>
>>> Steven
>>>
>>>> On 12/08/17 22:15, Wayne Stambaugh wrote:
>>>>
>>>> On 8/11/2017 10:08 PM, Greg Smith wrote:
>>>
>>> ...
>>>>>
>>>>> Suggestions on coding style, functionality, integration technique are
>>>>> welcome!
>>>>
>>>> We have not defined a Python coding style.  It's something that needs to
>>>> be done but no one has had the time to do it.  Please look at some of
>>>> the existing Python code in the KiCad source repo and follow what others
>>>> have done.  The last time I looked (which admittedly has been a while),
>>>> the formatting of our Python code was pretty consistent.
>>>
>>> ...
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


Follow ups

References