Python-Dev June 2015

python-dev@python.org

63 participants
42 discussions

by Steve Dower

If you have an interest in linking to the Windows builds of Python 2.7 and 3.5+ using mingw, please visit http://bugs.python.org/issue24385 Unless someone can provide me with the One True Way to generate a lib that will work for everyone, I'm going to replace the lib file with instructions on how to generate it with your own tools. I've done enough guessing and need someone who actually uses mingw to step up and help out. Thanks, Steve

5 years, 10 months

Re: [Python-Dev] zipimport

by Rose Ames

On 06/03/2015 08:56 AM, Antoine Pitrou wrote: > Le 03/06/2015 14:34, Rose Ames a écrit : >> >> >> On 06/03/2015 04:59 AM, Antoine Pitrou wrote: >>> On Tue, 02 Jun 2015 21:20:10 +0000 >>> Brett Cannon <brett(a)python.org> wrote: >>>> >>>> I vaguely remember people suggesting writing the minimal zip reading code >>>> in C but I can't remember why since we have I/O access in importlib through >>>> _io and thus it's really just the pulling apart of the zip file to get at >>>> the files to import and thus should be doable in pure Python. >>> >>> You would need other modules, such as struct and zlib, right? >>> >> zlib is already required for compressed zips: >> >> https://github.com/python/cpython/blob/master/Modules/zipimport.c#L1030 > > Ah, the C code already importing the zlib module? Then I guess it's fine :-) > >> Do some companies >> zip the standard library or something? > > I don't know. If they do so, they probably exclude the zlib module in > some way. > > Regards > > Antoine. Sounds like I can just add a zipimporter to Lib/importlib/_bootstrap.py and remove zipimport.c entirely, is that right?

5 years, 10 months

Fwd: zipimport

by Rose Ames

At pycon I talked with a few people about bugs.python.org/issue19699. The consensus seemed to be that zipimport wants a lot of work, possibly a rewrite. I'll have some time to work on this over the next couple of months, but I want to be working on the right thing. Could the people who were involved in that conversation remind me of their concerns with zipimport? What exactly would the goal of a rewrite be? Thanks, Rose

5 years, 10 months

Avoiding reference leaks in heap types with custom tp_dealloc

by Petr Viktorin

Hello, The new test_importlib.extension.test_loader is currently leaking references, (issue24268). There is a simple hack to stop this, but I'm inclined to not apply quick hacks and rather dig into the root cause. (It's a test module, the refleaks are relatively harmless.) The tests are based directly on the "xxlimited" example, xxlimited.Xxo, which exhibits the same bug -- it's just not tested. It's is caused by a combination of a few factors, but I'm not sure what's a bug and what's just undocumented behavior, so I'm asking for input to put me on the right track. As reported in issue16690, heap types with a naïve custom tp_dealloc leak references to the type when instantiated. According to [0], it seems that tp_dealloc should check if it has been overridden, and if so, decref the type. This needs to be documented (regardless of the solution to the other problems), and I intend to document it. We can change xxlimited to do the check and decref, but isn't it too ugly for a module that showcases the extension module API? (xxlimited.Xxo can technically skip the check, since it doesn't allow subclasses, but that would be setting a nasty trap for anyone learning from that example.) The nice way out would be taking advantage of PEP 442: xxlimited.Xxo can ditch tp_dealloc in favor of tp_traverse and tp_finalize (the former of which it needs anyway to behave correctly). Unfortunately, tp_finalize is not available in the stable ABI (issue24345). I think it should be added; is it too late for 3.5? Another problem is that xxlimited is untested. It's only built for non-debug builds, because Py_LIMITED_API and Py_DEBUG are incompatible. Would it make sense to build and test it without Py_LIMITED_API in debug mode, instead of not building it at all? [0] http://bugs.python.org/issue15653#msg168449

5 years, 10 months

Re: [Python-Dev] cpython (2.7): Issue #24357: Change host in socket.getaddrinfo example to one that

by Serhiy Storchaka

On 02.06.15 04:58, ned.deily wrote: > https://hg.python.org/cpython/rev/30da21d2fa4f > changeset: 96458:30da21d2fa4f > branch: 2.7 > parent: 96454:5e8fa1b13516 > user: Ned Deily <nad(a)acm.org> > date: Mon Jun 01 18:45:49 2015 -0700 > summary: > Issue #24357: Change host in socket.getaddrinfo example to one that > does support IPv6 and IPv4; www.python.org currently does not. > > files: > Doc/library/socket.rst | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) > > > diff --git a/Doc/library/socket.rst b/Doc/library/socket.rst > --- a/Doc/library/socket.rst > +++ b/Doc/library/socket.rst > @@ -262,12 +262,12 @@ > method. > > The following example fetches address information for a hypothetical TCP > - connection to ``www.python.org`` on port 80 (results may differ on your > + connection to ``google.com`` on port 80 (results may differ on your > system if IPv6 isn't enabled):: example.org does support IPv6 and IPv4 too, and is not commercial name.

5 years, 10 months

RM for 3.6?

by Serhiy Storchaka

Isn't it a time to assign release manager for 3.6-3.7?

5 years, 10 months

Re: [Python-Dev] [python-committers] Ned Deily is release manager for Python 3.6

by Larry Hastings

On 06/01/2015 11:09 AM, Barry Warsaw wrote: > Please welcome Ned Deily as RM for Python 3.6. > > https://www.python.org/dev/peps/pep-0494/ We're in good hands. For two versions now Benjamin and Ned have been quietly cleaning up my mistakes after (nearly) every release. My guess is, Ned won't bother making the mistakes in the first place! //arry/

5 years, 10 months

Python 3 migration status update across some key subcommunities (was Re: 2.7 is here until 2020, please don't call it a waste.)

by Nick Coghlan

On 31 May 2015 at 19:07, Ludovic Gasc <gmludo(a)gmail.com> wrote: > About Python 3 migration, I think that one of our best control stick is > newcomers, and by extension, Python trainers/teachers. > If newcomers learn first Python 3, when they will start to work > professionally, they should help to rationalize the Python 3 migration > inside existing dev teams, especially because they don't have an interest > conflict based on the fact that they haven't written plenty of code with > Python 2. > 2020 is around the corner, 5 years shouldn't be enough to change the > community mind, I don't know. The education community started switching a while back - if you watch Carrie-Anne Philbin's PyCon UK 2014 keynote, one of her requests for the broader Python community was for everyone else to just catch up already in order to reduce student's confusion (she phrased it more politely than that, though). Educators need to tweak examples and exercises to account for a version switch, but that's substantially easier than migrating hundreds of thousands or even millions of lines of production code. And yes, if you learn Python 3 first, subsequently encountering Python 2's quirks and cruft is likely to encourage folks that know both versions of the language to start advocating for a version upgrade :) After accounting for the "Wow, the existing Python 2 install base is even larger than we realised" factour, the migration is actually in a pretty good place overall these days. The "enterprise" crowd really are likely to be the only ones that might need the full remaining 5 years of migration time (and they may potentially have even more time, if they're relying on a commercial redistributor). Web frameworks have allowed Python 3 development for a while now, and with Django switching their tutorial to Python 3 by default, Django downloads via pip show one of the highest proportions of Python 3 adoption on PyPI. www.python.org itself is now a production Python 3 Django web service, and the next generation of pypi.python.org will be a Pyramid application that's also running on Python 3. The dedicated async/await syntax in 3.5 represents a decent carrot to encourage migration for anyone currently using yield (or yield from) based coroutines, since the distinct syntax not only allows for easier local reasoning about whether something is an iterator or a coroutine, it also provides a much improved user experience for asynchronous iterators and context managers (including finally handling the "asynchronous database transaction as a context manager" case, which previous versions of Python couldn't really do at all). The matrix multiplication operator is similarly a major improvement for the science and data analysis part of the Python community. In terms of reducing *barriers* to adoption, after inviting them to speak at the 2014 language summit, we spent a fair bit of time with the Twisted and Mercurial folks over the past year or so working through "What's still missing from Python 3 for your use cases?", as Python 3.4 was still missing some features for binary data manipulation where we'd been a bit too ruthless in pruning back the binary side of things when deciding what counted as text-only features, and what was applicable to binary data as well. So 3.5 brings back binary interpolation, adds a hex() method to bytes, and adds binary data support directly to a couple of standard library modules (tempfile, difflib). If I understand the situation correctly, the work Guido et al have been doing on PEP 484 and type hinting standardisation is also aimed at reducing barriers to Python 3 adoption, by making it possible to develop better migration tools that are more semantically aware than the existing syntax focused tools. The type hinting actually acts as a carrot as well, since it's a feature that mainly shows its value when attempting to scale a *team* to larger sizes (as it lets you delegate more of the code review process to an automated tool, letting the human reviewers spend more time focusing on higher level semantic concerns). Finally, both Debian/Ubuntu and Fedora are well advanced in their efforts to replace Python 2 with Python 3 in their respective default images (but keeping Py2 available in their package repos). That work is close to finished now (myself, Slavek Kabrda, Barry Warsaw, and Matthias Klose had some good opportunities to discuss that at PyCon), although there are still some significant rough edges to figure out (such as coming up with a coherent cross-platform story for what we're going to do with the Python symlink), as well as a few more key projects to either migrate entirely, or at least finish porting to the source compatible subset of Python 2 & 3 (e.g. Samba). Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

5 years, 10 months

Windows new 3.5 installer: Command line uninstall

by Paul Moore

I'm trying to script a command line uninstall of Python 3.5. The new installer has a nice well-documented command line interface, but there's nothing much about how to uninstall. Looking at the installed products, I see >get-wmiobject Win32_Product -filter 'name like "Python 3.5.0b2%"' | select Name Name ---- Python 3.5.0b2 pip Bootstrap (64-bit) Python 3.5.0b2 Development Libraries (64-bit) Python 3.5.0b2 C Runtime (64-bit) Python 3.5.0b2 Tcl/Tk Support (64-bit) Python 3.5.0b2 Standard Library (64-bit) Python 3.5.0b2 Executables (64-bit) Python 3.5.0b2 Core Interpreter (64-bit) Python 3.5.0b2 Launcher (32-bit) Python 3.5.0b2 Documentation (64-bit) Python 3.5.0b2 Utility Scripts (64-bit) Python 3.5.0b2 Test Suite (64-bit) Normally I'd be able to call the Uninstall method on the installed product, but here, I'm not sure which of the above I'd call "Uninstall" on (there's only one "Programs and Features" entry for 3.5, and I can't tell which of these is equivalent to it - or if I need to uninstall each in turn, I don't know what order they need to be done in). Specifically (get-wmiobject -query 'select * from Win32_Product where name = "Python 2.7.8 (64-bit)"').Uninstall() is an automated, command line silent uninstall of Python 2.7.8. What (if anything) would be the equivalent for 3.5.0b2? Paul

5 years, 10 months

Re: [Python-Dev] [Python-checkins] peps: We have a 3.6 release PEP.

by Yury Selivanov

It looks like we now have two 3.6 release PEPs: 494 & 495 Yury On 2015-06-01 1:59 PM, barry.warsaw wrote: > https://hg.python.org/peps/rev/a50d51e8c748 > changeset: 5888:a50d51e8c748 > user: Barry Warsaw <barry(a)python.org> > date: Mon Jun 01 13:59:32 2015 -0400 > summary: > We have a 3.6 release PEP. > > files: > pep-0495.txt | 66 ++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 66 insertions(+), 0 deletions(-) > > > diff --git a/pep-0495.txt b/pep-0495.txt > new file mode 100644 > --- /dev/null > +++ b/pep-0495.txt > @@ -0,0 +1,66 @@ > +PEP: 495 > +Title: Python 3.6 Release Schedule > +Version: $Revision$ > +Last-Modified: $Date$ > +Author: Ned Deily <nad(a)acm.org> > +Status: Active > +Type: Informational > +Content-Type: text/x-rst > +Created: 30-May-2015 > +Python-Version: 3.6 > + > + > +Abstract > +======== > + > +This document describes the development and release schedule for Python 3.6. > +The schedule primarily concerns itself with PEP-sized items. > + > +.. Small features may be added up to the first beta release. Bugs may be > + fixed until the final release, which is tentatively planned for late 2016. > + > + > +Release Manager and Crew > +======================== > + > +- 3.6 Release Manager: Ned Deily > +- Windows installers: Steve Dower > +- Mac installers: Ned Deily > +- Documentation: Georg Brandl > + > + > +Release Schedule > +================ > + > +The releases: > + > +- 3.6.0 alpha 1: TBD > +- 3.6.0 beta 1: TBD > +- 3.6.0 candidate 1: TBD > +- 3.6.0 final: TBD (late 2016?) > + > +(Beta 1 is also "feature freeze"--no new features beyond this point.) > + > + > +Features for 3.6 > +================ > + > +Proposed changes for 3.6: > + > +* TBD > + > + > +Copyright > +========= > + > +This document has been placed in the public domain. > + > + > +.. > + Local Variables: > + mode: indented-text > + indent-tabs-mode: nil > + sentence-end-double-space: t > + fill-column: 70 > + coding: utf-8 > + End: > > > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > https://mail.python.org/mailman/listinfo/python-checkins

5 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev June 2015