File names with slashes [was Re: error in os.chdir]

[MRAB]

On 2018-07-02 18:16, Richard Damon wrote:
> On 7/2/18 9:20 AM, Mikhail V wrote:
>> [Richard Damon]
>>
>>> The one major issue with backslashes is that they are a special
>>> character in string literals, so you either need to use raw literals a
>>> remember the few cases they still act as special characters, or remember
>>> to convert them to double back slashes, at a minimum for all the
>>> characters that they are special for (easier to double them all).
>>> I think it was originally an error to make the backslash followed by a
>>> character not defined as special with a backslash as keeping the
>>> backslash as a literal as it causes a number of these issues. Yes, it
>>> allows you to not need to double it in many cases but that just sets you
>>> up for the mistakes that started the thread. It is probably too late to
>>> change that behavior now though.
>> Yes this would at least make less mistakes.
>> I find the whole situation with strings a bit disappointing.
>> On the one hand - there were so many string types added, on the other
>> hand - there are still many inconveniences. There is an english proverb,
>> "it does too much, but still too little". (or something like that)
>>
>> The initial string syntax -- I think it's direct copy of C strings syntax.
>> And it sucks. (path dependency?)
>>
>> I'd say there should be just two main string types:
>> 1. string literal where all special character goes into, say, figure braces {};
>> (if only there was a time machine)
>> 2. raw strings, including multiline raw strings which should be PEP-8 compliant.
>>
>> So Imo default syntax should be something like:
>>
>>     S = "A:{x41}B:{x42}"
>>
>> instead of backslashes and Co.
> 
> Yes, the backslash notation is just like what C uses (an likely the
> source of it). The exact same problem pops up in the C forums too. Not
> sure where it got the notation from.
> 
C is descended from BCPL, which used '*', e.g. newline was "*N".