On 25/05/2018 05:34, Mikhail V wrote:
Proposal
-----------
Current proposal suggests adding syntax for the "raw text" statement.
This should enable the possibility to define text pieces in source
code without the need for interpreted characters.
Thereby it should solve the mentioned issues.
Additionally it should solve some issues with visual appearance.
General rules:
--------
- parsing is aware of the indent of containing
block, i.e. no de-dention needed.
- single line assignment may be allowed with
some restrictions.
Difficulties:
--------
- change of core parsing rules
- backward compatibility broken
- syntax highlighting may not work
I had one big problem with your proposal, which is that I couldn't make
head or tail of your syntax. Such a thing should be immediately obvious.
(In your first two examples, what IS the exact string that you're trying
to incorporate? That is not clear at all.)
The aim is to allow arbitrary text in program source which is to be
interpreted as a string literal, and to be able to see the text as much
in its natural form as possible.
One problem here is how to deal with embedded non-printable characters:
CR, LF and TAB might become part of the normal source text, but how
about anything else? Or would you only allow text that might appear in a
text file where those characters would also cause issues?
Another thing that might come up: suppose you do come up with a workable
scheme, and have a source file PROG1.PY which contains such raw strings.
Would it then be possible to create a source file PROG2.PY which
contains PROG1.PY as a raw string? That is, without changing the text
from PROG1.PY at all.
Here's one scheme I use in another language:
print strinclude "file.txt"
'strinclude "file.txt"' is interpreted as a string literal which
contains the contents of file.txt, with escapes used as needed. In fact
it can be used for binary files too.
This ticks some of the boxes, but not all: the text isn't shown inline
in the program source code. If you send someone this source code, they
will also need FILE.TXT.
And it won't pass my PROG2/PROG1 test above (because both strincludes
need expanding to strings, but the compiler won't recognise the one
inside PROG1, as that is after all just text, not program code).
As for a better proposal, I'm inclined not to make it part of the
language at all, but to make it an editor feature: insert a block of
arbitrary text, and give a command to turn it into a string literal.
With perhaps another command to take a string literal within a program
and view it as un-escaped text.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
