On Jun 2, 5:31 pm, Terry Brown <terry_n_br...@yahoo.com> wrote:
> class t(object):
>
> def m1(self):
> pass
>
> m = m1
>
> def m2(self, func=m):
> print func
>
> I know that's a weird piece of code, but I think you could argue the m = m1
> belongs with the m2 definition in that case.
Your example is more complicated than mine, but it's a good addition
to the topic. It shows a particular use case when python-specific
stuff provides specific meaning for the code.
After looking at your example, I'm making an attempt to simplify mine.
Let's consider the following code (not necessary pythonic, but it's
important that the language shall allow variable assignements inside
the class body):
--- cut here ---
class MyClass:
def method1(self):
pass
foo = bar
def method1(self):
pass
--- cut here ---
Here are the the possible options for the leo parser that I see:
- 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)
- 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
- 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.
--
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.
