Skip to content
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

Implement exercise dot-dsl #978

Merged
merged 15 commits into from
Nov 21, 2017
Merged

Implement exercise dot-dsl #978

merged 15 commits into from
Nov 21, 2017

Conversation

ackerleytng
Copy link
Contributor

@ackerleytng ackerleytng commented Oct 24, 2017

Will fix #732

@ackerleytng
Copy link
Contributor Author

ackerleytng commented Oct 24, 2017

Okay, I think I'm pretty much done with implementing this exercise to close #732, please review it, thanks!!

Copy link
Contributor

@cmccandless cmccandless left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maintainers note: As of this time, there is no canonical data for this exercise.

Looks good to me!


Observe the test cases in `dot_dsl_test.py` to understand the DSL's design.

### Submitting Exercises
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per #950 , this should be at heading level 2 instead of 3.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved it to level 2!

@ilya-khadykin ilya-khadykin changed the title [WIP] Implement exercise dot-dsl Implement exercise dot-dsl Oct 25, 2017
Copy link
Contributor Author

@ackerleytng ackerleytng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved it to level 2!


Observe the test cases in `dot_dsl_test.py` to understand the DSL's design.

### Submitting Exercises
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved it to level 2!

Copy link
Contributor

@N-Parsons N-Parsons left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your implementation looks good, but I've left a few questions as comments.

config.json Outdated
"maps",
"object_oriented_programming",
"test_driven_development",
"transforming"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reasoning for including maps, test_driven_development and transforming?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I left maps there, I was thinking of dictionaries. Now that I think of it again, I think maps probably means something else, in this case.

For object_oriented_programming, I thought that since we were using classes, it was fair to leave that as a topic.

For test_driven_development, I think there isn't any other way to complete this other than by reading through the test cases and building up the DSL, so I thought TDD is accurate here.

As for transforming, I thought it was fair to say that DSLs are a transformation of one representation of data to another.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your explanation. I don't think that maps is a suitable topic here, but domain_specific_languages and graphs would probably be a sensible additions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

self.attrs = attrs

def __eq__(self, other):
return self.name == other.name and self.attrs == other.attrs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering whether it might be better not to implement this but to instead hint that it should be implemented? I feel like rather a lot of code is being supplied pre-written, without the user having to think about how to check for equality. I think that we should either set a lower difficulty for this problem, or we should add a .meta/hints.md that lets the user know that they need to implement the __eq__ method themself (with each method being stripped down to just pass).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was concerned that without defining __eq__, the tests wouldn't even pass. A lot of the test cases, such as

        self.assertEqual(g.nodes, [Node("a", {"color": "green"})])

requires __eq__ to be defined properly for the check to work.

Perhaps we could say that as part of TDD, the person working on this topic should seek to first complete __eq__ so that test cases work as the human would expect?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at it again, I think it should be ok to leave it as it is - I'm not a great fan of supplying too much code, but the definition is also fairly easy and could border on being tedious.


for item in data:
if len(item) != 3 and len(item) != 4:
raise TypeError("Graph item malformed")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this check really necessary? Surely the conditionals below will achieve the same but with a more informative output?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm but without these checks,

            type_ = item[0]

might raise an IndexError if len(item) < 1.

Or should I just say

            if len(item) < 3:
                raise TypeError("Graph item incomplete")

?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well spotted, I think that would be a sensible change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

raise ValueError("EDGE malformed")
self.edges.append(Edge(item[1], item[2], item[3]))
else:
raise TypeError("Unknown item {}".format(item[0]))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain the reasoning for using a TypeError here instead of a ValueError here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed it to a ValueError, thanks for pointing this out!

I thought about it and decided to follow the guidelines here

Fixed this in commit 812140a on the dot-dsl branch

Changed associated test cases

Create a DSL similar to the dot language.

## Description of DSL
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section should also go into a .meta/hints.md file so that it doesn't get lost if we regenerate the READMEs in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

@N-Parsons
Copy link
Contributor

Sorry for taking a while to get back to this - I've had a rather busy couple of weeks!

There are a couple of minor issues that need to be resolved, and then this will be ready to merge:

  • Creation of .meta/hints.md (comment)
  • Change the input validation to avoid an IndexError (comment)
  • Update topics in config.json (comment)

Copy link
Contributor

@N-Parsons N-Parsons left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ackerleytng Just a couple of minor changes that need to be made, and then this will be ready to merge.

The implementations of `Node` and `Edge` provided in `dot_dsl.py`.

Observe the test cases in `dot_dsl_test.py` to understand the DSL's design.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The this description should still be here! The contents of the .meta/hints.md file are put here when someone runs configlet generate to regenerate the READMEs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok made the change!

"test_driven_development",
"transforming"
]
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current version of exercism goes through the exercises in the order specified in the config. I don't think that this should be a particularly early exercise, so can you move this section down to around line 750 or so (the exact location isn't too important).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved it lower!

@N-Parsons
Copy link
Contributor

Looks good, thanks @ackerleytng!

@N-Parsons N-Parsons merged commit 5a81d6a into exercism:master Nov 21, 2017
N-Parsons pushed a commit to N-Parsons/exercism-python that referenced this pull request Nov 21, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

dot-dsl: implement exercise
4 participants