Regression: Fails handling triple backquotes with lang tag about sybil

[Marenz]

I forgot to add: If I remove the python part in my example, it works again

[Marenz]

I just realized we do a heavy amount of our own parsing in the linked module.

Specifically here, we use example.end to find the end of the sample and in previous versions that seemed to
match with position before the terminating tripple quotes.

[cjw296]

I forgot to add: If I remove the python part in my example, it works again

Is the example even executed/checked if you do this?

Specifically here, we use example.end to find the end of the sample and in previous versions that seemed to match with position before the terminating tripple quotes.

It did, but that was a bug, even appears in the release notes ;-)

[Marenz]

It did, but that was a bug, even appears in the release notes ;-)

I was wondering about that..one persons bug is another persons feature 😆

We're doing that extra parsing because we try to have the original line numbers, but maybe I am just not using some existing features to get the same?

Anyway, closing since it's not a bug, but appreciate any pointers if I can do it better.

[cjw296]

Can you try changing this:

        example_code = textwrap.dedent(
            example.document.text[example.start : example.end]
        )

to this:

        example_code = example.parsed

[cjw296]

Am I right in reading your code as only running pylint over the example rather than actually executing the examples?

Getting line numbers right is hard, especially if you're modifying the source before executing it. Sybil used to do that style of modification, but I managed to eradicate it by using compile flags instead, partly because getting it right is so hard.

Nonetheless, here's what Sybil does to get this right:

sybil/sybil/evaluators/python.py

Lines 23 to 26 in 9e12507

	def __call__(self, example: Example) -> None:
	# There must be a nicer way to get line numbers to be correct...
	source = pad(example.parsed, example.line + example.parsed.line_offset)
	code = compile(source, example.path, 'exec', flags=self.flags, dont_inherit=True)

[Marenz]

Am I right in reading your code as only running pylint over the example rather than actually executing the examples?

I mean, executing them fully is certainly desirable, but many of our code requires remote end points for most examples to work :)

I'll try your suggestions as soon as I have some time :) Thanks!

[Marenz]

sybil/sybil/evaluators/python.py

Lines 23 to 26 in 9e12507

	def __call__(self, example: Example) -> None:
	# There must be a nicer way to get line numbers to be correct...
	source = pad(example.parsed, example.line + example.parsed.line_offset)
	code = compile(source, example.path, 'exec', flags=self.flags, dont_inherit=True)

What I don't understand about this code (I do the padding the same), you use example.parsed, but that text bit has all the empty lines removed, thus it must also result in wrong line numbers the further you get to the end (more skipped blank lines).

Otherwise that whole hack I did would be obsolete as I could just use .parsed.

[cjw296]

you use example.parsed, but that text bit has all the empty lines removed

I don't believe this is the case, can you show me an example of .parsed having empty lines removed?

Otherwise that whole hack I did would be obsolete as I could just use .parsed.

That's my hope :-) But, to get the line numbers right, you still have to prefix with the right number of newlines to match where the example was found in the source, and also the number of newlines between the start of the example and the actual line within the example, which is what the code on line 25 above is doing.

[Marenz]

I don't believe this is the case, can you show me an example of .parsed having empty lines removed?

Sure, any example works for that for me.. I added the following code to the already linked snippets for the comparison:

        # Dedent the code example
        # There is also example.parsed that is already prepared, but it has
        # empty lines stripped and thus fucks up the line numbers.
        example_code = textwrap.dedent(
            example.document.text[example.start : example.end]
        )
        # Remove first line (the line with the triple backticks)
        example_code = example_code[example_code.find("\n") + 1 :]

        print(f"Example code: >\n{example_code}<")
        print(f"=================\n.parsed: >\n{example.parsed}<")

Output:

Example code: >
a = 2
# blank line follows this

b = 3
<
=================
.parsed: >
a = 2
# blank line follows this
b = 3
<

[cjw296]

I added a test for this in https://github.com/simplistix/sybil/pull/116/files
It appears to show that no blank lines are removed by the MyST PythonCodeBlockParser.

It you could work up a similar PR to the one above that shows the problem you are experiencing, I can take a look.

Otherwise, can you confirm this verifies the behaviour is introduced somewhere in your code?

[Marenz]

I'll see if I can make a test

[Marenz]

#117