More of a Q: Empty lines

[MementoRC]

My preference is that the empty lines in the original code remains (as much as possible) in the modified code. There is a small change that enables this in the PreciseUnparser, however, it seems to be by design (connected comments vs non-connected in the test_ast.py) that empty lines are not considered. Is it better to create a new PreciseEmptyLinesUnparser? or simply it is a matter of preference and no need to PR since my needs are met in my fork?

[isidentical]

Hey MementoRC, thanks a lot fo the PR(s) and the questions! I think the empty lines can also be preserved, but we need to be careful (a lot of tests of scenarios, especially with inner replaces) I'll try to take a look at them as soon as possible (hopefully tomorrow)

[MementoRC]

@isidentical For the InsertAfter and InsertBefore, I like to have a separating line sometimes, is it the right way to add and InserBeforeWithSeparator, ... classes to the actions? or is there a mean to add options to the existing classes? The new class only has the following addition:

        # Adding extra separating line
        replacement.append(lines._newline_type)

[isidentical]

@isidentical For the InsertAfter and InsertBefore, I like to have a separating line sometimes, is it the right way to add and InserBeforeWithSeparator, ... classes to the actions? or is there a mean to add options to the existing classes? The new class only has the following addition:

I think it makes sense to have an option in both of them that takes separator: str | None (for InsertAfter, that's between the target <-> new node, and for InsertBefore it is between the new node <-> target).

[MementoRC]

This does not seem to be possible with the dataclass, that is for LazyInsertAfter since InsertAfter inherits from it and would have to define it first in the list of arguments passed to the instantiation - Or at least, this is above my padawan-level ;P Hints? Help?