Cannot modify spaces after trailing comma

[kayhayen]

The following code:

(self, )

Note the trailing space after the comma. I was writing a modifier that removes trailing and leading spaces. And came up with this:

if "\n" not in tuple_node.dumps():
    tuple_node.second_formatting = ""
    tuple_node.third_formatting = ""

    for argument in tuple_node.value:
        if argument.type in ("string", "binary_string"):
            argument.second_formatting = ""

Note, that I find it strange, that I need to drop leading spaces from contained strings (same for
call nodes, strings seem to attract whitespace for no good reason, where I would naturally attribute it to the outside). I tried setting all four formattings to "x#", and this resulted a string containing them, plus still a space after the comma. Where is it hiding? The name typed argument doesn't indicate anything in its dict.

[Psycojoker]

Hello,

The problem you are facing right now is that, by default, RedBaron hides from you the comma tokens using ProxyList has described here: https://redbaron.readthedocs.org/en/latest/proxy_list.html The unproxyfied list is accessible using ".node_list": https://redbaron.readthedocs.org/en/latest/proxy_list.html#access-the-unproxified-node-list

You have several solutions to go to the last comma:

from redbaron import RedBaron
red = RedBaron("(self, )")
red[0].value.node_list[-1].second_formatting = ""
red[0]("comma", recursive=False)[-1]

Is this help? I'm wondering on how to makes this more obvious to people (this is already describe at the end of the tutorial and in the documentation :/).

[kayhayen]

Hello Laurent,

You have several solutions to go to the last comma:

from redbaronimport RedBaron
red= RedBaron("(self, )")
red[0].value.node_list[-1].second_formatting= ""
red0[-1]

That works, with the gotcha, that I need to consider "with_parenthesis",
or else I remove it for such code as well:

a, = b

which is different (to me) from

(a, ) = b

A relatively constant theme, is that I do not always agree, where
spaces are allocated. I would want to assign the space before and
after theequals sign to an assignment node, never the rvalue and
lvalue.

I understand for strings, that "a" "b" is legal, and that the
whitespace needs storage, while it's still a string node.

But this leads to calls:

call( 1 )
call( "a" )

having entirely different assignment of spaces for the call node.

So my code checks for string arguments, and treats them differently, as
it does for bytestrings, and raw strings. I am tempted to raise an issue
for this. I think for the last string, it should not consume any spaces
but leave them to its parent.

But I don't understand the difficulties of inserting items properly
formatted in the same way. Maybe it's not even feasible to get what I
consider the natural assignment of spaces.

Yours,
Kay

[Psycojoker]

That works, with the gotcha, that I need to consider "with_parenthesis",
or else I remove it for such code as well:

a, = b

which is different (to me) from

(a, ) = b

A solution for this case would be to always remove it from the last
comma of the tuple and always put it on the left side of the "=".

I don't know if this is an acceptable solution for you, please let me
know.

A relatively constant theme, is that I do not always agree, where
spaces are allocated. I would want to assign the space before and
after theequals sign to an assignment node, never the rvalue and
lvalue.

I understand for strings, that "a" "b" is legal, and that the
whitespace needs storage, while it's still a string node.

But this leads to calls:

call( 1 )
call( "a" )

having entirely different assignment of spaces for the call node.

So my code checks for string arguments, and treats them differently, as
it does for bytestrings, and raw strings. I am tempted to raise an issue
for this. I think for the last string, it should not consume any spaces
but leave them to its parent.

Indeed, you are correct, the string here are greedy on getting
surrounding formatting tokens. I'm going to open an issue for that. I
think this is fixable (probably taking the approach you are
suggesting) but might take me some time.

Laurent Peuch -- Bram

[Psycojoker]

String aren't greedy anymore so this shouldn't be a problem now, don't hesitate to complain if it's still the case.

[kayhayen]

Great, just ran it with 0.3 over my code, and it found a few extra places to correct.