Re: Rawest raw string literals

[Tim Chase]

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 one can do

  k = r"""abc
 def
 ghi
 jkl
 mno
 pqrs
 \tuv
 wxyz
 """


which keeps the "\" while allowing multi-line strings.

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Chris Angelico]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Mikhail V]

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 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  "\\server-01\D\SER_Bigl.mpg" "
>>>
>>>s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '
>>>
>>> Does that do what you want?
>>
>> Yes but it still needs to watch out if there is no ' inside or vice
>> versa with " characters if use r"". I would like a universal
>> solution.
>
> IOW, you want something that just reads your mind.
>
> 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 the literal itself.
>

In *theory* one can define what characters can be part of the raw string.
In Python e.g. the newline character cannot be part of
the r"" string (unless a line ends with \):

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.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Jussi Piitulainen]

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 arbitrary-user-specified-delimiter idea
>>> still holds.
>> 
>> If you put any quote characters in the initial EOT, it doesn't.
>> Quote removal on the EOT determines the actual EOT at the end.
>> 
>>   cat <<"EOT"
>>   Not expanding any $amount here
>>   EOT
>
> Huh, I just tested it and you're 100% right on that.  But I just
> re-read over that section of my `man bash` page and don't see anything
> that stands out as detailing this.  Is there something I missed in the
> docs?

It's in this snippet, yanked straight from the man page:

   The format of here-documents is:

  <<[-]word
  here-document
  delimiter

   No  parameter expansion, command substitution, arithmetic expansion,
   or pathname expansion is performed on word.  If  any  characters  in
   word  are  quoted,  the  delimiter is the result of quote removal on
   word, and the lines in the here-document are not expanded.  If  word
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Tim Chase]

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 put any quote characters in the initial EOT, it doesn't.
> Quote removal on the EOT determines the actual EOT at the end.
> 
>   cat <<"EOT"
>   Not expanding any $amount here
>   EOT

Huh, I just tested it and you're 100% right on that.  But I just
re-read over that section of my `man bash` page and don't see
anything that stands out as detailing this.  Is there something I
missed in the docs?

Thanks for this little tip (filing away for future use)

-tkc


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Jussi Piitulainen]

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 put any quote characters in the initial EOT, it doesn't. Quote
removal on the EOT determines the actual EOT at the end.

  cat <<"EOT"
  Not expanding any $amount here
  EOT
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[MRAB]

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 literal" sequence appears in the
literal itself.


A number of tools use a custom quote-string:

Bash:

   cat <
Perl 5 also does this.

[snip]
--
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Tim Chase]

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 the
> literal itself.

A number of tools use a custom quote-string:

Bash:

  cat 

Re: Rawest raw string literals

[MRAB]

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. :-)

Wow, I haven't seen one of those in a _long_ time -- probably about 45
years.  I think the first FORTAN implementation I used was WATFIV,
which had just introduced the character type. But, books/classes on
FORTRAN all still covered Hollerith constants.


The IMAP protocol uses a similar kind of construct (the length is
enclosed in braces)

Even ignoring the maintenance difficulty, I don't think it's possible to
syntax highlight something like that on most common editors.

The best solution I can think of is to have a text editor designed to
parse a string literal, spawn a nested editor with the unescaped
contents of that string literal, and then re-escape it back to place in
the code. If we had that, then we wouldn't even need raw strings.


Yes exactly, it would be cool to have such a satellite app
which can escape and unescape strings according to rules.
And which can also convert unicode literals to their ascii
analogues and back on the fly, this would very useful
for programming.
Probably it is a good idea to even include such thing
in Python package. So it would be a small standalone app
running parallel with text editor making it to copy paste strings.


I'm sure it's possible in, say, Emacs.

The editor that I use (EditPad Pro) can call external tools, so I could:

1. Select the string literal (easy when it is syntax-aware, so I can 
select all of the literal with 2 keypresses).


2. Call the external tool (1 keypress), to open, say, a simple tkinter app.

3. Edit the unescaped text (unescape with ast.literal_eval, re-escape 
with 'ascii').


4. Close the external tool, and the selection is replaced.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Chris Angelico]

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 arguments.
>
>   When one uses brackets to delimit string literals,
>   on even can allow /nested/ brackets to be part of
>   the string without escapes, e.g., the literal
>
> [abc[def]ghi]
>
>   can stand for the string
>
> abc[def]ghi
>
>   . Only unpaired brackets then have to be escaped
>   (and occurences of the escape symbol at the end
>   of such a string).

If you're going to use brackets like that, I'd prefer a
multi-character delimiter:

[[[abcdef]]]

But you have to be careful about the nesting, because that makes it
difficult to create a string with an imbalanced set of delimiters.
You'll end up with messy and complicated edge cases.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Mikhail V]

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 those in a _long_ time -- probably about 45
>> years.  I think the first FORTAN implementation I used was WATFIV,
>> which had just introduced the character type. But, books/classes on
>> FORTRAN all still covered Hollerith constants.
>
> The IMAP protocol uses a similar kind of construct (the length is
> enclosed in braces)
>
> Even ignoring the maintenance difficulty, I don't think it's possible to
> syntax highlight something like that on most common editors.
>
> The best solution I can think of is to have a text editor designed to
> parse a string literal, spawn a nested editor with the unescaped
> contents of that string literal, and then re-escape it back to place in
> the code. If we had that, then we wouldn't even need raw strings.

Yes exactly, it would be cool to have such a satellite app
which can escape and unescape strings according to rules.
And which can also convert unicode literals to their ascii
analogues and back on the fly, this would very useful
for programming.
Probably it is a good idea to even include such thing
in Python package. So it would be a small standalone app
running parallel with text editor making it to copy paste strings.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Mikhail V]

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 quotes
> are valid in that context, on Windows.
>

For ffmpeg on Windows at least, both single and double quotes work equally.
So yes, if I keep the rule to use single quotes only inside commands
then I'd be fine with r"".
I simply don't like single quotes, and tend to use doble quotes
everywhere for better readability.

Well it is just somewhat unfortunate, because literals use
the quotes as a open/close tag, which are very common character in
strings. So the idea was to choose something that is not so
frequent and much less probable to appear in a string.
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 arguments.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Random832]

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 implementation I used was WATFIV,
> which had just introduced the character type. But, books/classes on
> FORTRAN all still covered Hollerith constants.

The IMAP protocol uses a similar kind of construct (the length is
enclosed in braces)

Even ignoring the maintenance difficulty, I don't think it's possible to
syntax highlight something like that on most common editors.

The best solution I can think of is to have a text editor designed to
parse a string literal, spawn a nested editor with the unescaped
contents of that string literal, and then re-escape it back to place in
the code. If we had that, then we wouldn't even need raw strings.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Grant Edwards]

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 literal itself.
>> 
> 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 implementation I used was WATFIV,
which had just introduced the character type. But, books/classes on
FORTRAN all still covered Hollerith constants.

-- 
Grant Edwards   grant.b.edwardsYow! Look!  A ladder!
  at   Maybe it leads to heaven,
  gmail.comor a sandwich!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[MRAB]

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 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  "\\server-01\D\SER_Bigl.mpg" "


   s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '

Does that do what you want?


Yes but it still needs to watch out if there is no ' inside or vice
versa with " characters if use r"". I would like a universal
solution.


IOW, you want something that just reads your mind.

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 the literal itself.


There _is_ a "universal solution"; it's called a Hollerith constant. :-)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Arthur Havlicek]

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 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 *one* quote sign in the beginning and on the end.
Would it be useful, what do you think? I think looks better than triple quote.
In the past there were quite a lot additions to string manipulation,
probably there is already something like this.

What would be the argument passed to this function?

ChrisA


Yeah that is right, I cant imagine how this would work.
But I think you get the idea- I'd want something dedicated
to input raw strings with cute syntax and *no* escaping
at all.


Mikhail


--
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[eryk sun]

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 single quotes
> are valid in that context, on Windows.

On Windows, whether forward slash can be used as a path separator and
whether single quotes escape spaces and special characters depends on
the programs involved.

If you use the lpApplicationName parameter of CreateProcess (i.e.
`executable` for Popen), the system doesn't have to look at the
command line. Otherwise if the path of the executable in the command
line contains spaces, it needs to be quoted using double quotes;
single quotes have no special significance. If it has to search for
the executable, it calls SearchPath with the API's executable search
path (i.e. the directory of the calling application, the current
directory [in legacy mode], system directories, plus the PATH
environment variable) and .EXE as the optional file extension to
append.

Beyond that, the application can implement any command-line parsing
rules. In practice most programs use the CRT's argv parameter from the
`[w]main` entry point. Microsoft's CRT delimits arguments using
spaces; quotes arguments using double quotes; and escapes double
quotes using backslash [1].

If you're using the cmd.exe shell to run this, spaces and special
characters are escaped with double quotes, or with '^' outside of
quotes - except there's no way to completely escape "%" in a cmd.exe
command line (in a batch script, percent can be escaped by doubling it
as %%). If quoted, the path to the executable can use forward slash as
a path delimiter. cmd.exe implements its own custom search for the
executable, which includes the current directory (in legacy mode) and
PATH. It also tries appending all of the extensions in PATHEXT instead
of just .EXE. Since it uses the lpApplicationName parameter when it
calls CreateProcess, the system doesn't have to re-parse the command
line to locate the executable.

[1]: http://msdn.microsoft.com/en-us/library/17w5ykft.aspx
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Chris Angelico]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[breamoreboy]

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 not enough because e.g. this:
> > s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "
> 
>s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '
> 
> Does that do what you want?
> 
> -- 
> Grant Edwards   grant.b.edwardsYow! And then we could sit
>   at   on the hoods of cars at
>   gmail.comstop lights!

I find this:-

s = r"ffmpeg -i  '\\server-01\D\SER_Bigl.mpg' "

vastly superior.

Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Grant Edwards]

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 is obviously not enough because e.g. this:
>> s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "
>>
>> is not valid.
>>
>> The closest I've found is triple quote literal:
>> s = r"""ffmpeg -i  "\\server-01\D\SER_Bigl__" """
>>
>> This is what I use now, still there is problem: last quote inside the string
>> needs escaping or a space character before closing triple quote,
>> otherwise there is again an error.
>>
>> 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, what do you think? I think looks better than triple 
>> quote.
>> In the past there were quite a lot additions to string manipulation,
>> probably there is already something like this.
>
> A function probably would not be possible to implement directly,
> but probably such a syntax for example:
> s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg""r
>
> i.e. an opening and closing "r" particle.

What do you do when the sting '"r' appears in the literal?

All you've done is change the literal terminating character sequence.
You still have to have a mechanism to escape it.

-- 
Grant Edwards   grant.b.edwardsYow! World War Three can
  at   be averted by adherence
  gmail.comto a strictly enforced
   dress code!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Grant Edwards]

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 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  "\\server-01\D\SER_Bigl.mpg" "
>>
>>s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '
>>
>> Does that do what you want?
>
> Yes but it still needs to watch out if there is no ' inside or vice
> versa with " characters if use r"". I would like a universal
> solution.

IOW, you want something that just reads your mind.

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 the literal itself.

-- 
Grant Edwards   grant.b.edwardsYow! I brought my BOWLING
  at   BALL -- and some DRUGS!!
  gmail.com

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Chris Angelico]

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 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  "\\server-01\D\SER_Bigl.mpg" "
>>
>>s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '
>>
>> Does that do what you want?
>>
>
> Yes but it still needs to watch out if there is no ' inside or vice versa
> with " characters if use r"". I would like a universal solution.

There's no universal solution, by definition. The nearest you'll get
is something like the PostgreSQL "dollar string":

$SomeTag$any text$SomeTag$

You can choose any tag you like for SomeTag and it'll match only the
corresponding tag, so this can be nested. But it's long and ugly,
especially when you don't need to actually nest it.

Python is not a shell scripting language, and trying to treat it as
one is usually going to get you into tangles like this. Much better,
IMO, is to treat Python as a scripting language, where higher-level
constructs like lists are the norm.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Mikhail V]

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"" string, but it is obviously not enough because e.g. this:
>> s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "
>
>s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '
>
> Does that do what you want?
>

Yes but it still needs to watch out if there is no ' inside or vice versa
with " characters if use r"". I would like a universal solution.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Chris Angelico]

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:
>>> 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, what do you think? I think looks better than triple 
>>> quote.
>>> In the past there were quite a lot additions to string manipulation,
>>> probably there is already something like this.
>>
>> What would be the argument passed to this function?
>>
>> ChrisA
>
>
> Yeah that is right, I cant imagine how this would work.
> But I think you get the idea- I'd want something dedicated
> to input raw strings with cute syntax and *no* escaping
> at all.

Yep. It can't be a function; it has to be a piece of language syntax.

So then the question is: what language syntax is appropriate? And
honestly, I hardly ever need this kind of thing - partly because I
wouldn't call ffmpeg this way. I'd do it like this:

cmd = ["ffmpeg", "-i", r"\\server-01\D\SER_Bigl.mpg"]

with the separate arguments as, well, separate arguments. Far less
need for double escaping that way, and you can use different escaping
rules for different arguments if you need to. (Actually, I usually use
forward slashes, so even raw string lits are unnecessary.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Mikhail V]

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 *one* quote sign in the beginning and on the end.
>> Would it be useful, what do you think? I think looks better than triple 
>> quote.
>> In the past there were quite a lot additions to string manipulation,
>> probably there is already something like this.
>
> What would be the argument passed to this function?
>
> ChrisA


Yeah that is right, I cant imagine how this would work.
But I think you get the idea- I'd want something dedicated
to input raw strings with cute syntax and *no* escaping
at all.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Grant Edwards]

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  "\\server-01\D\SER_Bigl.mpg" "

   s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '

Does that do what you want?

-- 
Grant Edwards   grant.b.edwardsYow! And then we could sit
  at   on the hoods of cars at
  gmail.comstop lights!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Mikhail V]

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  "\\server-01\D\SER_Bigl.mpg" "
>
> is not valid.
>
> The closest I've found is triple quote literal:
> s = r"""ffmpeg -i  "\\server-01\D\SER_Bigl__" """
>
> This is what I use now, still there is problem: last quote inside the string
> needs escaping or a space character before closing triple quote,
> otherwise there is again an error.
>
> 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, what do you think? I think looks better than triple quote.
> In the past there were quite a lot additions to string manipulation,
> probably there is already something like this.

A function probably would not be possible to implement directly,
but probably such a syntax for example:
s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg""r

i.e. an opening and closing "r" particle.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Chris Angelico]

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, what do you think? I think looks better than triple quote.
> In the past there were quite a lot additions to string manipulation,
> probably there is already something like this.

What would be the argument passed to this function?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list