Mailman 3 August 2015 - Python-Dev

PEP 498 f-string: is it a preprocessor?
by Victor Stinner Aug. 11, 2015

Aug. 11, 2015

Hi, I read the PEP but I don't understand how it is implemented. For me, it should be a simple preprocessor: - f'x={x}' is replaced with 'x={0}'.format(x) by the compiler - f'x={1+1}' is replaced with 'x={0}'.format(1+1) - f'x={foo()!r}' is replaced with 'x={0!r}'.format(foo()) - ... That's all. No new language, no new function or method. It's unclear to me if arbitrary expressions should be allowed or not. If not, we may pass parameters by keywords instead: f'x={x}' is replaced with 'x={x}… [View More]

2 6

PEP 498 f-string: please remove the special case for spaces
by Victor Stinner Aug. 11, 2015

Aug. 11, 2015

PEP 498: """ Leading whitespace in expressions is skipped <https://www.python.org/dev/peps/pep-0498/#id28> Because expressions may begin with a left brace ('{'), there is a problem when parsing such expressions. For example: >>> f'{{k:v for k, v in [(1, 2), (3, 4)]}}' '{k:v for k, v in [(1, 2), (3, 4)]}' """ For me, this example is crazy. You should not add a special case (ignore spaces) just to support a corner case. This example can easily be rewritten using a temporary … [View More]

7 14

Instructions on the new "push request" workflow for 3.5.0rc1+ through 3.5.0 final
by Larry Hastings Aug. 11, 2015

Aug. 11, 2015

As of Python 3.5.0rc1, the canonical repository for Python 3.5.0 is *no longer* on hg.python.org. Instead, it's hosted on Bitbucket on my personal account, here: https://bitbucket.org/larry/cpython350 Since 3.5.0rc1 isn't out yet I'm keeping the repository private for now. Once 3.5.0 rc1 is released (hopefully Monday) I'll flip the switch and make the repository public. (I'll email python-dev and python-committers when that happens.) Putting it succinctly, here's a table of versions … [View More]and where you'd check in for your change to go there: 3.5.0 : https://bitbucket.org/larry/cpython350 (branch "3.5") 3.5.1 : hg.python.org/cpython (branch "3.5") 3.6.0 : hg.python.org/cpython (branch "default") You'll notice nobody but myself has checkin permissions for my 3.5.0 repo on Bitbucket. That's on purpose. The only way you can get changes in to 3.5.0 now is by sending me a Bitbucket "pull request". This is a workflow experiment, to see if we as a community like this sort of new-fangled gizmo. For now, we're only using Bitbucket for the actual final checking-in stage. Requests for fixes to be accepted into 3.5.0 and code review will all still happen on the Python issue tracker. Also, I'm officially now asking you folks to do the forward-merge into 3.5.1 and 3.6.0 yourselves. Here's how to get a fix checked in for 3.5.0, starting with 3.5.0rc1+ and continuing through until 3.5.0 final. Pre-requisites: * You must have a Bitbucket account. * You must have commit rights to the CPython repository. 1. Create an issue on the Python issue tracker for the problem. 2. Submit a patch that fixes the problem. 3. Add me to the issue and get me to agree that it needs fixing in 3.5.0. (You can attempt this step before 2 if you prefer.) 4. Fork my repository into your Bitbucket account using their web GUI. To do that, go to Bitbucket, log in, then go to my 3.5.0 repo: https://bitbucket.org/larry/cpython350 and press the "Fork" link in the left column. Bitbucket has a tutorial on how to do this, here: https://confluence.atlassian.com/display/BITBUCKET/Fork+a+teammate%27s+repo… Note: DO NOT start with a conventional CPython trunk cloned from hg.python.org. The 3.5 branch in my repo and the 3.5 branch in normal CPython trunk have intentionally diverged and *need* to stay out-of-sync. 5. Make a local clone of your fork on your computer. Bitbucket has a tutorial on how to do that, here: https://confluence.atlassian.com/display/BITBUCKET/Copy+your+Mercurial+repo… Reminder: switch to the 3.5 branch! 6. Apply your change to the 3.5 branch and check in. Reminder: check in to the 3.5 branch! 7. Make sure you checked in your change to the 3.5 branch. Reminder: Seriously. I keep messing this up. I say, the more reminders, the better. 8. Push your change back to *your* fork on *your* Bitbucket account. Just normal "hg push" should work here. In case it helps, I recommend using the "https" protocol for this step, as it sidesteps ssh authentication and prompts you for your Bitbucket username and password. 9. Create a pull request using Bitbucket's web GUI. Bitbucket has a tutorial on how to create a pull request, here: https://confluence.atlassian.com/display/BITBUCKET/Create+a+pull+request On the "Create pull request" web GUI, make sure that you specify branch "3.5" for *both* your repo *and* my repo. Also, make sure you *don't* check the "Close 3.5 after the pull request is merged" check box. (If you use the "Compare" page, you also need to select "3.5" in both drop-down lists--one for my repo, and one for yours.) 10. Paste a link to the pull request into the issue tracker issue for this change request. 11. Wait for confirmation that I've accepted your pull request into the 3.5.0 repo. 12. Pull your accepted change from your local Bitbucket fork repo into a normal hg.cpython.org CPython repo, merge into 3.5, then merge into 3.6, then push. For the record, here's what *my* workflow looks like when I accept your pull request: 1. Click on the URL you pasted into the pull request. 2. Visually check that the diff matches the approved diff in the issue on the issue tracker. 3. Click on the "Merge" button. Frequently Asked Questions ========================== Q: What if someone sends me a "pull request" for a change that doesn't merge cleanly? A: Then I'll decline it, and ask you on the issue tracker to rebase and resubmit. Q: What if someone sends me a "pull request" but they don't have commit rights to CPython? A: I'll ignore it. I'll only pay attention to pull requests pasted into the issue tracker by someone with commit rights. Q: Whose name goes on the commit? A: It gets the name the checkin was made with. Don't worry, your name will stay on your commit. Q: This seems like a lot more work than the old way. A: For you guys, yes. But notice how little work it is for *me*! Seriously. Q: Can I reuse my fork / my local copy? Or do I have to create a fresh one each time? A: I don't care either way. All I care about are clean pull requests. If you're careful you should have no trouble reusing forks and local checkouts. If it were me, I'd probably use a fresh fork each time. Forks are cheap and this way is cleaner. I'll add these instructions to the Python Dev Guide in the next day or two. /arry p.s. Remember to use the 3.5 branch! [View Less]

2 2

[RELEASED] Python 3.5.0rc1 is now available
by Larry Hastings Aug. 11, 2015

Aug. 11, 2015

On behalf of the Python development community and the Python 3.5 release team, I'm relieved to announce the availability of Python 3.5.0rc1, also known as Python 3.5.0 Release Candidate 1. Python 3.5 has now entered "feature freeze". By default new features may no longer be added to Python 3.5. This is a preview release, and its use is not recommended for production settings. You can find Python 3.5.0rc1 here: https://www.python.org/downloads/release/python-350rc1/ Windows and … [View More]

1 0

Branch Prediction And The Performance Of Interpreters - Don't Trust Folklore
by Larry Hastings Aug. 11, 2015

Aug. 11, 2015

This just went by this morning on reddit's /r/programming. It's a paper that analyzed Python--among a handful of other languages--to answer the question "are branch predictors still that bad at the big switch statement approach to interpreters?" Their conclusion: no. Our simulations [...] show that, as long as the payload in the bytecode remains limited and do not feature significant amount of extra indirect branches, then the misprediction rate on the interpreter can be … [View More]

2 1

Python 3.5.0rc1 is delayed by a day
by Larry Hastings Aug. 10, 2015

Aug. 10, 2015

We retagged Python 3.5.0rc1 today to fix two bugs that popped up late in the process. Release candidates are supposed to be software you genuinely would release, and I couldn't release Python with both those bugs. This delay rippled through the whole process, so it just isn't going out tonight (late Sunday / early Monday in my timezone). I have every expectation it'll go out Monday. In case you're interested, the bugs are (were!): http://bugs.python.org/issue24745 http://bugs.… [View More]

1 0

Reminder: the "3.5" branch in CPython trunk is now 3.5.1
by Larry Hastings Aug. 9, 2015

Aug. 9, 2015

As I write this email I'm tagging Python 3.5.0 release candidate 1. This is the moment that we switch over to our new experimental workflow, where we use Bitbucket and pull requests for all future changesets that will get applied to 3.5.0. The Bitbucket repository isn't ready yet, and I'm still putting the final touches on the documentation for the process. I'll have everything ready no later than a day from now. It'll be posted here, and will also go into the Python Dev Guide. For … [View More]

1 0

SSH to hg.p.o okay?
by Steve Dower Aug. 8, 2015

Aug. 8, 2015

Is hg.python.org okay for others? I'm getting the following output from all hg commands: sending hello command sending between command abort: no suitable response from remote hg! I don't know of any more verbose or debugging options than that (--debug, -v's added nothing). I can SSH normally into hg.p.o, not that there's anything I can do without a terminal, but I guess it's not completely down...

2 3

Summary of Python tracker Issues
by Python tracker Aug. 7, 2015

Aug. 7, 2015

ACTIVITY SUMMARY (2015-07-31 - 2015-08-07) Python tracker at http://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: open 4992 (+31) closed 31595 (+32) total 36587 (+63) Open issues with patches: 2245 Issues opened (55) ================== #24759: Idle: add ttk widgets as an option http://bugs.python.org/issue24759 reopened by terry.reedy #24764: cgi.FieldStorage can't parse … [View More]

1 0

Bitbucket mirror is out-of-date
by Larry Hastings Aug. 7, 2015

Aug. 7, 2015

Bitbucket has a mirror of cpython, here: https://bitbucket.org/mirror/cpython It was last updated on May 7 and still says it's Python 3.5.0a4. It's not clear to me who owns the "mirror" account--is it Atlassian themselves? Anyway it'd be nice if it were, y'know, fresher. //arry/

1 0