pypentago-devel

[Pypentago-devel] Code styleguide

[Florian M. <flo...@ai...>]

Hello.
I have been thinking that maybe we should introduce a code style
convention, so the source code is easier to read due to being uniform.
On the other hand, it may be better if every one can use his own style
so it is easier to develop for him.

If we agree on making a convention, there are three proposals that are
possible. One would be PEP8, the Python styleguide, compatibility and
the other two would be adapting the style of the modules we are using,
namely Twisted or wxPython.

I think PEP8 has several advantages beside being the official Python
style. The first is, because our external modules are *not* compatible
to PEP8 we would never fall into naming issues overwriting their
methods, of course this cannot be applied to class names, as they are
the same in every of those three.
The other would be that every Python developer should be able to read
our code pretty well, as most of them have read the PEP8. Also I think
the style is really clear and easy to read, but that is just my opinion.
In this style, methods and functions have the same convention, but it is
easy to tell from those two because methods have self as their first
attribute.

The Twisted style is the one I am using at the moment, because I somehow
got used to it. There is not much difference between it and the PEP8,
besides the convention for the method names.
The advantage would be that the code looks uniform to the Twisted
methods that we import, but then it does not fit the wxPython ones
either. I personally like to name functions PEP8 style when using this,
thus it is methodName but function_name, but this is subject to changes.

Last and, for me, least the wxPython style. It is in fact C++ style as
wxWidgets is C++ and wxPython is just a wrapper for it, thus not
changing the naming convention.
I like it least because with it it is hard to tell whether something is
a class, method or function. It is actually pretty near to the Java
style, something you might like.

Just look at the code samples below to see which one you like best.
If you do not like the idea of a code style convention, feel free to say
that too.

[1] PEP8: http://paste.pocoo.org/show/59160/
[2] Twisted: http://paste.pocoo.org/show/60063/
[3] wxPython: http://paste.pocoo.org/show/60064/

Re: [Pypentago-devel] Code styleguide

[J. K. <ko...@fr...>]

I think I like PEP8 because of its standard-python-ness.

Seems like it would be pretty major to go through and convert it all to
PEP8, but I'm willing to work on that if it will help out.

There will be a lot of problems, and it will probably break our existing
(working playable) version for awhile until all the bugs get worked out.
Am I wrong about the amount of effort involved?

Re: [Pypentago-devel] Code styleguide

[Florian M. <flo...@ai...>]

J. Kovacs wrote:
> I think I like PEP8 because of its standard-python-ness.
> 
> Seems like it would be pretty major to go through and convert it all to
> PEP8, but I'm willing to work on that if it will help out.
I do not think it is so hard to do with the possibilities regex and
search&replace offer to us.
I think it would take me a day or two to convert the whole source, but
that's only an estimate.


> There will be a lot of problems, and it will probably break our existing
> (working playable) version for awhile until all the bugs get worked out.
> Am I wrong about the amount of effort involved?
I hope you are. I will think about if it is worth the effort, but I
think most modules(especially the server) will be converted pretty fast.


Florian Mayer

Re: [Pypentago-devel] Code styleguide

[Florian M. <flo...@ai...>]

I have just converted server/connection.py into PEP8 style for your
review: http://paste.pocoo.org/show/60142/
I am not completely sure if this is better anymore, maybe I just need to
get used to it.

Florian Mayer

Re: [Pypentago-devel] Code styleguide

[Hardik M. <har...@gm...>]

Hi,

I think converting itself using regex is not a big deal, but in this process
you may break something, e.g a similarly named variable and because we don't
have unittest coverage, there is no guarantee that everything is working as
it was before the style change.

I don't have much idea about the code in other modules than db, but if you
think something may get broken after the style change you can develop unit
tests to test those parts before the change and the tests should pass after
the change. This is sort of a guarantee that you will not break anything.

regards,
Hardik


On Mon, Jun 2, 2008 at 10:03 PM, Florian Mayer <flo...@ai...> wrote:

> I have just converted server/connection.py into PEP8 style for your
> review: http://paste.pocoo.org/show/60142/
> I am not completely sure if this is better anymore, maybe I just need to
> get used to it.
>
> Florian Mayer
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pypentago-devel mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypentago-devel
>

Re: [Pypentago-devel] Code styleguide

[Florian M. <flo...@ai...>]

Hardik Mehta wrote:
> Hi,
> 
> I think converting itself using regex is not a big deal, but in this process
> you may break something, e.g a similarly named variable and because we don't
> have unittest coverage, there is no guarantee that everything is working as
> it was before the style change.
> 
> I don't have much idea about the code in other modules than db, but if you
> think something may get broken after the style change you can develop unit
> tests to test those parts before the change and the tests should pass after
> the change. This is sort of a guarantee that you will not break anything.
> 
> regards,
> Hardik
I think unittest are a bit over the top as the current features are
easily testable by just playing a test game and watching for exceptions.

Florian Mayer

Re: [Pypentago-devel] Code styleguide

[J. K. <ko...@fr...>]

I can see both sides of it.

Unit testing is good and would be very professional.  Plus it would be a
good chance for me to learn more about PyUnit and unit testing in general.

but...

It does also seem like a lot of extra work and perhaps overkill for this
sized project.

Sorry I did not break the tie.


BTW,
http://svn.browsershots.org/trunk/devtools/pep8/pep8.py
is a source code checker to validate a file is in PEP8 format.(i think)
No idea if it works well or not, just a thought.

[Pypentago-devel] GameHistoryManager.py ???

[J. K. <ko...@fr...>]

Hi all,

Does it make sense to create a GameHistoryManager.py file kind of like the
PlayerManager?


I'm wondering if that is where the Game Logging code will go.

I picture at the end of the game, the server, after detecting the win
condition calls a "report_game" method; not sure if my format is correct
there.

If I'm right, the GameHistoryManager.report_game() method
would have a couple goals:

#1 - Log the game
Log the Game into the game history table.

#2 - Update the current_rating of both players
Get previous game history for player 1
Build it into a list L
Pass list to glicko2 function
    rc = RatingCalculator()  #create the rating calculator object
    result = rc.CalculateNewRating( L, current_volatility, current_RD)
    #I think the Glicko code is close to working, if given proper input.
Use returned list to save the new rating of the player back to Players
table (probably using PlayerManager, right?)
Repeat for player 2


Well, just wanted to get my thoughts down here.
(I think the above makes the 2 public methods of Glicko2.py obsolete)


Lets create a Gna Task if GameHistoryManager.py  makes sense.
Maybe I am just rushing things, if so, then disregard.

I will be happy to work on something like that if it makes sense.
Florian and I discussed doing a GameLog class, but Maybe it makes more
sense in the /db/GameHistoryManager  file.  If there are no objections, I
will begin working on this;  however, if I am stepping on your toes
Hardik, let me know and I will hold off and work on glicko-cleanup
instead.

Let me know.
Thanks for your continued good communication.

Kovacs

Re: [Pypentago-devel] GameHistoryManager.py ???

[Hardik M. <har...@gm...>]

Hi J. Kovacs.

The direction in which you are thinking is completely right. After I have
set up this annoying  many-to-many relations between GameHistory and
Players, I wanted to ask you this question about How you would like to use
GameHistoryManager, if we would create one.

While your arguments are completely right as far as the storing the
GameHistory or in your words, the functionality of report_game() method
goes. But I have a few questions

1. Are we going to need queries like how many games a given player won  or
2. With which player has a given player won maximum games ?
3. Or as simple as which games were played by a given player (can be as p1
as well p2) ?

If we are going to need these queries it would be good to have a Manager
class for GameHistory. Moreover you can create GameLogger class which calls
the save_game method of GameHistoryManager class. I want to give the general
interface to all the tables so the interface can be extended at anytime to
implement more queries or other functionality. Yesterday, I was sick and
today I had to work. So only now I am able to work on the GameHistory table.
But if everything goes well, I will be able to commit at least the initial
version tonight.

You are in no way stepping on my toes, so feel free to create the GameLogger
class. Though if it should be in GameManager module or not is a question. If
it would be Java I would say no, because it has more to do with Game logic
than database.


regards,
Hardik





On Tue, Jun 3, 2008 at 8:02 PM, J. Kovacs <ko...@fr...> wrote:

> Hi all,
>
> Does it make sense to create a GameHistoryManager.py file kind of like the
> PlayerManager?
>
>
> I'm wondering if that is where the Game Logging code will go.
>
> I picture at the end of the game, the server, after detecting the win
> condition calls a "report_game" method; not sure if my format is correct
> there.
>
> If I'm right, the GameHistoryManager.report_game() method
> would have a couple goals:
>
> #1 - Log the game
> Log the Game into the game history table.
>
> #2 - Update the current_rating of both players
> Get previous game history for player 1
> Build it into a list L
> Pass list to glicko2 function
>    rc = RatingCalculator()  #create the rating calculator object
>    result = rc.CalculateNewRating( L, current_volatility, current_RD)
>    #I think the Glicko code is close to working, if given proper input.
> Use returned list to save the new rating of the player back to Players
> table (probably using PlayerManager, right?)
> Repeat for player 2
>
>
> Well, just wanted to get my thoughts down here.
> (I think the above makes the 2 public methods of Glicko2.py obsolete)
>
>
> Lets create a Gna Task if GameHistoryManager.py  makes sense.
> Maybe I am just rushing things, if so, then disregard.
>
> I will be happy to work on something like that if it makes sense.
> Florian and I discussed doing a GameLog class, but Maybe it makes more
> sense in the /db/GameHistoryManager  file.  If there are no objections, I
> will begin working on this;  however, if I am stepping on your toes
> Hardik, let me know and I will hold off and work on glicko-cleanup
> instead.
>
> Let me know.
> Thanks for your continued good communication.
>
> Kovacs
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pypentago-devel mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypentago-devel
>

Re: [Pypentago-devel] GameHistoryManager.py ???

[J. K. <ko...@fr...>]

> After I have set up this annoying many-to-many relations

So are you saying you would rather have

Games ---- Games_to_Players ------- Players

as the table structure?

It seems like it would be more complicated, but I can see why you might
want to do that.

If you think that is better then go ahead.

Re: [Pypentago-devel] GameHistoryManager.py ???

[Hardik M. <har...@gm...>]

Hi,

yes. I thought something like this but I didn't see any advantage so
committed the simple structure we had before and its manager. If we need
more complicated queries more often we will implement this.

regards,
Hardik

On Wed, Jun 4, 2008 at 3:16 AM, J. Kovacs <ko...@fr...> wrote:

> > After I have set up this annoying many-to-many relations
>
> So are you saying you would rather have
>
> Games ---- Games_to_Players ------- Players
>
> as the table structure?
>
> It seems like it would be more complicated, but I can see why you might
> want to do that.
>
> If you think that is better then go ahead.
>
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Pypentago-devel mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypentago-devel
>

Re: [Pypentago-devel] GameHistoryManager.py ???

[J. K. <ko...@fr...>]

Hi!

So, is it correct that there will be a GameLog class and also a
GameHistoryManager  class?

GameLog will use  GameHistoryManager to make its database calls.

Is that the correct setup?

And does everyone agree with that structure?

If so, I commence work on GameLog.py.  Else, lets discuss.

Thanks!

JK

Re: [Pypentago-devel] GameHistoryManager.py ???

[Hardik M. <har...@gm...>]

Hi,

Yes you understood correctly and the GameHistoryManager is already committed
and does what I think is necessary. If you want more queries or database
interaction, I will add it to the GameManager.

Florian got his two methods login_available() and email_available()
implemented on demand..

regards,
Hardik

On Thu, Jun 5, 2008 at 5:00 PM, J. Kovacs <ko...@fr...> wrote:

>
> Hi!
>
> So, is it correct that there will be a GameLog class and also a
> GameHistoryManager  class?
>
> GameLog will use  GameHistoryManager to make its database calls.
>
> Is that the correct setup?
>
> And does everyone agree with that structure?
>
> If so, I commence work on GameLog.py.  Else, lets discuss.
>
> Thanks!
>
> JK
>
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Pypentago-devel mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypentago-devel
>

Re: [Pypentago-devel] Code styleguide

[Hardik M. <har...@gm...>]

Hi guys,

Unit tests are actually meant to test a small, independent component. You
should in no case write unit tests for a huge software project (these tests
are called functional tests ) but divide that project into small independent
(this is more important) components and test the behavior of those
components.

Apart from providing the safety-net while refactoring,  writing first the
unit tests and then developing the corresponding component improves the
design of your project because you automatically modularize your project.

Anyway, this is just my opinion. If we can refactor the code without unit
tests, it would be good to avoid the overhead.


regards,
Hardik





On Tue, Jun 3, 2008 at 6:59 PM, J. Kovacs <ko...@fr...> wrote:

> I can see both sides of it.
>
> Unit testing is good and would be very professional.  Plus it would be a
> good chance for me to learn more about PyUnit and unit testing in general.
>
> but...
>
> It does also seem like a lot of extra work and perhaps overkill for this
> sized project.
>
> Sorry I did not break the tie.
>
>
> BTW,
> http://svn.browsershots.org/trunk/devtools/pep8/pep8.py
> is a source code checker to validate a file is in PEP8 format.(i think)
> No idea if it works well or not, just a thought.
>
>
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pypentago-devel mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypentago-devel
>

Re: [Pypentago-devel] Code styleguide

[Florian M. <flo...@ai...>]

Of course it *could* improve the quality, but take it that way: what
does a unittest, that only checks one module, help when I forget to
change a reference in the connection.py file imported from the game.py
file, like applyturn.
I think the effort/gain ratio is just too low to write unittests for the
server/client program.

Florian Mayer
Hardik Mehta wrote:
> Hi guys,
> 
> Unit tests are actually meant to test a small, independent component. You
> should in no case write unit tests for a huge software project (these tests
> are called functional tests ) but divide that project into small independent
> (this is more important) components and test the behavior of those
> components.
> 
> Apart from providing the safety-net while refactoring,  writing first the
> unit tests and then developing the corresponding component improves the
> design of your project because you automatically modularize your project.
> 
> Anyway, this is just my opinion. If we can refactor the code without unit
> tests, it would be good to avoid the overhead.
> 
> 
> regards,
> Hardik
>