I just published my solution for Circular Buffer, but I’m not seeing it in the Community Solutions.
I think the website does some magic to detect similar solutions and tries to show one solution of every “type”. If there are similar solutions, yours may not show up.
This is correct. If your solution matches that of an existing solution, it’ll be “merged into” that solution (at least as far as displaying community solutions is concerned). The benefit of this is that browsing community solutions will not show you duplicate solutions.
2 Likes
The closest solution I can find is this. Although that is similar to mine, there are a few differences in how I handle the read and overwrite functions. My solution is 1 line fewer. Also, there is this, which is line-for-line identical to mrattner’s solution, and both of those solutions show up.
@erikschierboom The missing " About this solution" block on the linked page makes me think that the representation hasn’t been generated for this solution (or something else is stopping that from showing), which means its likely also not been indexed etc.
Something I did notice is that when I submitted the solution, it said “Processing” for quite a while. I then refreshed the page, it is said “Passed”. I wonder if some event got missed. I’ll make a small change to my solution and see if that fixes it.
1 Like
Hi @rzuckerm,
I just ran your code through the representer manually, and it has an issue.
While the empty BufferFullException(BufferError) & BufferEmptyException(BufferError) class definitions aren’t causing test failure (they should, but that’s a different issue), the fact that they are not valid Python code is causing the representer to toss an error and fail out without making a representation. Without a representation, indexing and grouping/posting to community solutions doesn’t happen.
Edited to add: We normalize student code in the representer to remove docstrings/comments, and a function/class def without a body or a pass or a doctstring is not valid Python code.
Your code is creating the following error in the representer:
Traceback (most recent call last):
File "/opt/representer/bin/run.py", line 56, in <module>
main()
File "/opt/representer/bin/run.py", line 52, in main
representer.represent(args.slug, args.input, args.output)
File "/opt/representer/representer/__init__.py", line 110, in represent
out[0:0] = ['## BEGIN NORMALIZED CODE ##', representation.dump_code(), "## END NORMALIZED CODE ##", '']
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/representer/representer/__init__.py", line 47, in dump_code
return utils.reformat(code)
^^^^^^^^^^^^^^^^^^^^
File "/opt/representer/representer/utils.py", line 71, in reformat
return black.format_str(single_space(text), mode=black.FileMode())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/black/__init__.py", line 1154, in format_str
dst_contents = _format_str_once(src_contents, mode=mode)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/black/__init__.py", line 1164, in _format_str_once
src_node = lib2to3_parse(src_contents.lstrip(), mode.target_versions)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/black/parsing.py", line 128, in lib2to3_parse
raise exc from None
black.parsing.InvalidInput: Cannot parse: 5:0: class placeholder_1(BufferError):
When we create representations, we use the black formatting tool to format the normalized output. Black cannot parse the code in those two Error class definitions, because it isn’t valid Python once the docstrings are removed.
All function and class definitions must have an executable body. Having a docstring is not enough – there must be compilable code like a docstring or other statement (or the pass keyword), or the definition is not considered valid. If Python were a language that used {} and ;, that would be enough for a no-op, but instead Python uses pass for stubbing out definitions.
Adding pass to each class definition after the docstring or copying back in the code for the two classes from the stub file should solve your issue.
It doesn’t solve mine, however. Looks like the tests need to guard against the invalid definitions, or I need to add an analyzer rule or two. 
2 Likes
@BethanyG If there is a docstring, pass is unnecessary. All the tests pass locally (and on the server), and pylint doesn’t complain about the lack of pass. This is also something I’ve done numerous times in production code.
I think a class definition with only a docstring is perfectly valid Python code.
>>> class Foo:
... """Hello."""
...
>>> Foo()
<__main__.Foo object at 0x7dec90695b90>
@BethanyG I format my code with black before I submit it, and I run it through pylint. Anyway, I resubmitted with the pass statement, and it’s showing up now. However, I think you tooling needs to be fixed.
The language reference says the class needs an expression. I think a string is a valid expression.
Or, rather, it needs a suite but an expression is a valid suite. And I think a string is a valid expression.
Actually, the process of stashing the docstring does indeed create a “valid” definition, so my bad there. And yes, having a variable with a string would also be valid within the body, or an ellipsis, None, or return.
HOWEVER
Our representer normalizes the code by removing docstrings, so the resulting empty def is invalid Python by the time it gets to Black. 
1 Like
@BethanyG OK, that makes sense if the comments and docstrings are removed, then just a class definition is not valid. I’ll have to remember that for next time. Thanks!
Ouch! That makes more sense!
Sadly, if we didn’t remove comments, docstrings (and typhints), most solutions would be “unique”, which would somewhat defeat the purpose of representations.
The placeholder stuff also makes me nuts, but variable naming is also something that is pretty unique, so.
2 Likes
Would replacing all comments and docstrings etc with a standard docstring (rather than deleting them) fix this?
Maybe. I think that might then require all representations to be re-run, and the golden tests to be redone. Not a biggie, but yeah.
Or I could check if a function/class is empty after the docstring removal and put pass in the body. That would also require a few new tests/reworks, but maybe not a complete re-run of solutions.
I can take a look at how much work it would be when I next have time to work on the representer issues that are open. I have a nasty bug with typehints and newer Dataclass features that needs fixing, so trying to set aside time for it.
1 Like