93 lines
3.1 KiB
Plaintext
93 lines
3.1 KiB
Plaintext
|
|
Style
|
|
=====
|
|
|
|
* For indentation, use *four space characters* per level of indentation. Keep
|
|
lines under the 80 chars limit (only exception are the functions definition)
|
|
|
|
* When comparing C pointers with NULL, use == and != instead of the python
|
|
operator "is". This makes a visual distinction between python and C code.
|
|
|
|
|
|
Design patterns
|
|
===============
|
|
|
|
* From "The Zen of Python":
|
|
|
|
Beautiful is better than ugly.
|
|
Explicit is better than implicit.
|
|
Simple is better than complex.
|
|
Complex is better than complicated.
|
|
Flat is better than nested.
|
|
Sparse is better than dense.
|
|
Readability counts.
|
|
Special cases aren't special enough to break the rules.
|
|
Although practicality beats purity.
|
|
Errors should never pass silently.
|
|
Unless explicitly silenced.
|
|
In the face of ambiguity, refuse the temptation to guess.
|
|
There should be one-- and preferably only one --obvious way to do it.
|
|
Although that way may not be obvious at first unless you're Dutch.
|
|
Now is better than never.
|
|
Although never is often better than *right* now.
|
|
If the implementation is hard to explain, it's a bad idea.
|
|
If the implementation is easy to explain, it may be a good idea.
|
|
Namespaces are one honking great idea -- let's do more of those!
|
|
|
|
|
|
Tips
|
|
====
|
|
|
|
* cython does automatic dict <-> struct conversion with basic struct members
|
|
|
|
|
|
Release process instructions
|
|
============================
|
|
|
|
* Change versions in the top part of setup.py (ex: 1.9 and 1.9.0)
|
|
* Update the changes.html file
|
|
setup.py build_doc -b changes ...and manually merge
|
|
* Git push and wait jenkins to generate the 2 tarballs
|
|
* Test the generated tarball
|
|
* Put the tarballs on download.e.org/rel/bindings/python
|
|
* Create and push the tag for the release
|
|
git tag -a v1.9.0 && git push origin v1.9.0
|
|
* Create and push the branch for stable backporting
|
|
git branch python-efl-1.9 && git push origin python-efl-1.9
|
|
* Write the blog post on phame (Official Announcements)
|
|
* Annouce the release to release@lists.enlightenment.org
|
|
* Update download link on website
|
|
* Change versions again in setup.py (ex: 1.9 and 1.9.99)
|
|
* Raise efl and elementary requirements in setup.py (to 1.9.99)
|
|
|
|
more info at:
|
|
phab.enlightenment.org/w/release_procedure/
|
|
|
|
|
|
Discussion
|
|
==========
|
|
|
|
* Internal utility functions used in the bindings must start with an
|
|
underscore and must have the shortest name as possible.
|
|
^
|
|
This needs further discussion/expansion.
|
|
|
|
When we define a function with cdef it is not exposed to Python API.
|
|
This should be explicit enough to not need the underscore prefix, which
|
|
at best looks ugly, and at worst just plain confusing.
|
|
|
|
A function name should summarize its functionality in one clear text,
|
|
short sentence. We have both too long and too short names. And I admit to
|
|
being guilty of adding many of both.
|
|
|
|
Let's build up a short review so we can see where we stand with this and
|
|
make necessary corrections.
|
|
|
|
/ kuuko
|
|
|
|
|
|
The underscore usage is a coding standard in all the EFL, we should try
|
|
to follow the efl style also here (where is possible and make sense)
|
|
|
|
/ davemds
|