Forthcoming syntax changes in Robot Framework

[Pekka Klärck]

Hi all,

We try to avoid syntax changes because they always cause annoying
backwards incompatibility issues. When adding new features or
enhancing the framework otherwise, they cannot, however, be totally
avoided.

Right now we are planning to add native IF/ELSE [1] and possibly also
TRY/EXCEPT [2] support for Robot Framework and as a precondition we
are currently re-implementing the test data parser [3]. Both the new
syntax and the new parser cause some syntax changes explained below
along with some other unrelated syntax changes.

[1] https://github.com/robotframework/robotframework/issues/3074
[2] https://github.com/robotframework/robotframework/issues/3075
[3] https://github.com/robotframework/robotframework/issues/3076


= TL;DR summary =

This email is somewhat long and goes into not-that-interesting
details. I recommended reading it fully, though, especially if you are
responsible for a big amount of Robot Framework data. Here's a summary
if you are in a hurry:

- Old FOR loop syntax and some other features are going to be
deprecated in RF 3.2. Good idea to start using the new syntax already
now.
- New parser causes smallish syntax changes in RF 3.2. They will be
deprecated already in RF 3.1.2. Upgrade to that version once it's
available to see are you affected.


= FOR loop syntax changes =

To ease the usage of the forthcoming IF/ELSE and TRY/EXCEPT features
(including nested usages), we've decided to change also the FOR loop
syntax. The new syntax is this:

*** Test Cases ***
Example
FOR ${item} IN some items
Log ${item}
Another keyword
END

This syntax is supported already by Robot Framework 3.1 and is *very
highly recommended* unless you need to support older versions. The old
syntax will be deprecated in RF 3.2. For more details about using
`FOR` (case-sensitive) instead of `:FOR` (case-insensitive) and
closing the loop with `END` see [4] and [5], respectively.

[4] https://github.com/robotframework/robotframework/issues/2990
[5] https://github.com/robotframework/robotframework/issues/3009


= List and dictionary variable item access changes =

The old way to access items in a variable containing a list or a
dictionary has been `@{list}[0]` or `&{dict}[key]`, respectively. This
didn't work well with nested lists/dictionaries and RF 3.1 unified the
syntax to use `${list}[0]` or `${dict}[key]` instead [6]. The old
syntax will be deprecated in RF 3.2 [7] and it's a good idea to change
to the new syntax already before that unless older RF versions need to
be supported.

[6] https://github.com/robotframework/robotframework/issues/2601
[7] https://github.com/robotframework/robotframework/issues/2974


= Small changes to using `...` =

As you probably know, you can use `...` in the beginning of a line to
indicate that this line actually continues the previous one. The new
parser is going to change how this syntax works in some special cases:

- If a keyword call has a line with only `...`, currently this line is
totally ignored. In the future such a line is considered to contain a
single empty value. [8]
- You cannot anymore create tests or keywords with literal name `...`. [9]
- When constructing longer documentation, the rules related to joining
items in a single line will change. [10]

These changes shouldn't affect anyone in practice, but because there's
so much test data out there someone may still be affected. To make it
easier to spot possible changes, we are going to deprecate these
features in RF 3.1.2 and only change the syntax in RF 3.2. For more
information see [8], [9] and [10].

[8] https://github.com/robotframework/robotframework/issues/3107
[9] https://github.com/robotframework/robotframework/issues/3105
[10] https://github.com/robotframework/robotframework/issues/3106


= Small changes to handling whitespace =

The old parser considers only the normal ASCII space and the no-break
space to be spaces when it splits rows in test data to items. There
are, however, various other spaces [11] and all those are currently
converted to a normal space later during parsing. Additionally
consecutive spaces are currently collapsed into a single space (this
can only happen with the pipe separated format). In general the
current whitespace handling isn't very consistent.

It doesn't make sense for the new parser to behave inconsistently like
the old parser does. The plan is to change the logic like this:

- Any space character is considered a separator.
- Non-ASCII spaces in data aren't converted to normal spaces.
- Consecutive spaces aren't collapsed.

These changes shouldn't affect anyone in practice either, but with the
big amount of test data around we cannot be 100% sure. Also these
features are thus going to be first deprecated in RF 3.1.2 and then
changed in RF 3.2 by the new parser. For more details see issue [12]
where you can also comment if you think some of the planned changes
aren't good.

[11] https://en.wikipedia.org/wiki/Whitespace_character
[12] https://github.com/robotframework/robotframework/issues/3121


Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org