Re: [Python-Dev] Why aren't escape sequences in literal strings handled by the tokenizer?

Eric V. Smith wrote: I assume the intent is to not throw away any information in the lexer, and give the parser full access to the original string. But that's just a guess. More likely it's because the lexer is fairly dumb and can basically just recognise regular expressions. -- Greg

Re: [Python-Dev] [Python-checkins] bpo-33522: Enable CI builds onVisual Studio Team Services (GH-6865) (GH-6925)

Fair point. It was because the new platforms are not identical to any of our existing ones and so exposed gaps in our tests (and one wart in tempfile, which I had explicitly reviewed by two others and gave its own bug and NEWS item). Pre-squashing, the change had nearly 100 attempts at

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

17.05.18 21:39, Brett Cannon пише: Maybe we should start thinking about flagging PRs or issues as needing a What's New entry to help track when they need one, or always expect it in a PR and ignore that requirement when a 'skip whats new' label is applied. That would at least make it easier to

[Python-Dev] Normalisation of unicode and keywords

Stephan Houben noticed that Python apparently allows identifiers to be keywords, if you use Unicode "mathematical bold" letters. His explanation is that the identifier is normalised, but not until after keywords are checked for. So this works: class Spam: locals()['if'] = 1 Spam.퐢퐟#

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

On 5/18/18 9:20 AM, Ivan Pozdeev via Python-Dev wrote: > Since Python uses semantic versioning (https://semver.org), the > criterion for "what's new-worthy" changes is simple: they are _public > interface changes_ (which include visible changes to documented behavior). > (I maintain that changes

[Python-Dev] please help triage VSTS failures

These both look like VSTS infrastructure falling over on PRs: https://python.visualstudio.com/cpython/_build?buildId=522 https://python.visualstudio.com/cpython/_build?buildId=523 I don't see anywhere that gives information about the failures. (*) These CI failures on different platforms are

Re: [Python-Dev] please help triage VSTS failures

On Fri, May 18, 2018 at 10:55 AM, Gregory P. Smith wrote: > These both look like VSTS infrastructure falling over on PRs: > > https://python.visualstudio.com/cpython/_build?buildId=522 > > https://python.visualstudio.com/cpython/_build?buildId=523 > > I don't see anywhere that

Re: [Python-Dev] Normalisation of unicode and keywords

It's a canonicalisation error. Steve Holden On Fri, May 18, 2018 at 2:38 PM, Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > On 18.05.2018 14:46, Steven D'Aprano wrote: > >> Stephan Houben noticed that Python apparently allows identifiers to be >> keywords, if you use Unicode

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2018-05-11 - 2018-05-18) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open6686 (+42) closed 38637 (+66) total 45323 (+108) Open issues

Re: [Python-Dev] [Python-checkins] bpo-33522: Enable CI builds on Visual Studio Team Services (GH-6865) (GH-6925)

On Thu, May 17, 2018 at 11:32 PM Gregory P. Smith wrote: > Why did this commit modify .py files, unittests, and test.support? > That is inappropriate for something claiming to merely enable a CI platform. I think there is probably an argument to be made that some of the

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

On 18.05.2018 10:55, Serhiy Storchaka wrote: 17.05.18 21:39, Brett Cannon пише: Maybe we should start thinking about flagging PRs or issues as needing a What's New entry to help track when they need one, or always expect it in a PR and ignore that requirement when a 'skip whats new' label is

Re: [Python-Dev] Normalisation of unicode and keywords

On 18.05.2018 14:46, Steven D'Aprano wrote: Stephan Houben noticed that Python apparently allows identifiers to be keywords, if you use Unicode "mathematical bold" letters. His explanation is that the identifier is normalised, but not until after keywords are checked for. So this works: class

Re: [Python-Dev] please help triage VSTS failures

On 5/18/2018 4:13 PM, Steve Dower wrote: Close/reopen PR is the best way to trigger a rebuild right now. It may be the way to retrigger VSTS, but if one want to merge, and either of Travis or AppVeyor pass, tossing the success is a foolish thing to do. Either may fail on a rebuild. --

Re: [Python-Dev] please help triage VSTS failures

Unfamiliar maybe, though I’m a big fan of separating build and test logs. If anyone is motivated enough to make unittest/regrtest generate Junit format XML then we can get a nice breakdown by individual test, too, which would save scrolling through the log entirely. The asyncio instability is

Re: [Python-Dev] please help triage VSTS failures

On Fri, May 18, 2018 at 4:15 PM Steve Dower wrote: [..] > The asyncio instability is apparently really hard to fix. There were 2-3 people looking into it yesterday on one of the other systems, but apparently we haven’t solved it yet (my guess is lingering state from a

Re: [Python-Dev] please help triage VSTS failures

On Fri, May 18, 2018 at 1:13 PM, Steve Dower wrote: > According to the VSTS dev team, an easy “rerun this build” button and > filtering by changed paths are coming soon, which should clean things up. If you're talking to them, please ask them to make sure that the "rerun

Re: [Python-Dev] please help triage VSTS failures

Hah, yes, that was un-intuitive for me. I was looking for something labelled "logs" to click on. thanks. (I hope MS is taking notes on UX issues here) So these failures were in fact the known flakes and not infrastructure. good! On the high level view of VSTS output on a failure: "Issues:

Re: [Python-Dev] please help triage VSTS failures

Hmm... I would guess that it would create a new "build” and likely lose the link to the original (though it would still be kept, just harder to find). Then again, the existing support for rerunning a release through VSTS keeps all the previous attempts... I’ll mention it, but the quickest fix