| 1 |
On Thu, Dec 4, 2008 at 2:43 PM, Alec Warner <antarus@g.o> wrote: |
| 2 |
> <nitpick feel free to ignore me> |
| 3 |
> Don't put stuff in __init__.py. |
| 4 |
> |
| 5 |
> Make a file called equery (no .py) and do all the work in the modules |
| 6 |
> you import; eg. |
| 7 |
> |
| 8 |
> from equery import driver |
| 9 |
> |
| 10 |
> if __name__ == "__main__": |
| 11 |
> driver.Run() |
| 12 |
> |
| 13 |
> Then put all this code in driver.py (option parsing, signal handling, |
| 14 |
> etc...). Don't try to hide the code in __init__.py; it confuses |
| 15 |
> people who are trying to figure out what the module is for (since |
| 16 |
> __init__.py has very specific duties in declaring what is in the |
| 17 |
> module when you inspect the query module). Putting the code in a file |
| 18 |
> named 'driver.py' or similarly makes it pretty obvious (to me anyway) |
| 19 |
> what the code in that file is for (to drive a program). |
| 20 |
> |
| 21 |
> Does that make sense or am I full of crap? |
| 22 |
|
| 23 |
I see what you're saying, but using a second file, driver.py, just to |
| 24 |
do __init__.py's job seems even more confusing. __init__.py is the |
| 25 |
standard python constructor, and it's required to be in every module |
| 26 |
directory, if I understand correctly. Since you have to have an |
| 27 |
__init__.py file in the directory, which gets sourced anyway, it might |
| 28 |
as well be used for what it's meant for, which is handling all the |
| 29 |
initial setup of the package. If I'm misunderstanding the purpose of |
| 30 |
__init__, please let me know. |
| 31 |
|
| 32 |
So two best ways I can think to set it up are: |
| 33 |
1) /usr/bin/equery only import equery from /usr/lib/gentoolkit/equery. |
| 34 |
__init__.py in that dir runs all the setup work and handles input args |
| 35 |
(this is quite common), and imports and runs the requested module. |
| 36 |
This is a similar setup used by something like iotop. |
| 37 |
|
| 38 |
or |
| 39 |
|
| 40 |
2) /usr/bin/equery contains all the init stuff and opt handling, then |
| 41 |
imports the separate modules as needed. This style is used by |
| 42 |
something like pybugz, although you still have to have an __init__.py |
| 43 |
in the module folder, it can be a lot sparser. |
| 44 |
|
| 45 |
I was leaning toward #1 because it keeps all the code in the same directory. |
| 46 |
|
| 47 |
>> |
| 48 |
>> A little RFC: |
| 49 |
>> 1) Spaces or tabs? Python standard is spaces, Gentoo seems to be |
| 50 |
>> predominantly tabs. I personally like to use spaces when I'm writing |
| 51 |
>> Python, but if that would annoy everyone later on, I'll stick to tabs. |
| 52 |
> |
| 53 |
> Gentoo has no official coding standards. I'd personally prefer spaces |
| 54 |
> (along with basically everything else in the Google Python Style |
| 55 |
> Guide[1]), but I'm probably not going to nitpick. It is my opinion |
| 56 |
> that tabs are used because that is what the tools were written in and |
| 57 |
> it is annoying to change from tabs to spaces ;) |
| 58 |
> |
| 59 |
> [1] http://code.google.com/p/soc/wiki/PythonStyleGuide |
| 60 |
> |
| 61 |
|
| 62 |
I'm with you there, I really like that style guide as well. We should |
| 63 |
adopt it :) |
| 64 |
|
| 65 |
-Doug |
Archives