Raw string statement (proposal)

[Steven D'Aprano]

On Sat, 26 May 2018 18:22:15 +0300, Mikhail V wrote:

>> Here is a string assigned to name `s` using Python's current syntax:
>>
>> s = "some\ncharacters\0abc\x01\ndef\uFF0A\nhere"
>>
>> How do you represent that assignment using your syntax?
> 
> Hope its not mandatory to decipher your random example. If for example
> I'd want to work with a lot of non-presentable characters, I'd use a
> more human-oriented notation than this ^. And that is exactly where raw
> strings are needed.
> 
> So I'd make a readable notation where I can present a character by its
> ordinal enclosed in some tag for example {10}. Then just write a
> function which collapses those depending on further needs:
> 
> data >>| abc{10}def
> data = f(data)
> 
> And the notation itself can be chosen depending on my needs. Hope you
> get the point.

Loud and clear: your syntax has no way of representing the string s.

Okay, let's take a simpler example. You want to use {65290} to represent 
the Unicode code point \uFF0A. Fair enough. Everyone else in the world 
uses hexadecimal for this purpose, but whatever.

But isn't {65290} just another way of spelling an escape code? Isn't your 
syntax supposed to eliminate the need for escape codes?

So if I had:

    result = function("Mikhail's syntax for \uFF0A is {65290}")

your syntax would become:

    temp = >>| Mikhail's syntax for {65290} is {65290}
    result = function(f(temp))

where f is your (as yet non-existent?) function for collapsing the {} 
codes to characters.

Can you see the problem yet? How does your collapse function f() 
distinguish between the escape code {65290} and the literal string 
{65290}?

And we've gone from a single string literal, which is an expression that 
can be used anywhere, to a statement that cannot be used in expressions.



>> And another example:
>>
>> s = """this is some text
>> x = 'a'
>> y = 'b'"""
>> t = 'c'
>>
>> How do we write that piece of code using your syntax?
> 
> That's too easy - maybe you can try it yourself? I am not trying to
> imply anything, but I don't see how this example can cause problems -
> just put the TQS in a block.

I don't know what TQS is supposed to mean.

I'll give it a try, and see if I understand your syntax. The idea is to 
avoid needing to put BEGIN END delimiters such as quotation marks around 
the string, right?


s = >>>
this is some text
x = 'a'
y = 'b'
t = 'c'


Am I close?

How is the interpreter supposed to know that the final line is not part 
of the string, but a line of actual Python code?

[...]
>> Bart said WITHOUT CHANGING THE TEXT. Indenting it is changing the text.
> 
> I know. So you've decided to share that you also understood this? Good,
> I'm glad that you understand :-)

I believe that the whole point of your proposal to avoid needing to 
change the text in any way when you paste it into your source code. If 
that's not the point, then what is the point?


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson