This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Tim.Graham, abarry, brett.cannon, martin.panter, ncoghlan, ned.deily, r.david.murray, rhettinger, serhiy.storchaka, yan12125, yselivanov
Date 2016-09-16.02:18:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Regarding when I think the error should be generated, we definitely want the warning to be happening at compile time, but the "compile step" is actually a series of substeps.

The point where the string parser is processing string escapes is *not* the best place to complain about unrecognised ones, as it doesn't have the ability to report the appropriate context for where the offending string exists in the code base (hence this issue report, and the misattribution problem in the generated warning).

Instead, you probably want to look at delaying generation of the error until the point where AST Bytes and Str nodes are being generated for inclusion in the AST, as at that point the code generator has access to full file, line, and column information regarding the location of the problematic escape.

However, I also expect you'll run into a problem where you'll need to be able to embed *something* in the processed string that lets the latter stage of the pipeline detect that there was an unknown escape rather than a properly escaped usage of "\\" (which is presumably why the "immediate warning" approach was attempted first - it doesn't need that ability to communicate with the latter stage of the pipeline).
Date User Action Args
2016-09-16 02:18:56ncoghlansetrecipients: + ncoghlan, brett.cannon, rhettinger, ned.deily, r.david.murray, martin.panter, serhiy.storchaka, yselivanov, Tim.Graham, yan12125, abarry
2016-09-16 02:18:56ncoghlansetmessageid: <>
2016-09-16 02:18:56ncoghlanlinkissue28128 messages
2016-09-16 02:18:55ncoghlancreate