[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] json service

From: lkcl
Subject: Re: [Gnumed-devel] json service
Date: Thu, 15 Jul 2010 11:08:03 -0700 (PDT)

Sebastian Hilbert wrote:
> Will do asap. BTW. From the code you provided it is evident that you have 
> acquired a good understanding of GNUmed. What do you think of the code ?  

whatever gave you that impression? :)  no, it's more that i have a way of
getting round unfamiliar code very very quickly, and it's pretty much a
standard MVC app, so is not rocket science.

my honest opinion?  it's pretty well organised: the module subdivisions are
thorough and clear, and the level of commenting is above-average standard.

the only thing that's a complete pain is the use of tabs for indentation,
which is _not_ standard, violates PEP8 (four spaces) and will generally make
it incredibly awkward for me to contribute unless i set up a special login
or script which resets the vimrc settings _just_ to deal with this code.

the other thing which is non-PEP8 is the use of separator lines to divide
functions _without_ also putting in whitespace breaks between them.  this
makes it realllly hard on the eyes, to locate functions.  most python
programmers are used to searching for the keyword "def" or the keyword
"class" which of course stick out due to the indentation, so there really
_is_ no need for comment line separators like you are usually forced to have
for c-code, and in fact the comment-line-separator, because it is not
indented at the same level as the "def", actually makes it *harder* to find

oh, the other thing, again non-PEP8, was the occasional >80 char line.

btw one way round the vim issue is to have, at the beginning (or better, the
end) of each file, is a "#:ex set ts=4; set sw=4; set expandtab" command,
which vim will pick up and execute.  you need this at the bottom of _every_
file if you intend to have non-PEP8-standard indentation.   there's probably
an emacs version of the same thing you could add at the same time.

ok, that ts=4 and sw=4 is only if you're actually setting tabs to 4 spaces;
if you're expecting tabs to be 8 and shiftwidth to 4, resulting in *mixed*
tabs and space indentation, that's _very_ bad, and will result in continuous
irritation and loss of contributors as their choice of editor conflicts with
the non-PEP8-standards-based indentation, but you can get away with it
(just) by adding :ex set ts=8; set sw=4; set expandtab

Sebastian Hilbert wrote:
>> btw there _are_ limitations in the proxyapp, such as "if the service
>> dies,
>> the proxy barfs" taking _all_ the current connections with it.  but, if
>> you
>> can put up with it for now, or never encounter a problem, great.
> Thanks for the hint.

oh, i managed to solve that one.  if the back-end dies and is restarted, the
proxy can't "reset" the client's connection, so you have to disconnect and
reconnect, but once you have it's happy again.  i'm sure i'll find a way to
fix that, too, some time.

Sebastian Hilbert wrote:
>> the only thing that's going to be a bit of a pain is the separation
>> between
>> "fetch data" and "display data" which that onRemoteResponse thing shows
>> you
>> how to do, but trust me when i say that this _is_ an advantage in terms
>> of
>> UI responsiveness.
> You do realize that using pyjamas for GNUmed will most likely mean more 
> questions for you (via mailing list) :-) ?

 *grin* yup.  fortunately there are others on the list.  as long as you're
throwing stuff directly into the git repo, it'll be easy enough to keep an
eye on.


View this message in context:
Sent from the GnuMed - Dev mailing list archive at

reply via email to

[Prev in Thread] Current Thread [Next in Thread]