[IPython-dev] IPython.fronend progress
Mon Jun 23 12:44:27 CDT 2008
>> At this point, I would appreciate comments on the entire frontend
>> package before we consider merging ipython-frontend into trunk.
> OK, some first impression comments:
> conding standards:
> * Some lines are longer than 80 characters. I don't like this as I
> keep all my windows open at 80 characters width, and I don't like
> lines wrapping.
True, when possible, we should stick to 80 chars.
> * The function naming convention is not systematic (eg
> frontendbase.py, line 101, there is a method with a CamelCase name,
> but right under there is one with underscore-sperated names.
> CamelCase is reserved for classes. I don't care what twisted, apple
> modules or wx does, they go against pep 8.
For the most part we do want to follow pep 8 conventions for IPython
code. But, there are cases (I don't know if things in the Cocoa
frontend fall into this case), like subclassing, where you have to use
the conventions established by a third party (twisted or pyobjc in
Barry's case). These other projects may go against pep 8, but we do
have to live with their conventions if we want to use their software.
In that sense, they don't care that we don't care :)
> On the code side of things, a lot of the methods in cocoa_frontend look
> like they are not Cocoa-specific. They should be moved in the
> frontendbase, IMHO.
> More will probably come, but I wanted to post this right now, less I
> never do it.
> Just a stupid question: is their a good reason for not merging this
> branch with trunk? It will probably get us more people running the code
> or reviewing it, though I must admit that the fact that the only
> available frontend is a cocoa one prevents me totally forom trying the
> code out.
The plan is to do a merge very soon. Barry is just doing good
development by 1) doing his work in a branch and 2) asking for code
review before merging. Kudos for that!
> IPython-dev mailing list
More information about the IPython-dev