Separate pynames and pynamesdef and remove star-import

[lieryan]

No description provided.

[lieryan]

@edreamleo this is my proposal if you really cannot have the import *

I'll expand further on why the #587 and related changes doesn't really make sense as a comment on that PR.

[edreamleo]

@lieryan Hurray! This works for me. Many thanks.

[edreamleo]

Many thanks for meeting me half way.

[lieryan]

Thanks for confirming that! Glad to find a common ground that we can both settle for.

While this has been a hard argument, but I think it is very worthwhile to think about these things and to always keep challenging and reevaluating incumbent design decisions. Thank you for making me have to think! It's a good kind of headache to have 😀.

[edreamleo]

@lieryan

While this has been a hard argument, but I think it is very worthwhile to think about these things and to always keep challenging and reevaluating incumbent design decisions. Thank you for making me have to think! It's a good kind of headache to have 😀.

You're welcome! You are teaching me about collaboration from another point of view. These are important lessons for me.

[edreamleo]

@lieryan The usual OO pattern is to derive, say, classes 'Cat' and 'Dog' from class 'Animal'.

But this PR continues to derive (for example) rope.base.pynamesdef.ParameterName from rope.base.pynames.ParameterName. There are other examples.

As I said in another recent comment, I'm not sure what the names of the base class should be, but it seems to me that Rope's code would be clearer if the names of base classes didn't class with the names of subclasses.

To repeat, the docstrings for the base classes could clarify what's going on.