2013-03-28 14:37:17 -07:00
|
|
|
|
2013-03-29 08:46:32 -07:00
|
|
|
Style
|
|
|
|
=====
|
|
|
|
|
2013-03-31 12:16:50 -07:00
|
|
|
* 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.
|
2013-03-29 08:46:32 -07:00
|
|
|
|
2015-02-16 11:38:25 -08:00
|
|
|
* For long lines that do not fit in the 80 cols please use only the first
|
|
|
|
raccomandation from PEP-8 (Aligned with opening delimiter). Example:
|
|
|
|
Yes:
|
|
|
|
foo = long_function_name(var_one, var_two,
|
|
|
|
var_three, var_four)
|
|
|
|
No:
|
|
|
|
foo = long_function_name(
|
|
|
|
var_one, var_two,
|
|
|
|
var_three, var_four)
|
|
|
|
|
|
|
|
This to keep new code consistent with the rest of the bindings and to
|
|
|
|
try to match the style of the C efl code style as much as possible.
|
|
|
|
...also because I found it more readable and I like it more :P -davemds-
|
|
|
|
|
2013-03-30 06:17:52 -07:00
|
|
|
|
|
|
|
Design patterns
|
|
|
|
===============
|
2013-03-31 12:16:50 -07:00
|
|
|
|
2013-03-30 06:17:52 -07:00
|
|
|
* 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!
|
|
|
|
|
2013-03-31 12:16:50 -07:00
|
|
|
|
2013-03-29 08:46:32 -07:00
|
|
|
Tips
|
|
|
|
====
|
|
|
|
|
|
|
|
* cython does automatic dict <-> struct conversion with basic struct members
|
|
|
|
|
2013-03-31 12:16:50 -07:00
|
|
|
|
2014-03-05 13:56:11 -08:00
|
|
|
Release process instructions
|
|
|
|
============================
|
|
|
|
|
2014-05-31 02:07:00 -07:00
|
|
|
* Announce at enlightenment-release@lists.sourceforge.net that you are planning
|
|
|
|
for the release
|
2014-11-22 07:52:46 -08:00
|
|
|
* Change versions in efl/__init__.py (ex: 1.9.0)
|
2015-01-06 15:31:06 -08:00
|
|
|
* Update the ChangeLog file:
|
|
|
|
setup.py build_doc -b changes ...and manually merge from the html file
|
2014-03-05 13:56:11 -08:00
|
|
|
* Git push and wait jenkins to generate the 2 tarballs
|
2014-04-04 20:35:32 -07:00
|
|
|
* Test the generated tarballs
|
2014-11-23 11:27:52 -08:00
|
|
|
* scp tarballs & md5sums to:
|
|
|
|
download.enlightenment.org:/srv/web/download.enlightenment.org/public_html/pre-releases/
|
2014-05-31 02:07:00 -07:00
|
|
|
* Announce at enlightenment-release@lists.sourceforge.net that tarballs are
|
|
|
|
ready for testing
|
2014-04-04 20:35:32 -07:00
|
|
|
|
|
|
|
... wait 24 hours, fix any issues found. In the mean time you can prepare the
|
|
|
|
release announcement for phame/ml.
|
|
|
|
|
2014-11-23 11:27:52 -08:00
|
|
|
* ssh to download.enlightenment.org and mv tarballs & md5sums to:
|
2014-12-25 04:15:23 -08:00
|
|
|
/srv/web/download.enlightenment.org/public_html/rel/bindings/python
|
|
|
|
* Upload the .tar.gz archive to pypi
|
2014-03-05 13:56:11 -08:00
|
|
|
* 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
|
2014-04-04 20:35:32 -07:00
|
|
|
* Publish the blog post on phame (Official Announcements)
|
2014-05-31 02:07:00 -07:00
|
|
|
* Announce the release to release@lists.enlightenment.org
|
2014-12-25 04:15:23 -08:00
|
|
|
(an alias for e-announce etc.)
|
2014-05-31 02:07:00 -07:00
|
|
|
* Update download link on website (clone website/www.git, edit, commit, push)
|
2014-11-22 07:52:46 -08:00
|
|
|
* Change versions again in efl/__init__.py (ex: 1.9.99)
|
2014-03-05 13:56:11 -08:00
|
|
|
|
|
|
|
more info at:
|
|
|
|
phab.enlightenment.org/w/release_procedure/
|
|
|
|
|
|
|
|
|
2013-03-30 15:22:33 -07:00
|
|
|
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
|
2013-03-31 12:16:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
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
|