Sidney Cadot: Yes, newline (ascii 10, decimal).

Sidney Cadot: A handful of OEIS entries have a similar issue. I'm fixing those as they potentially wreak havoc with automated parsing. (I know I had to adapt my parser to handle them without issue, but it violates a rather hard requirement that all main files lines should start with a directive).

Andrew Howroyd: I doubt this is ascii 10 newline. If you look at https://oeis.org/A357975/internal then there is no line break. The character is visible. If you are not pulling from  https://oeis.org/A357975/internal then from where? This is clearer in some of the other Mma examples you found. The back-end to my understanding is Unix (or Linux) which does not use a combo \r\n to break lines. Also I have not encountered this. (so my guess is that this is one of the many unicode line break chars). In any case, good to fix.

Andrew Howroyd: closer inspection of the glyph says it is lsep https://www.fileformat.info/info/unicode/char/2028/index.htm

Sidney Cadot: Had a closer look. The encoded byte sequence retrieved from the server is 0xe2 0x80 0xe8, in UTF-8. It appears that, in Pythion, this specific character is mapped immediately to a plain '\n' (0x10), which is what it looks like to me after that. My script retrieves OEIS entries using Python and inserts the string into a local SQLite3 database. So you are right. That's very useful information for me -- it means that the conversion to a Python string is lossy. I will have to think how to handle that. So while getting rid of the character is useful, my initial report was indeed incorrect as you point out.

Sidney Cadot: Last message was wrong in several ways. The sequence is 0xe2 0x80 0xa8, which indeed maps currently to '\u2028' in Python and survives storage in an SQLIte3 database and subsequent retrieval. So I will have to dig a bit deeper why my code signals it as an '\n' character. (FYI: as you may have guessed, I have written a lint-like tool for OEIS entries).

Andrew Howroyd: Python has been modernized to deal with unicode. You probably cannot stop it translating unicode line separators. (without writing/overriding some low-level binary -> text stream class). The right thing to do is to remove them - I was just curious as to what they were and now that we know we can still eliminate them.

Andrew Howroyd: (btw I'm just happily inventing the rules here - this time to your benefit.)

Andrew Howroyd: Out of interest what ASCII / Unicode char is this? Surely not newline (\n)?

Sidney Cadot: The "crossrefs" section (%Y) had a spurious newline character after the line "Positions of first appearances are A297002, sorted A066207.", and thus an empty line, violating the constraint that all lines in a main file should start with a % directive.