Mailman 3 January 2018 - Python-Dev

3.7.0b1 status
by Ned Deily 31 Jan '18

31 Jan '18

Just a quick update: thanks to all of you who worked long hours to get features completed and merged in for the 3.7 feature code cutoff yesterday. We release elves have been busy behind the scenes baking goodies. So far everything looks OK. But we're taking a little longer than usual: this is, in many ways, the most complicated milestone of the release cycle, since it involves creating a new release branch and other munging, and this is the first time we are doing this since we moved to our new git-based workflow last year and we want to get it right. We will have everything done and announced in not more than 24 hours from now. If you wish, feel free to merge new commits into the master branch for release in 3.8, with the understanding that any also destined for 3.7.0 will need to be cherrypicked after the 3.7 branch is available. Other branches (3.6, 2.7) are unaffected. Thanks for your patience! -- Ned Deily nad(a)python.org -- []

1 0

Python 2.7, long double vs allocator alignment, GCC 8 on x86-64
by Florian Weimer 31 Jan '18

31 Jan '18

I hope this is the right list for this kind of question. We recently tried to build Python 2.6 with GCC 8, and ran into this issue: <https://bugzilla.redhat.com/show_bug.cgi?id=1540316> Also quoting for context: | PyInstance_NewRaw contains this code: | | inst = PyObject_GC_New(PyInstanceObject, &PyInstance_Type); | if (inst == NULL) { | Py_DECREF(dict); | return NULL; | } | inst->in_weakreflist = NULL; | Py_INCREF(klass); | inst->in_class = (PyClassObject *)klass; | inst->in_dict = dict; | _PyObject_GC_TRACK(inst); | | _PyObject_GC_TRACK expands to: | | #define _PyObject_GC_TRACK(o) do { \ | PyGC_Head *g = _Py_AS_GC(o); \ | if (g->gc.gc_refs != _PyGC_REFS_UNTRACKED) \ | Py_FatalError("GC object already tracked"); \ | … | | Via: | | #define _Py_AS_GC(o) ((PyGC_Head *)(o)-1) | | We get to this: | | /* GC information is stored BEFORE the object structure. */ | typedef union _gc_head { | struct { | union _gc_head *gc_next; | union _gc_head *gc_prev; | Py_ssize_t gc_refs; | } gc; | long double dummy; /* force worst-case alignment */ | } PyGC_Head; | | PyGC_Head has 16-byte alignment. The net result is that | | _PyObject_GC_TRACK(inst); | | promises to the compiler that inst is properly aligned for the | PyGC_Head type, but it is not: PyObject_GC_New returns a pointer which | is only 8-byte-aligned. | | Objects/obmalloc.c contains this: | | /* | * Alignment of addresses returned to the user. 8-bytes alignment works | * on most current architectures (with 32-bit or 64-bit address busses). | * The alignment value is also used for grouping small requests in size | * classes spaced ALIGNMENT bytes apart. | * | * You shouldn't change this unless you know what you are doing. | */ | #define ALIGNMENT 8 /* must be 2^N */ | #define ALIGNMENT_SHIFT 3 | #define ALIGNMENT_MASK (ALIGNMENT - 1) | | So either the allocator alignment needs to be increased, or the | PyGC_Head alignment needs to be decreased. Is this a known issue? As far as I can see, it has not been fixed on the 2.7 branch. (Store merging is a relatively new GCC feature. Among other things, this means that on x86-64, for sufficiently aligned pointers, vector instructions are used to update multiple struct fields at once. These vector instructions can trigger alignment traps, similar to what happens on some other architectures for scalars.)

4 5

Friendly reminder: be kind to one another
by Brett Cannon 31 Jan '18

31 Jan '18

Over the last 3 days I have had two situations come up where I was asked for my opinion in regards to possible CoC violations. I just wanted to take this opportunity to remind everyone that open source does not work if we are not open, considerate, and respectful to one another (which also happens to be the PSF CoC that we are all expected to follow when working on Python). When we stop being kind to each other is when open source falls apart because it drives people away, and for a project that is driven by volunteers like Python that will be what ends this project (not to say people should be rude to corporate open source projects, but they can simply choose to switch to a core dump approach of open source). I gave a talk at PyCascades this past week on setting expectations for open source participation: https://youtu.be/HiWfqMbJ3_8?t=7m24s . I had at least one person who was upset about no one getting to their pull request quickly come up to me afterwards and apologize for ever feeling that way after watching my talk, so do please watch it if you have ever felt angry at an open source maintainer or contributor to help keep things in perspective. I also wanted to say that I think core developers should work extra hard to be kind as we help set the tone for this project which can leak into the broader community. People with commit privileges are not beyond rebuke and so people should never feel they are not justified speaking up when they feel a core developer has been rude to them. Anyway, the key point is to remember is that people are what make this project and community work, so please make sure that you do what you can to keep people wanting to participate.

5 6

Is static typing still optional?
by Raymond Hettinger 29 Jan '18

29 Jan '18

The make_dataclass() factory function in the dataclasses module currently requires type declarations. It would be nice if the type declarations were optional. With typing (currently works): Point = NamedTuple('Point', [('x', float), ('y', float), ('z', float)]) Point = make_dataclass('Point', [('x', float), ('y', float), ('z', float)]) Without typing (only the first currently works): Point = namedtuple('Point', ['x', 'y', 'z']) # underlying store is a tuple Point = make_dataclass('Point', ['x', 'y', 'z']) # underlying store is an instance dict This proposal would make it easy to cleanly switch between the immutable tuple-based container and the instancedict-based optionally-frozen container. The proposal would make it possible for instructors to teach dataclasses without having to teach typing as a prerequisite. And, it would make dataclasses usable for projects that have elected not to use static typing. Raymond

26 83

cls for metaclass?
by Pim Schellart 29 Jan '18

29 Jan '18

Dear Python developers, PEP 8 says: "Always use self for the first argument to instance methods. Always use cls for the first argument to class methods.” But what about metaclasses? PEP 3115 seems to suggest `cls`, and so do many Python books, however tools such as flake8 don’t seem to like it. Is there a consensus opinion, and should PEP 8 be updated? Kind regards, Pim Schellart

3 2

Sad buildbots
by Victor Stinner 29 Jan '18

29 Jan '18

Hi, It seems like the feature freeze is close: while I usually get 2 emails/day at maximum on buildbot-status, I got 14 emails during the weekend: https://mail.python.org/mm3/archives/list/buildbot-status@python.org/ (are all buildbots red? :-p) I will not have the bandwidth to analyze all buildbot failures. Can someone help to investigate all these funny new regressions? http://buildbot.python.org/all/#/builders I would feel safer to cut a release if most buildbots are green again. Victor

2 2

Guido's Python 1.0.0 Announcement from 27 Jan 1994
by Senthil Kumaran 28 Jan '18

28 Jan '18

Someone in HackerNews shared the Guido's Python 1.0.0 announcement from 27 Jan 1994. That is, on this day, 20 years ago. https://groups.google.com/forum/?hl=en#!original/comp.lang.misc/_QUzdEGFwCo… It is very entertaining to read. * Guido was the release manager, which is now taken up by other core-dev volunteers. * Announcement highlighted *readable* syntax. * The announcement takes a dig at Perl and Bash. While Bourne shell is still very relevant and might continue for a long time, we recognize the difference is use cases for Bash and Python. * Documentation was LaTeX and PostScript. * Error-free builds on SGI IRIX 4 and 5, Sun SunOS 4 and Solaris 2, HP-UX, DEC Ultrix and OSF/1, IBM AIX, and SCO ODT 3.0. :-) We no longer have them. * You used WWW viewer to view the documentation and got the files via FTP. Fun times! Cheers to Guido and everyone contributing to Python. Thanks, Senthil

11 14

Welcome the 3.8 and 3.9 Release Manager - Łukasz Langa!
by Barry Warsaw 27 Jan '18

27 Jan '18

As Ned just announced, Python 3.7 is very soon to enter beta 1 and thus feature freeze. I think we can all give Ned a huge round of applause for his amazing work as Release Manager for Python 3.6 and 3.7. Let’s also give him all the support he needs to make 3.7 the best version yet. As is tradition, Python release managers serve for two consecutive releases, and so with the 3.7 release branch about to be made, it’s time to announce our release manager for Python 3.8 and 3.9. By unanimous and enthusiastic consent from the Python Secret Underground (PSU, which emphatically does not exist), the Python Cabal of Former and Current Release Managers, Cardinal Ximénez, and of course the BDFL, please welcome your next release manager… Łukasz Langa! And also, happy 24th anniversary to Guido’s Python 1.0.0 announcement[1]. It’s been a fun and incredible ride, and I firmly believe that Python’s best days are ahead of us. Enjoy, -Barry [1] https://groups.google.com/forum/?hl=en#!original/comp.lang.misc/_QUzdEGFwCo…

6 7

IMPORTANT: 3.7.0b1 and feature code cutoff 2018-01-29
by Ned Deily 27 Jan '18

27 Jan '18

Happy mid-winter (northern hemisphere) or -summer (southern)! The time has come to finish feature development for Python 3.7. As previously announced, this coming Monday marks the end of the alpha phase of the release cycle and the beginning of the beta phase. Up through the alpha phase, there has been unrestricted feature development phase; that ends as of beta 1. All feature code for 3.7.0 must be checked in by the b1 cutoff on end-of-day Monday (unless you have contacted me and we have agreed on an extension). As was done during the 3.6 release cycle, we will create the 3.7 branch at b1 time. During the beta phase, the emphasis is on fixes for new features, fixes for all categories of bugs and regressions, and documentation fixes/updates. I will send out specific information for core committers next week after the creation of the b1 tag and the 3.7 branch. Beta releases are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage maintainers of third-party Python projects to test with 3.7 during the beta phase and report issues found to bugs.python.org as soon as possible. While the release will be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase. Our goal is have no changes after rc1. To achieve that, it will be extremely important to get as much exposure for 3.7 as possible during the beta phase. Also, during the 3.6.0 release cycle, the question of ABI stability during the final (e.g. beta and release candidate) phases of the release came up. Last-minute changes put a burden on our and our downstream users testing efforts and adds risk to the release. Therefore, as was proposed then, we will strive to have no ABI changes after beta 3. More details forthcoming. To recap: 2018-01-29 ~23:59 Anywhere on Earth (UTC-12:00): code snapshot for 3.7.0 beta 1 (feature code freeze, no new features) 2019-01-30: 3.7 branch opens for 3.7.0 feature development continues on master branch, now for 3.8.0 2018-01-30 to 2018-05-21: 3.7.0 beta phase (bug, regression, and doc fixes, no new features) 2018-03-26: 3.7.0 beta 3 (3.7.0 ABI freeze) 2018-05-21: 3.7.0 release candidate 1 (3.7.0 code freeze) 2018-06-15: 3.7.0 release (3.7.0rc1 plus, if necessary, any dire emergency fixes) ~2019-12 tentative (3.7.0 release + 18 months): 3.8.0 release (details TBD) Thank you all for your great efforts so far on 3.7; it should be another great release! --Ned https://www.python.org/dev/peps/pep-0537/ -- Ned Deily nad(a)python.org -- []

1 0

New Contributor looking for help
by Jay Yin 26 Jan '18

26 Jan '18

Hello everyone, I've been trying to build the master branch on Ubuntu 16.04 and it currently fails 2 test, I was wondering if this was normal or if I'm missing dependencies, I also tried apt-get build-dev python3.6 and python3.7 to no avail, the build requirements install worked for python3.5 but I suspect 3.7 has different dependencies but I can't find where the documentation for the requirements are. 2 tests failed: test_dtrace test_subprocess running test_dtrace as verbose gave https://pastebin.com/ZGzzxwjk [https://pastebin.com/i/facebook.png]<https://pastebin.com/ZGzzxwjk> [Bash] FAILED (errors=4) test test_dtrace failed 1 test failed: test_dtrace R - Pastebin.com<https://pastebin.com/ZGzzxwjk> pastebin.com and running test_subprocess gives https://pastebin.com/DNjPzpgp [https://pastebin.com/i/facebook.png]<https://pastebin.com/DNjPzpgp> [Bash] ----------------------------------------------- Modules/Setup.dist is newer tha - Pastebin.com<https://pastebin.com/DNjPzpgp> pastebin.com _______________________________________________________________________________________________________________________ [1488460367159_signiture.jpg]

2 1