Re: Rawest raw string literals

On 2017-04-22 23:13, Mikhail V wrote: > k = r"abc > def" > > gives an error: > > k = r"abc > ^ > SyntaxError: EOL while scanning string literal > > So one could define a rule, that a raw string *must* > be terminated by the sequence quote + newline. > In theory. Though

Re: Rawest raw string literals

On Sun, Apr 23, 2017 at 7:13 AM, Mikhail V wrote: > So one could define a rule, that a raw string *must* > be terminated by the sequence quote + newline. > In theory. Then how would you pass one as a function parameter? func(r"" ) Ugh. Ugly. ChrisA --

Re: Rawest raw string literals

On 20 April 2017 at 18:40, Grant Edwards wrote: > On 2017-04-20, Mikhail V wrote: >> On 20 April 2017 at 17:59, Grant Edwards wrote: >>> On 2017-04-20, Mikhail V wrote: Quite often I need raw

Re: Rawest raw string literals

Tim Chase writes: > On 2017-04-21 08:23, Jussi Piitulainen wrote: >> Tim Chase writes: >>> Bash: >>> cat <>> "single and double" with \ and / >>> EOT >>> >>> PS: yes, bash's does interpolate strings, so you still need to do >>> escaping within, but the

Re: Rawest raw string literals

On 2017-04-21 08:23, Jussi Piitulainen wrote: > Tim Chase writes: >> Bash: >> cat <> "single and double" with \ and / >> EOT >> >> PS: yes, bash's does interpolate strings, so you still need to do >> escaping within, but the arbitrary-user-specified-delimiter idea >> still holds. > > If you

Re: Rawest raw string literals

Tim Chase writes: > A number of tools use a custom quote-string: > > Bash: > > cat < "single and double" with \ and / > EOT [snip] > PS: yes, bash's does interpolate strings, so you still need to do > escaping within, but the arbitrary-user-specified-delimiter idea still > holds. If you

Re: Rawest raw string literals

On 2017-04-21 01:11, Tim Chase wrote: On 2017-04-20 16:40, Grant Edwards wrote: How can there exist a "universal solution" even in theory? There has to be some sort of "end of literal" terminator character sequence. That means there has to be some sort of escaping mechanism when that "end of

Re: Rawest raw string literals

On 2017-04-20 16:40, Grant Edwards wrote: > How can there exist a "universal solution" even in theory? > > There has to be some sort of "end of literal" terminator character > sequence. That means there has to be some sort of escaping > mechanism when that "end of literal" sequence appears in

Re: Rawest raw string literals

On 2017-04-20 22:03, Mikhail V wrote: On 20 April 2017 at 22:43, Random832 wrote: On Thu, Apr 20, 2017, at 16:01, Grant Edwards wrote: On 2017-04-20, MRAB wrote: > There _is_ a "universal solution"; it's called a Hollerith constant. :-)

Re: Rawest raw string literals

On Fri, Apr 21, 2017 at 7:37 AM, Stefan Ram wrote: > Mikhail V writes: >>But the less probable it is, the more complex or ugly would the tag >>become. >>E.g. curly braces {} seems to be much less frequent characters >>for filenames and command line

Re: Rawest raw string literals

On 20 April 2017 at 22:43, Random832 wrote: > On Thu, Apr 20, 2017, at 16:01, Grant Edwards wrote: >> On 2017-04-20, MRAB wrote: >> > There _is_ a "universal solution"; it's called a Hollerith constant. :-) >> >> Wow, I haven't seen one of

Re: Rawest raw string literals

On 20 April 2017 at 19:27, Chris Angelico wrote: > On Fri, Apr 21, 2017 at 2:26 AM, wrote: >> I find this:- >> >> s = r"ffmpeg -i '\\server-01\D\SER_Bigl.mpg' " >> >> vastly superior. > > It's semantically different though. I don't know whether single

Re: Rawest raw string literals

On Thu, Apr 20, 2017, at 16:01, Grant Edwards wrote: > On 2017-04-20, MRAB wrote: > > There _is_ a "universal solution"; it's called a Hollerith constant. :-) > > Wow, I haven't seen one of those in a _long_ time -- probably about 45 > years. I think the first FORTAN

Re: Rawest raw string literals

On 2017-04-20, MRAB wrote: > On 2017-04-20 17:40, Grant Edwards wrote: > >> There has to be some sort of "end of literal" terminator character >> sequence. That means there has to be some sort of escaping mechanism >> when that "end of literal" sequence appears in the

Re: Rawest raw string literals

On 2017-04-20 17:40, Grant Edwards wrote: On 2017-04-20, Mikhail V wrote: On 20 April 2017 at 17:59, Grant Edwards wrote: On 2017-04-20, Mikhail V wrote: Quite often I need raw string literals for concatenating console

Re: Rawest raw string literals

No escaping is not something possible, in your suggested syntax ") is ambigous. E.g. raw("abcd")") is ambigous. Any sequence delimited string involves escaping, the only thing that wouldnt would be size-defined strings but they are impractical. Le 20/04/2017 à 18:03, Mikhail V a écrit : On

Re: Rawest raw string literals

On Thu, Apr 20, 2017 at 5:27 PM, Chris Angelico wrote: > On Fri, Apr 21, 2017 at 2:26 AM, wrote: >> I find this:- >> >> s = r"ffmpeg -i '\\server-01\D\SER_Bigl.mpg' " >> >> vastly superior. > > It's semantically different though. I don't know whether

Re: Rawest raw string literals

On Fri, Apr 21, 2017 at 2:26 AM, wrote: > I find this:- > > s = r"ffmpeg -i '\\server-01\D\SER_Bigl.mpg' " > > vastly superior. It's semantically different though. I don't know whether single quotes are valid in that context, on Windows. ChrisA --

Re: Rawest raw string literals

On Thursday, April 20, 2017 at 4:59:48 PM UTC+1, Grant Edwards wrote: > On 2017-04-20, Mikhail V wrote: > > Quite often I need raw string literals for concatenating console commands. > > I want to input them exactly as they are in python sources. > > > > There is r"" string, but it is obviously

Re: Rawest raw string literals

On 2017-04-20, Mikhail V wrote: > On 20 April 2017 at 17:44, Mikhail V wrote: >> Quite often I need raw string literals for concatenating console commands. >> I want to input them exactly as they are in python sources. >> >> There is r"" string, but it

Re: Rawest raw string literals

On 2017-04-20, Mikhail V wrote: > On 20 April 2017 at 17:59, Grant Edwards wrote: >> On 2017-04-20, Mikhail V wrote: >>> Quite often I need raw string literals for concatenating console commands. >>> I want to input them

Re: Rawest raw string literals

On Fri, Apr 21, 2017 at 2:16 AM, Mikhail V wrote: > On 20 April 2017 at 17:59, Grant Edwards wrote: >> On 2017-04-20, Mikhail V wrote: >>> Quite often I need raw string literals for concatenating console commands. >>> I want

Re: Rawest raw string literals

On 20 April 2017 at 17:59, Grant Edwards wrote: > On 2017-04-20, Mikhail V wrote: >> Quite often I need raw string literals for concatenating console commands. >> I want to input them exactly as they are in python sources. >> >> There is r""

Re: Rawest raw string literals

On Fri, Apr 21, 2017 at 2:03 AM, Mikhail V wrote: > On 20 April 2017 at 17:55, Chris Angelico wrote: >> On Fri, Apr 21, 2017 at 1:44 AM, Mikhail V wrote: >>> What I think: why there is no some built-in function, for example like: >>>

Re: Rawest raw string literals

On 20 April 2017 at 17:55, Chris Angelico wrote: > On Fri, Apr 21, 2017 at 1:44 AM, Mikhail V wrote: >> What I think: why there is no some built-in function, for example like: >> s = raw("ffmpeg -i "\\server-01\D\SER_Bigl__"") >> >> which would just need

Re: Rawest raw string literals

On 2017-04-20, Mikhail V wrote: > Quite often I need raw string literals for concatenating console commands. > I want to input them exactly as they are in python sources. > > There is r"" string, but it is obviously not enough because e.g. this: > s = r"ffmpeg -i

Re: Rawest raw string literals

On 20 April 2017 at 17:44, Mikhail V wrote: > Quite often I need raw string literals for concatenating console commands. > I want to input them exactly as they are in python sources. > > There is r"" string, but it is obviously not enough because e.g. this: > s = r"ffmpeg -i

Re: Rawest raw string literals

On Fri, Apr 21, 2017 at 1:44 AM, Mikhail V wrote: > What I think: why there is no some built-in function, for example like: > s = raw("ffmpeg -i "\\server-01\D\SER_Bigl__"") > > which would just need *one* quote sign in the beginning and on the end. > Would it be useful,