Mailman 3 December 2016 - Python-Dev

Asking for feedback about fixing `ftplib' (issue25458)
by Ivan Pozdeev 16 Dec '16

16 Dec '16

I'm currently working on http://bugs.python.org/issue25458 . There are a few options there, and each one has drawbacks. So, I'd like to get some feedback on which way is prefereable before working towards any of them and/or other ideas should they arise. The problem and the options are summarized in http://bugs.python.org/issue25458#msg283073 and the message after that one. Apart from the options, I'd like to know if I must solve the 2nd problem (error handling), too, or it can be handled in a separate ticket. -- Regards, Ivan

1 0

Python 3.6.0rc2 coming soon, 3.6.0 final now 2016-12-23
by Ned Deily 16 Dec '16

16 Dec '16

Hi all! Today (2016-12-16) has long been our planned release date for 3.6.0 final. So far most of the feedback from users testing the preview versions of 3.6.0 has been very positive. We made it to the next-to-final milestone, the 3.6.0rc1 release candidate, 10 days ago with hopes of going directly to the final release. Alas, in the last few days at least one outstanding issue that we had hoped would not be a real-world problem has proven to be a showstopper during third-party package testing and I have been persuaded that we do need to fix it before 3.6.0 final. I take responsibility and apologize for not ensuring it was resolved earlier in the release cycle; I'll try to do better next time. Therefore, we are going to produce a second release candidate. Besides the showstopper fix (#28147), I've cherrypicked a few requested build fixes and, as promised, some last-minute documentation updates and additions. I'm also expecting to cherrypick at least one more asynchio fix before tagging and manufacturing 3.6.0rc2 sometime later today (i.e. within the next 24 hours). Assuming that is accomplished, we will be looking for quick feedback to ensure that we have addressed the problems and have not introduced any new ones. Then, assuming all goes well and no new showstoppers are found, we plan to release 3.6.0 final on Friday 2016-12-23, a week from now. Also note that there is no change in the status of the cpython repo branches. Continue to push appropriate changes to the 3.6 branch for the 3.6.1 maintenance release and to the default branch for the next feature release, 3.7.0. Should you run into a potential showstopper problem for 3.6.0, please make sure there is an open issue for it on the bug tracker marked as "release blocker", work to getting a fix pushed to the 3.6 branch for 3.6.1, and contact me ASAP to discuss potential cherrypicking. Please do the same for any necessary important documentation fixes for 3.6.0 final. As before, my goal will be to have no new changes after the release candidate. Thank you all again for your great efforts and co-operation throughout the 3.6 development cycle! We are oh-so-close to getting your work officially out there. --Ned P.S. Happy Beethoven's Birthday FYI: Here is a list of the post 3.6.0rc1 changesets that have been cherrypicked so far for 3.6.0rc2. There will likely be at least one more. (Note, the description and files list below for some changesets may be truncated.) user: Yury Selivanov <yury(a)magic.io> date: Wed Dec 07 16:19:56 2016 -0800 files: Doc/whatsnew/3.6.rst description: Issue #28635: Drop the note that whatsnew is incomplete user: Ned Deily <nad(a)python.org> date: Wed Dec 07 23:37:12 2016 -0500 files: Doc/tools/templates/indexsidebar.html description: Issue #28900: Update documentation sidebar for 3.6.0rc. user: Benjamin Peterson <benjamin(a)python.org> date: Wed Dec 07 23:54:28 2016 -0800 files: Include/pyport.h description: guard HAVE_LONG_LONG definition to prevent redefinition (#28898) [prevent gdb build errors with 3.6.0] user: Steve Dower <steve.dower(a)microsoft.com> date: Wed Dec 07 13:02:27 2016 -0800 files: Doc/library/importlib.rst Doc/using/windows.rst Doc/whatsnew/3.6.rst Misc/NEW description: Issue #28896: Deprecate WindowsRegistryFinder user: Steve Dower <steve.dower(a)microsoft.com> date: Sun Dec 11 14:48:32 2016 -0800 files: Tools/msi/distutils.command.__init__.py Tools/msi/distutils.command.bdist_win description: Issue #28783: Replaces bdist_wininst in nuget packages with stub user: Yury Selivanov <yury(a)magic.io> date: Mon Dec 12 16:44:58 2016 -0500 files: Doc/library/asyncio-protocol.rst Doc/whatsnew/3.6.rst description: Issue #28089: Document TCP_NODELAY in asyncio user: Victor Stinner <victor.stinner(a)gmail.com> date: Thu Dec 15 16:20:53 2016 +0100 files: Doc/whatsnew/3.6.rst description: Issue #28979: Fix What's New in Python 3.6, dict user: Victor Stinner <victor.stinner(a)gmail.com> date: Thu Dec 15 17:21:23 2016 +0100 files: Lib/test/test_dict.py Misc/NEWS Modules/_testcapimodule.c Objects/dictobject. description: Issue #28147: Fix a memory leak in split-table dictionaries: setattr() must not convert combined table into split table. Patch written by INADA Naoki. user: Yury Selivanov <yury(a)magic.io> date: Thu Dec 15 17:36:05 2016 -0500 files: Doc/glossary.rst Doc/library/asyncio-eventloop.rst Doc/library/inspect.rst [...] description: Issue #28091: Document PEP 525 & PEP 530. user: Yury Selivanov <yury(a)magic.io> date: Thu Dec 15 17:56:43 2016 -0500 files: Doc/whatsnew/3.6.rst description: Issue #28635: asyncio-related fixes and additions. [docs only] user: Yury Selivanov <yury(a)magic.io> date: Thu Dec 15 18:58:19 2016 -0500 files: Doc/library/asyncio.rst description: docs: asyncio is no longer provisional user: Ned Deily <nad(a)python.org> date: Thu Dec 15 23:20:48 2016 -0500 files: Misc/NEWS description: Issue #28898: add Misc/NEWS entry -- Ned Deily nad(a)python.org -- []

2 1

Removing memoryview object patch from Python 2.7
by Sesha Narayanan Subbiah 14 Dec '16

14 Dec '16

Hello I have some implementation that currently uses python 2.6.4, which I m trying to upgrade to Python 2.7.6. After upgrade, I get the following error: "expected string or Unicode object, memoryview found" On checking further, I could find that memory view object has been back ported to python 2.7 using this patch: https://bugs.python.org/issue2396 I would like to know if it is safe to revert this patch alone from Python 2.7.6, or do we know if there are any other dependencies? Thanks Regards Sesha

4 6

Implementation difference of audioop.lin2lin in Python2 and Python3
by KH Luke Kim 14 Dec '16

14 Dec '16

Hello, recently there had been some issues in audioread and librosa that 3-byte samples can be loaded in Python 3 but 2. The documentation says that the audioop.lin2lin function in Python 3 support 1-, 2-, 3-, 4-byte samples but only 1-, 2-, 4-byte samples in Python 2. I wonder why 3-byte support is not implemented in Python 2. If there is any previous thread or history regarding this issue, could you refer it to me? Thanks in advance, Luke

5 6

3.6.0: OpenSSL 1.1.0c is not supported
by Christian Heimes 14 Dec '16

14 Dec '16

Hi Ned, please add a reminder to the release docs that Python 3.6.0 is not compatible with OpenSSL 1.1.0c, https://bugs.python.org/issue28689. 1.1.0 to 1.1.0b work fine. 1.1.0d will be compatible, too. Regards, Christian

1 0

Making sure dictionary adds/deletes during iteration always raise exception
by Max Moroz 13 Dec '16

13 Dec '16

Would it be worth ensuring that an exception is ALWAYS raised if a key is added to or deleted from a dictionary during iteration? Currently, dict.__iter__ only raises "RuntimeError" when "dictionary changed size during iteration". I managed to add 1 key and delete 1 key from the dictionary in the same iteration of the loop (the code was in a callback function invoked in the loop) - of course without any exception. (I hope I'm right in assuming that adding and deleting entries in the loop is unsafe whether or not number of adds equals number of deletes.) I suspect the cost of a more comprehensive error reporting is not worth the benefit, but I thought I'd ask anyway. Here's a pure python prototype that would always raise on unsafe add/delete. The main cost is the addition of a counter keeping track of the number of modifications made to the dictionary (the work done inside __iter__ is probably not adding any runtime cost because it replaces roughly equivalent code that currently verifies that the length didn't change): class SafeKeyIter: def __init__(self, iterator, container): self.iterator = iterator self.container = container try: self.n_modifications = container.n_modifications except AttributeError: raise RuntimeError('container does not support safe iteration') def __next__(self): if self.n_modifications != self.container.n_modifications: raise RuntimeError('container entries added or deleted during iteration') return next(self.iterator) class SafeView: def __init__(self, view, container): self.view = view self.container = container def __iter__(self): return SafeKeyIter(self.view.__iter__(), self.container) class SafeDict(dict): def __init__(self, *args, **kwargs): self.n_modifications = 0 super().__init__(*args, **kwargs) def __setitem__(self, key, value): if key not in self: self.n_modifications += 1 super().__setitem__(key, value) def __delitem__(self, key): self.n_modifications += 1 super().__delitem__(key) def __iter__(self): return SafeKeyIter(super().__iter__(), self) def keys(self): return SafeView(super().keys(), self) def values(self): return SafeView(super().values(), self) def items(self): return SafeView(super().items(), self) # this raises RuntimeError: d = SafeDict({1: 2}) for k in d: d[k * 100] = 100 del d[k] # while it wouldn't raise for a built-in dict d = {1: 2} for k in d: d[k * 100] = 100 del d[k] There was a brief discussion on SO after I asked a question about this behavior, and later answered it: http://stackoverflow.com/questions/40955786/why-modifying-dict-during-itera…. Max

9 11

Removing memoryview object patch from Python 2.7
by Sesha Narayanan Subbiah 13 Dec '16

13 Dec '16

Hello I have some implementation that currently uses python 2.6.4, which I m trying to upgrade to Python 2.7.6. After upgrade, I get the following error: "expected string or Unicode object, memoryview found" On checking further, I could find that memory view object has been back ported to python 2.7 using this patch: https://bugs.python.org/issue2396 I would like to know if it is safe to revert this patch alone from Python 2.7.6, or do we know if there are any other dependencies? Thanks Regards Sesha

1 0

Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub
by Stephen J. Turnbull 13 Dec '16

13 Dec '16

Wes Turner writes: > [Continuing to play devil's advocate for the sake of clarification] I will answer briefly here, but for further discussion, I will go to personal mail. (I don't recommend that, I'm really at the limit of things I ever knew well. ;-) > On Mon, Dec 12, 2016 at 2:40 AM, Stephen J. Turnbull < > turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > > > The legal theory is that the name "Python" is reserved so that > > users can know that Python-Dev's strict (or not so, YMMV) QA > > policies have been applied > > These are QA'd: I should have put "QA" in scare quotes. It's not about what actually happens in Python, it's the legal theory that as a trademark of the PSF it carries the PSF's "reputational capital", whatever that may be. > There's really a "ship of theseus" argument: it is defacto standard De jure in the U.S. (and most jurisdictions I know about) doesn't much care about "de facto" if it gets to court.[1] > How extensive those patches are is likely irrelevant to a trademark > dispute (of which there is none here). Ah, but there *is* a trademark dispute that is relevant here: a future one. For other practical considerations, Nick's explanation of distro (or Red Hat or Fedora?) considerations was helpful to me (as I said, it's been a decade or so since I looked closely at this stuff). Steve Footnotes: [1] Japan is interesting: it rarely gets to court, so bureaucrats can effectively sanction illegal activity if it's considered to be socially beneficial. A recent example I heard about is community gardens, which violate some nitpicky agricultural laws, but help preserve greenery and feed the impecunious elderly in large cities. There are less savory examples, too. :-(

1 0

Removing memoryview object patch from Python 2.7
by Sesha Narayanan Subbiah 13 Dec '16

13 Dec '16

Hello I have some implementation that currently uses python 2.6.4, which I m trying to upgrade to Python 2.7.6. After upgrade, I get the following error: "expected string or Unicode object, memoryview found" On checking further, I could find that memory view object has been back ported to python 2.7 using this patch: https://bugs.python.org/issue2396 I would like to know if it is safe to revert this patch alone from Python 2.7.6, or do we know if there are any other dependencies? Thanks Sesha

1 1

Someons's put a "Python 2.8" on GitHub
by Larry Hastings 12 Dec '16

12 Dec '16

"Python 2.8 is a backwards-compatible Python interpreter with new features from Python 3.x. It was produced by forking Python 2.7.12 and backporting some of the new syntax, builtins, and libraries from Python 3. Python code and C-extensions targeting Python 2.7 or below are expected to run unmodified on Python 2.8 and produce the same output. But with Python 2.8, that code can now use some of the new features from Python 3.x." Backported features: * Function annotations * Keyword-only arguments * async / await * no-argument super() * new metaclass syntax * yield from * typing module * inspect.signature() * matrix multiplication operator * fine-grained reworking of OSError * underscores in numeric literals * concurrent.futures * types.MappingProxyType * selectors module https://github.com/naftaliharris/python2.8 Huh, //arry/

18 34