-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PR 3 for #570: the name 'ast' #580
Conversation
@lieryan Many thanks for your recent comments in the (closed) PR #579. Instead of sleeping on them, I swam in the lap pool. Standing in the shower and sitting in the locker room I saw:
We are close to resolving all the issues! We can discuss some minor preferences, but these will not be fraught. I now understand the code well enough so that I could live with it as it is (except for uncontroversial cleanups). My efforts on these PRs have been a form of initiation. I'm not complaining! I've learned a lot. Btw, I trashed my first fork because I could see no obvious way to get it to a pristine state. Better just to create the new fork. At last I understand the confusion In the legacy code, rope.base.ast defines 5 functions: Let us assume some module contains the following import:
Experts (like you) and initiated apprentices (like me) "just know" that for This problem might be invisible to you because of the "curse of knowledge." I can tell you that this "overloading" of the imported What to do The minimal change would be to leave everything exactly as it is, except for a prominent comment in rope/base/ast.py. This post would be pre-writing for such a comment :-) I could live with this, but I would like to discuss alternatives. Each has (minor?) drawbacks, but imo each does eliminate the confusion. Idea 1: Qualify ast.AST nodes with ast.ast.
Idea 2: Import ast from rope.base.ast
Other variations on these two themes are possible. Summary Doing nothing except adding a comment has some appeal. I can live with it. Using the @lieryan Please let me know your wishes. |
@lieryan Thanks for the comment. I'll remove all such useless methods. |
When I awoke this morning, I wanted to push back about rope.base.ast. Sorry, not sorry :-) I am enjoying our conversation--it is respectful even when heated. We are beginning to know each other as engineers and as persons. We are making progress, but imo our debate deserves to continue for as long as it takes. Yes, I could live with the code in master, but I would rather not :-) On to the specifics! We agree that namespaces are a honking good idea, but significant questions remain about the
Purpose: Contents: There is significant name clash within Clarity: Devs must understand the internals of Tools: Summary Not all modules are a honking good idea. |
@lieryan I'm fixing/suppressing pylint complaints. These two (no, three) complaints look like they point to real problems in the tests: ropetest\projecttest.py:1014:8: W1503: Redundant use of assertTrue with constant value '.ropeproject' (redundant-unittest-assert)
ropetest\projecttest.py:1066:8: W1503: Redundant use of assertTrue with constant value 'create_file ' (redundant-unittest-assert)
ropetest\projecttest.py:1082:8: W1503: Redundant use of assertTrue with constant value 'create_file ' (redundant-unittest-assert) The corresponding code: def test_getting_project_rope_folder(self):
self.project = testutils.sample_project(ropefolder=".ropeproject")
self.assertTrue(self.project.ropefolder.exists())
self.assertTrue(".ropeproject", self.project.ropefolder.path)
def test_normal_fscommands(self):
fscommands = _MockFSCommands()
self.project = testutils.sample_project(fscommands=fscommands)
myfile = self.project.get_file("myfile.txt")
myfile.create()
self.assertTrue("create_file ", fscommands.log)
def test_deprecated_fscommands(self):
fscommands = _DeprecatedFSCommands()
self.project = testutils.sample_project(fscommands=fscommands)
myfile = self.project.get_file("myfile.txt")
myfile.create()
self.assertTrue("create_file ", fscommands.log) I'm not sure what was intended. Do you have any suggestions? |
@edreamleo Thanks for finding those issues, these |
@lieryan I have converted this PR to a draft one again. I'll incorporate the commits that cleaned imports into a new PR. When that PR becomes part of master I'll merge master into this PR, thereby reducing this PR's size. I'll also study at master to see whether I want to pursue this PR at all. |
I am going to close this PR. A new PR (if I choose to submit one) will have the effect of squashing commits and rebooting our conversation. |
Locking this thread. Please continue any remaining thread of discussions on #575 |
See #570. Supersedes PR #579.