Mailman 3 January 2014 - python-committers

Updated schedule for Python 3.4
by Larry Hastings 18 Jan '14

18 Jan '14

We've added a third beta and pushed the whole schedule out by three weeks. Assuming we stick to this schedule, beta 3 will be released Jan 26th, rc1 Feb 9, rc2 Feb 23, and final March 16th. That's all the details, but here's the release schedule PEP anyway: http://www.python.org/dev/peps/pep-0429/ My hope all along has been for 3.4 to ship before the PyCon US sprints start on April 14th, so that trunk would be open for 3.5 work. Right now that looks like no problem. Cheers, //arry/

11 19

3.3.4 planning
by Georg Brandl 16 Jan '14

16 Jan '14

Hi all, I'm planning to release 3.3.4 candidate 1 together with 3.4 beta 3, i.e. on the 26th -- and then 3.3.4 final two weeks later if nothing bad comes up. As always, there will be one more full 3.3 release after 3.4 final, probably in the May-June timeframe. cheers, Georg

2 1

Some topics I have suggested for the language summit
by Nick Coghlan 15 Jan '14

15 Jan '14

Working across multiple projects has highlighted for me lately how much unnecessary overhead we're currently dealing with in core development, and how ineffective we are at delegating responsibility for parts of the docs that aren't tied directly to the standard library and interpreter implementation. In particular, the "core reviewer" model in OpenStack makes substantially more effective use of core developer time than our core committer model - if I say a change looks good, it merges cleanly and passes the tests, why do I need to do the last step manually? (While I don't work on OpenStack, I work on QA tools for Red Hat. I'm considering deploying Zuul in particular, since it's at the heart of being able to adopt a core reviewer model). The other part is that I've suggested we invite the PSF's Outreach & Education committee to the summit. There are some things we're currently trying to run entirely from within the existing core dev team (like maintenance of the tutorial and the howto guides) where that may not be the most sensible model. Forwarded to the committers list since there's no reason for these notions to be secret, but please remember they're just that: notions. Turning them into reality would require a lot of work, and we'd need to understand how that was going to happen. (Given point one above, we probably want some of the PSF infrastructure team there as well) Regards, Nick. ---------- Forwarded message ---------- From: "Nick Coghlan" <ncoghlan(a)gmail.com> Date: 13 Jan 2014 01:25 Subject: Re: Two new topics for the language summit To: "Michael Foord" <fuzzyman(a)voidspace.org.uk> Cc: On a related note - perhaps it would make sense to invite the PSF Outreach & Education committee? I'd like to start letting the core team move to a model where we still ensure the reference docs are up to date, but start handing over more responsibility for the tutorials and howto guides to folks that are more focused on education (there will be some overlap, of course, since some core devs are professional trainers and others may *like* writing introductory guides). I'd also like us to consider a more consistent structure like the logging module now uses (reference, beginner how to guide, advanced how to guide, cookbook), but there's no way that is feasible in a context where the core developers are still writing most of the docs. Unrelated to the above, note that I'm also happy to give an update on the state of packaging changes. Guido may like to hear what I'm doing with that authority he delegated to me :) Cheers, Nick. On 12 Jan 2014 23:47, "Nick Coghlan" <ncoghlan(a)gmail.com> wrote: > Docs maintenance and encouraging tech writers to get involved in updating > docs.python.org > > Possible infrastructure updates to improve the core development workflows. > > Idea 1: deploy RhodeCode to manage hg.python.org (adds pull request > support, for example, and makes it easy to create forks and share access > with non core devs) > > Idea 2: finally automate NEWS updates to avoid spurious conflicts > > Idea 3: Integrating Zuul (OpenStack merge gating system) with Reitveld, > RoundUp and BuildBot with the aim of allowing merge gating with our > existing tools, making it much, much simpler to get trivial changes and > docs fixes merged (patch review = last manual intervention. From there, if > the test suite passes on the stable buildbots after merging with the > relevant branch, it lands automatically) > > Cheers, > Nick. >

3 7

clinic churn after beta2
by Eli Bendersky 13 Jan '14

13 Jan '14

Hello, Does it really make sense to introduce large amounts of code churn after the release of 3.4 beta2? It started innocently enough, but now it seems that the whole implementation is being reconsidered (Antoine's email to pydev). This doesn't look like something we should be doing so late in the release process. Are we really that much in need of convert-to-clinic *now*? Eli

16 28

Adding a (small) feature to 3.4 for Argument Clinic: inspect.Signature supporting simple named constants for default values
by Larry Hastings 07 Jan '14

07 Jan '14

Serhiy Storchaka ran into a ticklish problem with Argument Clinic and inspect.Signature information for builtins. Consider pattern_match() in Modules/_sre.c. This implements the match method on a pattern object; in other words, re.compile().match(). The third parameter, endpos, defaults to PY_SSIZE_T_MAX in C. What should inspect.Signature() report as the default value for endpos? And how should it get that value? Before you answer, consider how inspect.Signature works for builtins. Argument Clinic hides a signature for the function as the first line of the docstring; the initialization of the code object strips that off and puts it in a separate member called __text_signature__. inspect.Signature pulls that out string and passes it in to ast.parse, then walks the tree it gets back, pulls out the arguments and their default values and goes on from there. We can't turn PY_SSIZE_T_MAX into an integer at Argument Clinic preprocessing time, because this could be done on a completely different architecture than the computer where Python is running. We can't stuff it in at compile time because the macro could devolve into an arbitrary expression (with | or + or something) so while that might work here that's not a general solution. We can't do it at runtime becuase the docstring is a static string. The best solution seems to be: allow simple symbolic constants as default values. For example, for endpos we'd use sys.maxsize. The code in inspect.Signature would have to support getting an Attribute node, and look up the first field ("sys" in this case) in sys.modules. You could then specify PY_SSIZE_T_MAX as the default for generated C code, and life would be a dream. I've posted a prototype patch on the tracker: http://bugs.python.org/issue20144 It need tests and such but I think the basic technology is fine. The thing is, I feel like this is borderline between bug fix and new feature. But without adding this, we would make a lot of the Argument Clinic conversions pretty messy. So I want to check it in. I just don't want to piss everybody off in the process. Can you guys live with this? /arry p.s. For what it's worth, the documentation for match() dodges this problem by outright lying. It claims that the prototype for the function is: match(string[, pos[, endpos]]) which is a lie. pattern_match() parses its arguments by calling PyArg_ParseTupleAndKeywords() with a format string of "O|nn". Which means, for example, you could call: match("abc", endpos=5) The documentation suggests this is invalid but it works fine. So my feeling is, this is a legitimate problem, and those who came before me swept it under the rug.

6 6

PyCon Language Summit: Wednesday 9th April
by Michael Foord 07 Jan '14

07 Jan '14

Hello all, As with previous years we will be having a Language Summit at PyCon North America, in Montreal. The summit will be on Wednesday 9th April and running from approximately 10am to 4pm. As Python committers you're invited, but please respond if you're attending so I can track numbers. When we have specific venue details I will email them to all attendees. I will also be inviting "core members" of other implementations and prominent Python projects. The topic of conversation will largely be "floor led" with a focus on plans for Python 3.5, but we will endeavour to have updates from members of the alternative implementations of Python and important topics like tulip, PyPI, packaging and so on. If you have topics you would like to see discussed please let me know. We may have some other short presentations, but they will be time limited (and the time limit enforced!). Attending the Summit is free. You are responsible for your travel and hotel costs. If you wish to attend PyCon, you must still register and pay for PyCon. Note that you don't have to stay for PyCon if you're only interested in the Language Summit. Regards, Michael Foord Coordinator, Python Language Summit -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

15 31

3.4.0b2 release commits merged back into trunk, trunk is open for business again EOM
by Larry Hastings 06 Jan '14

06 Jan '14

//arry/

1 0

[RELEASED] Python 3.4.0b2
by Larry Hastings 06 Jan '14

06 Jan '14

On behalf of the Python development team, I'm pleased to announce the second beta release of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new "tracemalloc" module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O Python 3.4 is now in "feature freeze", meaning that no new features will be added. The final release is projected for late February 2014. To download Python 3.4.0b2 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0b2 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors)

1 0