On Wed, 2 Jun 2010 08:09:16 -0700 (PDT)
zpcspm <zpc...@gmail.com> wrote:
> A) stick to the default assumptions that it uses now (I'm not happy
> with them, and I don't like the idea of modifying some code base just
> for the sake of fitting into the leo import algorithms)
> B) put the code blocks that have the same indentation as class methods
> (but are not class methods themselves) in their own subnodes of the
> class node
> C) use an option set by the user to decide if it needs to include the
> "code" part in the "method-code-method" scenario into the first node
> body or into the second one, this shall also include the special case
> "method-code" at the end of the class body
>
> Your comments are welcome.
Not sure how (C) would work, seems like code could belong to the preceding of
following def randomly throughout a class def. The same issue comes up at the
module level of course.
I like (B), it seems to me that putting code into def nodes (with the exception
of @decorators) can lead to a lot of confusion, as the code may have some
adverse impact and you might have trouble finding it. Comments are harmless of
course, but you still might miss an important comment for function X if the
comment gets shoved into function Y's node.
So,
class foo(object):
"""class to do some stuff"""
stream_base = sys.stdout
def m_int(self, x):
pass
mdef = m_int
# minty doesn't do anything
def minty(self):
pass
raise SystemExit
would be cut like this
class foo(object):
"""class to do some stuff"""
--------------------------------------
stream_base = sys.stdout
--------------------------------------
def m_int(self, x):
pass
--------------------------------------
mdef = m_int
# minty doesn't do anything
--------------------------------------
def minty(self):
pass
--------------------------------------
raise SystemExit
producing nodes like this
foo
foo code
m_int
foo code
minty
foo code
the two bad cuts in this case are the node containing only 'stream_base =
sys.stdout', which might have been better left in the foo node (containing the
class name line and docstring), and the separation of the comment about minty
from the def of minty. For the stream_base case... perhaps the class node
should contain everything up to the first def (or nested class)? For the minty
case, dumb place to put the comment, no way to tell whether it applies to the
preceding or following def.
Cheers -Terry
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
