Comment on revision ra5809acabff78dc4fee69b32e034e5db562aee1c in pychess

[pyc...@googlecode.com]

Comment by lobais:

Score: Positive

General Comment:
Great! Patches that remove code are always the nicest :)
I do think @glock.glocked is a bit less nice than glock_connect?

For more information:
http://code.google.com/p/pychess/source/detail?r=a5809acabff78dc4fee69b32e034e5db562aee1c

[pyc...@googlecode.com]

Comment by mattgatto:

General Comment:
I disagree because, when the @glock.glocked decorator is used, functions
that directly manipulate UI and need to run with the glock are guaranteed
to run with it whether they're called via the callback from a
gboject's .connect(), or whether they're called from another function.
Revision 7dc2c12e3bc2 illustrates this in a case where I had to replace a
glock_connect with a @glock.glocked because the changeset changed the code
such that the function (onSelectionChanged()) is called not only from a
callback, but from another function as well (private_changed()). Also, the
decorator syntax is alot more clear when browsing code about whether it's
being run with the glock or not.

Maybe we need to work on a coding standard to work out these somewhat
stylistic differences on the mailing list? I've noticed we all seem to have
different ideas of what the maximum line length should be too, as well as
whether and where to use CamelCase :)

[pyc...@googlecode.com]

Comment by lobais:

Score: Positive

General Comment:
I'm thinking it's bad if the code starts to assume that all functions that
do UI automagically handle threading. Then it's better to always be careful
when you call such functions.

But yeah, coding standards could be good for such things.
For more artistic matters, I don't like rewriting code just to fix line
length. It's dangerous, and for me anyway, it seams like once I've started,
I get obsessed with it :)