From benjamin at python.org  Thu Dec  1 01:58:01 2016
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 30 Nov 2016 22:58:01 -0800
Subject: [Python-Dev] Python 2.7.13 release dates
In-Reply-To: <20161130191940.4f7fc235@fsol>
References: <1480316791.2913744.800826761.72EEE93A@webmail.messagingengine.com>
 <o1htg3$2mg$1@blaine.gmane.org>
 <C0690135-3498-4CED-9D74-6E97CE1E72C3@gmail.com>
 <1480406500.3889434.802141153.0E325DD2@webmail.messagingengine.com>
 <E1cBjAA-0003t7-Jo@se2-syd.hostedmail.net.au>
 <41b7f3d0-952a-87a2-6dce-62cba199d46d@ubuntu.com>
 <1480489634.4189899.803413225.41835A11@webmail.messagingengine.com>
 <20161130191940.4f7fc235@fsol>
Message-ID: <1480575481.1645089.804693513.1A014ADE@webmail.messagingengine.com>



On Wed, Nov 30, 2016, at 10:19, Antoine Pitrou wrote:
> On Tue, 29 Nov 2016 23:07:14 -0800
> Benjamin Peterson <benjamin at python.org> wrote:
> > Okay, now that we're heard from the other side, and I lacking a concrete
> > reason to delay the release, I'm putting 2.7.13 back at the original
> > dates.
> 
> Serhiy may be thinking about https://bugs.python.org/issue28427

But that isn't new, right?

From solipsis at pitrou.net  Thu Dec  1 05:55:23 2016
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 1 Dec 2016 11:55:23 +0100
Subject: [Python-Dev] Python 2.7.13 release dates
In-Reply-To: <1480575481.1645089.804693513.1A014ADE@webmail.messagingengine.com>
References: <1480316791.2913744.800826761.72EEE93A@webmail.messagingengine.com>
 <o1htg3$2mg$1@blaine.gmane.org>
 <C0690135-3498-4CED-9D74-6E97CE1E72C3@gmail.com>
 <1480406500.3889434.802141153.0E325DD2@webmail.messagingengine.com>
 <E1cBjAA-0003t7-Jo@se2-syd.hostedmail.net.au>
 <41b7f3d0-952a-87a2-6dce-62cba199d46d@ubuntu.com>
 <1480489634.4189899.803413225.41835A11@webmail.messagingengine.com>
 <20161130191940.4f7fc235@fsol>
 <1480575481.1645089.804693513.1A014ADE@webmail.messagingengine.com>
Message-ID: <20161201115523.0e12ce1e@fsol>

On Wed, 30 Nov 2016 22:58:01 -0800
Benjamin Peterson <benjamin at python.org> wrote:

> On Wed, Nov 30, 2016, at 10:19, Antoine Pitrou wrote:
> > On Tue, 29 Nov 2016 23:07:14 -0800
> > Benjamin Peterson <benjamin at python.org> wrote:  
> > > Okay, now that we're heard from the other side, and I lacking a concrete
> > > reason to delay the release, I'm putting 2.7.13 back at the original
> > > dates.  
> > 
> > Serhiy may be thinking about https://bugs.python.org/issue28427  
> 
> But that isn't new, right?

Definitely not :-)

From status at bugs.python.org  Fri Dec  2 12:09:06 2016
From: status at bugs.python.org (Python tracker)
Date: Fri,  2 Dec 2016 18:09:06 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20161202170906.0EB6F5620E@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2016-11-25 - 2016-12-02)
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    5613 (+25)
  closed 35002 (+31)
  total  40615 (+56)

Open issues with patches: 2435 


Issues opened (44)
==================

#5225: OS X "Update Shell Profile" may not update $PATH if run more t
http://bugs.python.org/issue5225  reopened by ned.deily

#23507: Tuple creation is too slow
http://bugs.python.org/issue23507  reopened by serhiy.storchaka

#23722: During metaclass.__init__, super() of the constructed class do
http://bugs.python.org/issue23722  reopened by ncoghlan

#28638: Creating namedtuple is too slow to be used in common stdlib (e
http://bugs.python.org/issue28638  reopened by inada.naoki

#28805: Add documentation for METH_FASTCALL
http://bugs.python.org/issue28805  opened by skrah

#28806: Improve the netrc library
http://bugs.python.org/issue28806  opened by xiang.zhang

#28808: Make PyUnicode_CompareWithASCIIString() never failing
http://bugs.python.org/issue28808  opened by serhiy.storchaka

#28809: mention asyncio.gather non-deterministic task starting order
http://bugs.python.org/issue28809  opened by Soren Solari

#28810: Document bytecode changes in 3.6
http://bugs.python.org/issue28810  opened by serhiy.storchaka

#28812: Deadlock between GIL and pystate head_mutex.
http://bugs.python.org/issue28812  opened by inada.naoki

#28813: Remove unneeded folded consts after peephole
http://bugs.python.org/issue28813  opened by Adrian Wielgosik

#28814: Deprecation notice on inspect.getargvalues() is incorrect
http://bugs.python.org/issue28814  opened by ncoghlan

#28815: test_socket fails if /proc/modules is existent but not readabl
http://bugs.python.org/issue28815  opened by patrila

#28816: Document if zipimport can respect import hooks to load custom 
http://bugs.python.org/issue28816  opened by Decorater

#28818: simplify lookdict functions
http://bugs.python.org/issue28818  opened by inada.naoki

#28820: Typo in section 6 of the Python 3.4 documentation
http://bugs.python.org/issue28820  opened by Rares Aioanei

#28822: Fix indices handling in PyUnicode_FindChar
http://bugs.python.org/issue28822  opened by xiang.zhang

#28824: os.environ should preserve the case of the OS keys ?
http://bugs.python.org/issue28824  opened by tzickel

#28826: Programming with Python 3.6
http://bugs.python.org/issue28826  opened by ADFGUR

#28827: f-strings: format spec should not accept unicode escapes
http://bugs.python.org/issue28827  opened by yselivanov

#28829: Tkinter messagebox cx_freeze Python 3.4
http://bugs.python.org/issue28829  opened by ParvizKarimli

#28832: Reduce memset in dict creation
http://bugs.python.org/issue28832  opened by inada.naoki

#28833: cross compilation of third-party extension modules
http://bugs.python.org/issue28833  opened by xdegaye

#28835: Change in behavior when overriding warnings.showwarning and wi
http://bugs.python.org/issue28835  opened by Thomas.Robitaille

#28837: 2to3 does not wrap zip correctly
http://bugs.python.org/issue28837  opened by cvk

#28838: Uniformize argument names of "call" functions (C API)
http://bugs.python.org/issue28838  opened by haypo

#28839: _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_M
http://bugs.python.org/issue28839  opened by haypo

#28840: IDLE: Document tk's long line display limitation
http://bugs.python.org/issue28840  opened by piotr.sk

#28841: urlparse.urlparse() parses invalid URI without generating an e
http://bugs.python.org/issue28841  opened by amrith

#28842: PyInstanceMethod_Type isn't hashable
http://bugs.python.org/issue28842  opened by wolever

#28845: Clean up known issues for AIX
http://bugs.python.org/issue28845  opened by ericvw

#28846: Add a ProviderKey to the installer bundle
http://bugs.python.org/issue28846  opened by steve.dower

#28847: dumbdbm should not commit if in read mode
http://bugs.python.org/issue28847  opened by Jonathan Ng

#28848: Add CopyingMock to mock.py
http://bugs.python.org/issue28848  opened by wim.glenn

#28849: do not define sys.implementation._multiarch on Android
http://bugs.python.org/issue28849  opened by xdegaye

#28850: Regression in Python 3: Subclassing PrettyPrinter.format doesn
http://bugs.python.org/issue28850  opened by mic_e

#28851: namedtuples field_names sequence preferred
http://bugs.python.org/issue28851  opened by peentoon

#28852: sorted(range(1000)) is slower in Python 3.7 compared to Python
http://bugs.python.org/issue28852  opened by haypo

#28853: locals() and free variables
http://bugs.python.org/issue28853  opened by marco.buttu

#28854: FIPS mode causes dead-lock in ssl module
http://bugs.python.org/issue28854  opened by christian.heimes

#28856: %b format for bytes does not support objects that follow the b
http://bugs.python.org/issue28856  opened by belopolsky

#28857: SyncManager and Main Process fail to communicate after reboot 
http://bugs.python.org/issue28857  opened by Nagarjuna Arigapudi

#28858: Fastcall uses more C stack
http://bugs.python.org/issue28858  opened by haypo

#28859: os.path.mount sometimes raises FileNotFoundError on Windows
http://bugs.python.org/issue28859  opened by lazka



Most recent 15 issues with no replies (15)
==========================================

#28859: os.path.mount sometimes raises FileNotFoundError on Windows
http://bugs.python.org/issue28859

#28856: %b format for bytes does not support objects that follow the b
http://bugs.python.org/issue28856

#28850: Regression in Python 3: Subclassing PrettyPrinter.format doesn
http://bugs.python.org/issue28850

#28837: 2to3 does not wrap zip correctly
http://bugs.python.org/issue28837

#28829: Tkinter messagebox cx_freeze Python 3.4
http://bugs.python.org/issue28829

#28816: Document if zipimport can respect import hooks to load custom 
http://bugs.python.org/issue28816

#28814: Deprecation notice on inspect.getargvalues() is incorrect
http://bugs.python.org/issue28814

#28812: Deadlock between GIL and pystate head_mutex.
http://bugs.python.org/issue28812

#28809: mention asyncio.gather non-deterministic task starting order
http://bugs.python.org/issue28809

#28806: Improve the netrc library
http://bugs.python.org/issue28806

#28789: valgrind shows "invalid file descriptor" when calling platform
http://bugs.python.org/issue28789

#28788: ConfigParser should be able to write config to a given filenam
http://bugs.python.org/issue28788

#28787: Out of tree --with--dtrace builds fail with a traceback
http://bugs.python.org/issue28787

#28784: shlex.shlex punctuation_chars documentation should use posix=T
http://bugs.python.org/issue28784

#28780: netrc throws NetrcParseError for record without 'password'
http://bugs.python.org/issue28780



Most recent 15 issues waiting for review (15)
=============================================

#28853: locals() and free variables
http://bugs.python.org/issue28853

#28849: do not define sys.implementation._multiarch on Android
http://bugs.python.org/issue28849

#28848: Add CopyingMock to mock.py
http://bugs.python.org/issue28848

#28847: dumbdbm should not commit if in read mode
http://bugs.python.org/issue28847

#28845: Clean up known issues for AIX
http://bugs.python.org/issue28845

#28839: _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_M
http://bugs.python.org/issue28839

#28838: Uniformize argument names of "call" functions (C API)
http://bugs.python.org/issue28838

#28833: cross compilation of third-party extension modules
http://bugs.python.org/issue28833

#28832: Reduce memset in dict creation
http://bugs.python.org/issue28832

#28822: Fix indices handling in PyUnicode_FindChar
http://bugs.python.org/issue28822

#28820: Typo in section 6 of the Python 3.4 documentation
http://bugs.python.org/issue28820

#28818: simplify lookdict functions
http://bugs.python.org/issue28818

#28815: test_socket fails if /proc/modules is existent but not readabl
http://bugs.python.org/issue28815

#28813: Remove unneeded folded consts after peephole
http://bugs.python.org/issue28813

#28808: Make PyUnicode_CompareWithASCIIString() never failing
http://bugs.python.org/issue28808



Top 10 most discussed issues (10)
=================================

#28754: Argument Clinic for bisect.bisect_left
http://bugs.python.org/issue28754  26 msgs

#28781: On Installation of 3.5 Python get error message
http://bugs.python.org/issue28781  18 msgs

#28839: _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_M
http://bugs.python.org/issue28839  12 msgs

#26273: Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket modul
http://bugs.python.org/issue26273  11 msgs

#28797: Modifying class __dict__ inside __set_name__
http://bugs.python.org/issue28797  11 msgs

#23507: Tuple creation is too slow
http://bugs.python.org/issue23507  10 msgs

#28739: PEP 498: docstrings as f-strings
http://bugs.python.org/issue28739  10 msgs

#28833: cross compilation of third-party extension modules
http://bugs.python.org/issue28833  10 msgs

#28288: Expose environment variable for Py_Py3kWarningFlag
http://bugs.python.org/issue28288   9 msgs

#28820: Typo in section 6 of the Python 3.4 documentation
http://bugs.python.org/issue28820   9 msgs



Issues closed (34)
==================

#10444: A mechanism is needed to override waiting for Python threads t
http://bugs.python.org/issue10444  closed by ebarry

#11145: '%o' % user-defined instance
http://bugs.python.org/issue11145  closed by serhiy.storchaka

#12844: Support more than 255 arguments
http://bugs.python.org/issue12844  closed by serhiy.storchaka

#20767: Some python extensions can't be compiled with clang 3.4
http://bugs.python.org/issue20767  closed by skrah

#24015: timeit should start with 1 loop, not 10
http://bugs.python.org/issue24015  closed by serhiy.storchaka

#24142: ConfigParser._read doesn't join multi-line values collected wh
http://bugs.python.org/issue24142  closed by lukasz.langa

#24469: Py2.x int free list can grow without bounds
http://bugs.python.org/issue24469  closed by serhiy.storchaka

#25701: Document that tp_setattro and tp_setattr are used for deleting
http://bugs.python.org/issue25701  closed by martin.panter

#28625: multiprocessing.Pool.imap swallows exceptions thrown by genera
http://bugs.python.org/issue28625  closed by davin

#28696: imap from ThreadPool hangs by an exception in a generator func
http://bugs.python.org/issue28696  closed by davin

#28733: Show how to use mock_open in modules other that __main__
http://bugs.python.org/issue28733  closed by butla

#28740: Add sys.getandroidapilevel()
http://bugs.python.org/issue28740  closed by haypo

#28758: UnicodeDecodeError: 'gbk' codec can't decode byte 0xab in posi
http://bugs.python.org/issue28758  closed by steve.dower

#28763: Use en-dashes for ranges in docs
http://bugs.python.org/issue28763  closed by serhiy.storchaka

#28790: Error when using Generic and __slots__
http://bugs.python.org/issue28790  closed by gvanrossum

#28799: Drop CALL_PROFILE special build?
http://bugs.python.org/issue28799  closed by haypo

#28800: Add RETURN_NONE bytecode instruction
http://bugs.python.org/issue28800  closed by haypo

#28802: Python 3.6.0b4 Reports ncurses present in Cygwin but fails to 
http://bugs.python.org/issue28802  closed by berker.peksag

#28804: file tell() report incorrect file position on Windows (but Lin
http://bugs.python.org/issue28804  closed by eric.smith

#28807: [NetBSD] interpreter hangs on exit after call to subprocess.Po
http://bugs.python.org/issue28807  closed by oskog97

#28811: Make pathlib.PurePath.__str__ use shlex.quote
http://bugs.python.org/issue28811  closed by serhiy.storchaka

#28817: Provide method PurePath.quote() that calls shlex.quote
http://bugs.python.org/issue28817  closed by zach.ware

#28819: tzinfo class spacing bug
http://bugs.python.org/issue28819  closed by bzliu94

#28821: generate_opcode_h.py crash when run with python2
http://bugs.python.org/issue28821  closed by haypo

#28823: Simplify compiling to BUILD_MAP_UNPACK
http://bugs.python.org/issue28823  closed by serhiy.storchaka

#28825: socket.SO_KEEPALIVE does not work on FreeBSD
http://bugs.python.org/issue28825  closed by benjamin.peterson

#28828: Connection reset by peer error when installing python packages
http://bugs.python.org/issue28828  closed by ebarry

#28830: Typo in whatsnew entry for 3.6
http://bugs.python.org/issue28830  closed by SilentGhost

#28831: Python 3's shutil.make_archive is truncating filenames
http://bugs.python.org/issue28831  closed by serhiy.storchaka

#28834: Type checking in set comparisons.
http://bugs.python.org/issue28834  closed by SilentGhost

#28836: Throw concurrent.futures.TimeoutError instead of concurrent.fu
http://bugs.python.org/issue28836  closed by gvanrossum

#28843: asyncio.Task implemented in C loses __traceback__ for exceptio
http://bugs.python.org/issue28843  closed by yselivanov

#28844: Pickling units
http://bugs.python.org/issue28844  closed by r.david.murray

#28855: Compiler warnings in _PyObject_CallArg1()
http://bugs.python.org/issue28855  closed by python-dev

From storchaka at gmail.com  Sat Dec  3 16:12:05 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 3 Dec 2016 23:12:05 +0200
Subject: [Python-Dev] cpython: Revert unintended merge
In-Reply-To: <20161203201312.21479.59202.71523E16@psf.io>
References: <20161203201312.21479.59202.71523E16@psf.io>
Message-ID: <o1vcf0$t7l$1@blaine.gmane.org>

On 03.12.16 22:13, steve.dower wrote:
> https://hg.python.org/cpython/rev/a60767015bed
> changeset:   105436:a60767015bed
> user:        Steve Dower <steve.dower at microsoft.com>
> date:        Sat Dec 03 12:12:23 2016 -0800
> summary:
>   Revert unintended merge

I suppose it should be reverted in the 3.6 branch too.



From steve.dower at python.org  Sat Dec  3 17:15:28 2016
From: steve.dower at python.org (Steve Dower)
Date: Sat, 3 Dec 2016 14:15:28 -0800
Subject: [Python-Dev] cpython: Revert unintended merge
In-Reply-To: <o1vcf0$t7l$1@blaine.gmane.org>
References: <20161203201312.21479.59202.71523E16@psf.io>
 <o1vcf0$t7l$1@blaine.gmane.org>
Message-ID: <435d3fc6-853d-1b44-1feb-ef7cde3a3005@python.org>

On 03Dec2016 1312, Serhiy Storchaka wrote:
> On 03.12.16 22:13, steve.dower wrote:
>> https://hg.python.org/cpython/rev/a60767015bed
>> changeset:   105436:a60767015bed
>> user:        Steve Dower <steve.dower at microsoft.com>
>> date:        Sat Dec 03 12:12:23 2016 -0800
>> summary:
>>   Revert unintended merge
>
> I suppose it should be reverted in the 3.6 branch too.

Maybe, but I didn't make the change in the 3.6 branch, so I have no idea 
whether it is meant to be there or not. But it wasn't part of the change 
I made, so I didn't want to merge it forward.

Someone who actually understands the implications of changing these 
files (config.guess, config.sub) can figure it out :)

Cheers,
Steve


From vadmium+py at gmail.com  Sat Dec  3 18:19:30 2016
From: vadmium+py at gmail.com (Martin Panter)
Date: Sat, 3 Dec 2016 23:19:30 +0000
Subject: [Python-Dev] cpython: Revert unintended merge
In-Reply-To: <435d3fc6-853d-1b44-1feb-ef7cde3a3005@python.org>
References: <20161203201312.21479.59202.71523E16@psf.io>
 <o1vcf0$t7l$1@blaine.gmane.org>
 <435d3fc6-853d-1b44-1feb-ef7cde3a3005@python.org>
Message-ID: <CA+eR4cHPuy036q1xUbrWAf9YRur9+iMPxGaNCs3jmW9OV1eQnA@mail.gmail.com>

On 3 December 2016 at 22:15, Steve Dower <steve.dower at python.org> wrote:
> On 03Dec2016 1312, Serhiy Storchaka wrote:
>>
>> On 03.12.16 22:13, steve.dower wrote:
>>>
>>> https://hg.python.org/cpython/rev/a60767015bed
>>> changeset:   105436:a60767015bed
>>> user:        Steve Dower <steve.dower at microsoft.com>
>>> date:        Sat Dec 03 12:12:23 2016 -0800
>>> summary:
>>>   Revert unintended merge
>>
>>
>> I suppose it should be reverted in the 3.6 branch too.
>
>
> Maybe, but I didn't make the change in the 3.6 branch, so I have no idea
> whether it is meant to be there or not. But it wasn't part of the change I
> made, so I didn't want to merge it forward.

This change comes from Matthias (Doko), and was originally only in the
3.5 branch:
https://hg.python.org/cpython/rev/14c80065c36e

I presume it was left unmerged until there is a branch for 3.6.1 to
merge into. So Steve, when you did your first 3.5 ? 3.6 merge, you
merged Doko?s change into 3.6:

https://hg.python.org/cpython/rev/5171bd86a36f

> Someone who actually understands the implications of changing these files
> (config.guess, config.sub) can figure it out :)

From doko at ubuntu.com  Sat Dec  3 18:31:06 2016
From: doko at ubuntu.com (Matthias Klose)
Date: Sun, 4 Dec 2016 00:31:06 +0100
Subject: [Python-Dev] cpython: Revert unintended merge
In-Reply-To: <CA+eR4cHPuy036q1xUbrWAf9YRur9+iMPxGaNCs3jmW9OV1eQnA@mail.gmail.com>
References: <20161203201312.21479.59202.71523E16@psf.io>
 <o1vcf0$t7l$1@blaine.gmane.org>
 <435d3fc6-853d-1b44-1feb-ef7cde3a3005@python.org>
 <CA+eR4cHPuy036q1xUbrWAf9YRur9+iMPxGaNCs3jmW9OV1eQnA@mail.gmail.com>
Message-ID: <a8f8d16c-32c2-99fd-f860-23113d72ebb6@ubuntu.com>

On 04.12.2016 00:19, Martin Panter wrote:
> On 3 December 2016 at 22:15, Steve Dower <steve.dower at python.org> wrote:
>> On 03Dec2016 1312, Serhiy Storchaka wrote:
>>>
>>> On 03.12.16 22:13, steve.dower wrote:
>>>>
>>>> https://hg.python.org/cpython/rev/a60767015bed
>>>> changeset:   105436:a60767015bed
>>>> user:        Steve Dower <steve.dower at microsoft.com>
>>>> date:        Sat Dec 03 12:12:23 2016 -0800
>>>> summary:
>>>>   Revert unintended merge
>>>
>>>
>>> I suppose it should be reverted in the 3.6 branch too.
>>
>>
>> Maybe, but I didn't make the change in the 3.6 branch, so I have no idea
>> whether it is meant to be there or not. But it wasn't part of the change I
>> made, so I didn't want to merge it forward.
> 
> This change comes from Matthias (Doko), and was originally only in the
> 3.5 branch:
> https://hg.python.org/cpython/rev/14c80065c36e
> 
> I presume it was left unmerged until there is a branch for 3.6.1 to
> merge into. So Steve, when you did your first 3.5 ? 3.6 merge, you
> merged Doko?s change into 3.6:
> 
> https://hg.python.org/cpython/rev/5171bd86a36f
> 
>> Someone who actually understands the implications of changing these files
>> (config.guess, config.sub) can figure it out :)

sorry about the confusion.  Noticed by other people as well.  The change should
be safe, only adding support for new targets which shouldn't affect current
architectures.  Now staying away from any other 3.5 updates until 3.6 is
released.  I'm usually trying to update these files before releases but maybe
was a bit late this time.

Matthias


From steve.dower at python.org  Sat Dec  3 18:58:37 2016
From: steve.dower at python.org (Steve Dower)
Date: Sat, 3 Dec 2016 15:58:37 -0800
Subject: [Python-Dev] cpython: Revert unintended merge
In-Reply-To: <CA+eR4cHPuy036q1xUbrWAf9YRur9+iMPxGaNCs3jmW9OV1eQnA@mail.gmail.com>
References: <20161203201312.21479.59202.71523E16@psf.io>
 <o1vcf0$t7l$1@blaine.gmane.org>
 <435d3fc6-853d-1b44-1feb-ef7cde3a3005@python.org>
 <CA+eR4cHPuy036q1xUbrWAf9YRur9+iMPxGaNCs3jmW9OV1eQnA@mail.gmail.com>
Message-ID: <01299df4-c47e-d2b9-86ae-2c29034fa6e4@python.org>

On 03Dec2016 1519, Martin Panter wrote:
> This change comes from Matthias (Doko), and was originally only in the
> 3.5 branch:
> https://hg.python.org/cpython/rev/14c80065c36e
>
> I presume it was left unmerged until there is a branch for 3.6.1 to
> merge into. So Steve, when you did your first 3.5 ? 3.6 merge, you
> merged Doko?s change into 3.6:
>
> https://hg.python.org/cpython/rev/5171bd86a36f

You're right. It didn't show up in my merge commit until I explicitly 
diffed against the previous version. I've reverted it in 3.6 as well.

Cheers,
Steve

From benjamin at python.org  Sat Dec  3 23:18:41 2016
From: benjamin at python.org (Benjamin Peterson)
Date: Sat, 03 Dec 2016 20:18:41 -0800
Subject: [Python-Dev] [RELEASE] Python 2.7.13 release candidate 1
Message-ID: <1480825121.973481.807578801.7C0355E5@webmail.messagingengine.com>

It is my pleasure to announce the first release candidate of Python
2.7.13, a new bugfix release in the Python 2.7x series.

Downloads may be found on python.org:
     https://www.python.org/downloads/release/python-2713rc1/

Please test the release and report any bugs to
    https://bugs.python.org

A final release is scheduled for 2 weeks time.

Servus,
Benjamin
(on behalf of all of 2.7's contributors)

From hpj at urpla.net  Sun Dec  4 07:22:44 2016
From: hpj at urpla.net (Hans-Peter Jansen)
Date: Sun, 04 Dec 2016 13:22:44 +0100
Subject: [Python-Dev] distutils_ui 0.1.1 released
Message-ID: <18074248.yx9y0mqd1H@xrated>

For those of you, who like PyQt{4,5} as much as I do, as well as for those who 
don't like it that much, because of the poor integration with setuptools 
et.al., here's another piece of software to bridge the gap:

	A distutils build extension for PyQt{4,5} applications

that makes handling the PyQt tool chain easier than ever:

	https://pypi.python.org/pypi/distutils_ui

Ahem, well, it wasn't that easy before. Most of us were using dreaded 
Makefiles or other such crutches to generate translation files, .py modules of 
forms, and resource modules. Scratch the crutches, here's what you're looking 
for.

Feedback welcome.

Enjoy,
Pete



From armin.rigo at gmail.com  Mon Dec  5 03:42:51 2016
From: armin.rigo at gmail.com (Armin Rigo)
Date: Mon, 5 Dec 2016 09:42:51 +0100
Subject: [Python-Dev] PyPy progress: list of CPython 3.5 crashers and bugs
Message-ID: <CAMSv6X0kPQV5S-JwatKvvNbwUSkZnq0RH-NxFmbV+dfAvE-LnA@mail.gmail.com>

Hi all,

PyPy 3.5 is progressing.  It's still alpha status, but we'll give a
progress report on morepypy.blogspot.com at some point.

Now the point of this mail is that when exploring the source code of
CPython 3.5.2+, we found a large number of crashers and bugs.  None of
them are essential---otherwise, they would already have been reported.
However, if the goal of python-dev is still to ensure that CPython
cannot normally be crashed and behaves as documented even in corner
cases, then you are probably interested in them.

I reported the first two crashers, http://bugs.python.org/issue27811
and http://bugs.python.org/issue27812, but then stopped to keep some
focus on PyPy.  I'm instead collecting them here as I find them:
http://bitbucket.org/pypy/extradoc/raw/extradoc/planning/py3.5/cpython-crashers.rst

I didn't systematically check the CPython trunk: the bugs are for
CPython 3.5.2+.  But I did check trunk a few times, and the same bug
was present there too.  So for now I assume that many items on that
list are still up-to-date.

In 3.5.2+ at least, I'm reasonably convinced that all crashers are
real, but I didn't spend the time to come up with actual examples or
patches, beyond the first two items on the list.  There are also
non-crasher bugs where the current behavior is clearly wrong according
to the documentation or the PEP.  I've also added a few points that
strike me as rather strange but not against the documentation.  What
should I do with this list?  From my point of view, I could drop it
all in a single issue, or possibly three of them (crashers, bugs,
"strange").  Alternatively I can go ahead and open one issue per
bullet point.  Which way would you prefer?  Or, if you think there is
no point in me filing issues without actual examples and patches, then
that's fine with me too and I will simply continue to expand my
cpython-crashers.rst file.


Thank you for your attention,

Armin Rigo

From ncoghlan at gmail.com  Mon Dec  5 07:22:17 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 5 Dec 2016 22:22:17 +1000
Subject: [Python-Dev] PyPy progress: list of CPython 3.5 crashers and
 bugs
In-Reply-To: <CAMSv6X0kPQV5S-JwatKvvNbwUSkZnq0RH-NxFmbV+dfAvE-LnA@mail.gmail.com>
References: <CAMSv6X0kPQV5S-JwatKvvNbwUSkZnq0RH-NxFmbV+dfAvE-LnA@mail.gmail.com>
Message-ID: <CADiSq7dBwrphsyENXhmrqxTa3PG8OO=_S6ebSD5EHLJWbg53Hw@mail.gmail.com>

On 5 December 2016 at 18:42, Armin Rigo <armin.rigo at gmail.com> wrote:
> In 3.5.2+ at least, I'm reasonably convinced that all crashers are
> real, but I didn't spend the time to come up with actual examples or
> patches, beyond the first two items on the list.  There are also
> non-crasher bugs where the current behavior is clearly wrong according
> to the documentation or the PEP.  I've also added a few points that
> strike me as rather strange but not against the documentation.  What
> should I do with this list?  From my point of view, I could drop it
> all in a single issue, or possibly three of them (crashers, bugs,
> "strange").  Alternatively I can go ahead and open one issue per
> bullet point.  Which way would you prefer?  Or, if you think there is
> no point in me filing issues without actual examples and patches, then
> that's fine with me too and I will simply continue to expand my
> cpython-crashers.rst file.

I think 3 omnibus issues would be a reasonable way to go, with the
discussion on those issues then splitting things out to either new
issue reports, or entries in
https://hg.python.org/cpython/file/default/Lib/test/crashers/ (if any
of the crashers can't be readily resolved).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From tjreedy at udel.edu  Mon Dec  5 13:38:46 2016
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 5 Dec 2016 13:38:46 -0500
Subject: [Python-Dev] PyPy progress: list of CPython 3.5 crashers and
 bugs
In-Reply-To: <CAMSv6X0kPQV5S-JwatKvvNbwUSkZnq0RH-NxFmbV+dfAvE-LnA@mail.gmail.com>
References: <CAMSv6X0kPQV5S-JwatKvvNbwUSkZnq0RH-NxFmbV+dfAvE-LnA@mail.gmail.com>
Message-ID: <o24c7j$hkd$1@blaine.gmane.org>

On 12/5/2016 3:42 AM, Armin Rigo wrote:

[what to do with]
> http://bitbucket.org/pypy/extradoc/raw/extradoc/planning/py3.5/cpython-crashers.rst

Independent isssues ultimately need separate tracker issues, but a few 
collective issues are definitely better than nothing on the tracker. 
Few free to open separate issues for any that you wish.

---
I believe that this item in your list is a design choice rather than a bug.
"* _collectionsmodule.c: deque_repr uses "[...]" as repr if recursion is
   detected.  I'd suggest that "deque(...)" is clearer---it's not a list."

I strongly suspect that Raymond H. intentionally choose to consistently 
represent deques as "deque(<somelist>)"  With recursion, some current 
results are:

 >>> import _collections as c
 >>> d = c.deque()
 >>> d.append(d)
 >>> d
deque([[...]])
 >>> d.append(1)
 >>> d
deque([[...], 1])
 >>> d.rotate()
 >>> d
deque([1, [...]])
 >>> l = []
 >>> l.append(l)
 >>> d2 = c.deque(l)
 >>> d2
deque([[[...]]])

With ... now being valid, all of these evaluate to a finite structure 
with a different representation ('Ellipsis' replacing '...').  The same 
would be true of what I believe is your proposal for the first example 
above: "deque(deque(...))".  I can see why you might prefer it.  On the 
other hand, it could be seen as falsely implying that the object is the 
result two calls to deque.  In any case, changing the repr (and possibly 
breaking existing code) would be an enhancement issue for 3.7 at the 
earliest.

At least it is the case that the representation of a pure recursive 
deque and a deque containing a pure recursive list are different.

-- 
Terry Jan Reedy


From nad at python.org  Mon Dec  5 18:45:36 2016
From: nad at python.org (Ned Deily)
Date: Mon, 5 Dec 2016 18:45:36 -0500
Subject: [Python-Dev] LAST CHANCE: 3.6.0 code freeze (3.6.0rc1) in 12 hours
 at 2016-12-07 12:00 UTC
Message-ID: <87B3103E-2819-41BA-9966-EFA5BD064665@python.org>

The final hours for fixes for 3.6.0 are here.  Although the cutoff for 3.6.0rc1 is scheduled for today, we are still reviewing a few last release-critical fixes, primarily my fault for not pinging these earlier.  So I'm going to hold off tagging rc1 for another 12 hours or so.  This is your last chance to get release-critical fixes in for 3.6.0.  After rc1 is tagged and released, the 3.6 branch will be open again for normal maintenance-release changes which will first be released in 3.6.1 in the first quarter of 2017.

Should any emergency showstopper problems be discovered affecting 3.6.0rc1, please open an issue, mark it as "release blocker", if possible push a fix to the 3.6 branch, and we will discuss what action to take for 3.6.0.  As I've mentioned many times now, my goal is to have *no* code changes for 3.6.0 after rc1 so you will have to make a *really* strong case to add any code changes after rc1 and prior to the final release scheduled for 12-16.  Should the need arise for such a change, it would be cherrypicked from the 3.6 branch.  I am more willing to consider cherry-picking pure doc changes after rc1 but these will also need to be pushed to 3.6 and marked as "release blocker".

Thank you all once again for all of your hard work in getting 3.6 to this point!  It's going to be a really good release!

--
  Ned Deily
  nad at python.org -- []


From victor.stinner at gmail.com  Mon Dec  5 19:26:43 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Tue, 6 Dec 2016 01:26:43 +0100
Subject: [Python-Dev] LAST CHANCE: 3.6.0 code freeze (3.6.0rc1) in 12
 hours at 2016-12-07 12:00 UTC
In-Reply-To: <87B3103E-2819-41BA-9966-EFA5BD064665@python.org>
References: <87B3103E-2819-41BA-9966-EFA5BD064665@python.org>
Message-ID: <CAMpsgwaiutiMVDMtjHA3SGsG+jZsDz+rZTgdySZgFdHHMO852Q@mail.gmail.com>

Hi,

Can someone please review my patch for the following issue?
"Change in behavior when overriding warnings.showwarning and with
catch_warnings(record=True)"
http://bugs.python.org/issue28835

It would be nice to fix a known regression which has a patch :-)

I added warnings._showwarnmsg() to Python 3.6 to be able to extend the
warnings API, see:
https://bugs.python.org/issue26568

Victor

2016-12-06 0:45 GMT+01:00 Ned Deily <nad at python.org>:
> The final hours for fixes for 3.6.0 are here.  Although the cutoff for 3.6.0rc1 is scheduled for today, we are still reviewing a few last release-critical fixes, primarily my fault for not pinging these earlier.  So I'm going to hold off tagging rc1 for another 12 hours or so.  This is your last chance to get release-critical fixes in for 3.6.0.  After rc1 is tagged and released, the 3.6 branch will be open again for normal maintenance-release changes which will first be released in 3.6.1 in the first quarter of 2017.
>
> Should any emergency showstopper problems be discovered affecting 3.6.0rc1, please open an issue, mark it as "release blocker", if possible push a fix to the 3.6 branch, and we will discuss what action to take for 3.6.0.  As I've mentioned many times now, my goal is to have *no* code changes for 3.6.0 after rc1 so you will have to make a *really* strong case to add any code changes after rc1 and prior to the final release scheduled for 12-16.  Should the need arise for such a change, it would be cherrypicked from the 3.6 branch.  I am more willing to consider cherry-picking pure doc changes after rc1 but these will also need to be pushed to 3.6 and marked as "release blocker".
>
> Thank you all once again for all of your hard work in getting 3.6 to this point!  It's going to be a really good release!
>
> --
>   Ned Deily
>   nad at python.org -- []
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com

From raymond.hettinger at gmail.com  Mon Dec  5 23:59:03 2016
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 5 Dec 2016 20:59:03 -0800
Subject: [Python-Dev] PyPy progress: list of CPython 3.5 crashers and
 bugs
In-Reply-To: <o24c7j$hkd$1@blaine.gmane.org>
References: <CAMSv6X0kPQV5S-JwatKvvNbwUSkZnq0RH-NxFmbV+dfAvE-LnA@mail.gmail.com>
 <o24c7j$hkd$1@blaine.gmane.org>
Message-ID: <1F0BFF6D-5AC5-4FED-AE15-AA8C5074E4CF@gmail.com>


> On Dec 5, 2016, at 10:38 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> 
> I believe that this item in your list is a design choice rather than a bug.
> "* _collectionsmodule.c: deque_repr uses "[...]" as repr if recursion is
>  detected.  I'd suggest that "deque(...)" is clearer---it's not a list."
> 
> I strongly suspect that Raymond H. intentionally choose to consistently represent deques as "deque(<somelist>)"  With recursion, some current results are:
> 
> >>> import _collections as c
> >>> d = c.deque()
> >>> d.append(d)
> >>> d
> deque([[...]])
> >>> d.append(1)
> >>> d
> deque([[...], 1])
> >>> d.rotate()
> >>> d
> deque([1, [...]])
> >>> l = []
> >>> l.append(l)
> >>> d2 = c.deque(l)
> >>> d2
> deque([[[...]]])
> 
> With ... now being valid, all of these evaluate to a finite structure with a different representation ('Ellipsis' replacing '...').  The same would be true of what I believe is your proposal for the first example above: "deque(deque(...))".  I can see why you might prefer it.  On the other hand, it could be seen as falsely implying that the object is the result two calls to deque.  In any case, changing the repr (and possibly breaking existing code) would be an enhancement issue for 3.7 at the earliest.
> 
> At least it is the case that the representation of a pure recursive deque and a deque containing a pure recursive list are different.

Terry was right that this was a design choice.  To my eye, the current form looks better than "deque(deque(...))".  Also, we use  {...} instead of OrderedDict(...).  The idea is communicate a repeated reference rather than suggesting that the named constructor is called again or trying to communicate type.  Since the repr has been in place for over a decade, changing it would be unnecessarily disruptive (to users and to the other implementations).  I think we should just let it be.


Raymond





From storchaka at gmail.com  Tue Dec  6 01:18:45 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 6 Dec 2016 08:18:45 +0200
Subject: [Python-Dev] PyPy progress: list of CPython 3.5 crashers and
 bugs
In-Reply-To: <o24c7j$hkd$1@blaine.gmane.org>
References: <CAMSv6X0kPQV5S-JwatKvvNbwUSkZnq0RH-NxFmbV+dfAvE-LnA@mail.gmail.com>
 <o24c7j$hkd$1@blaine.gmane.org>
Message-ID: <o25l82$54e$1@blaine.gmane.org>

On 05.12.16 20:38, Terry Reedy wrote:
> I believe that this item in your list is a design choice rather than a bug.
> "* _collectionsmodule.c: deque_repr uses "[...]" as repr if recursion is
>   detected.  I'd suggest that "deque(...)" is clearer---it's not a list."
>
> I strongly suspect that Raymond H. intentionally choose to consistently
> represent deques as "deque(<somelist>)"  With recursion, some current
> results are:
>
>>>> import _collections as c
>>>> d = c.deque()
>>>> d.append(d)
>>>> d
> deque([[...]])
>>>> d.append(1)
>>>> d
> deque([[...], 1])
>>>> d.rotate()
>>>> d
> deque([1, [...]])
>>>> l = []
>>>> l.append(l)
>>>> d2 = c.deque(l)
>>>> d2
> deque([[[...]]])
>
> With ... now being valid, all of these evaluate to a finite structure
> with a different representation ('Ellipsis' replacing '...').  The same
> would be true of what I believe is your proposal for the first example
> above: "deque(deque(...))".  I can see why you might prefer it.  On the
> other hand, it could be seen as falsely implying that the object is the
> result two calls to deque.  In any case, changing the repr (and possibly
> breaking existing code) would be an enhancement issue for 3.7 at the
> earliest.
>
> At least it is the case that the representation of a pure recursive
> deque and a deque containing a pure recursive list are different.

There was a discussion about this a year ago. I proposed to use <...> or 
<deque object at ...> for disambiguation.

https://mail.python.org/pipermail/python-ideas/2015-December/037537.html
https://mail.python.org/pipermail/python-ideas/2015-December/037544.html



From armin.rigo at gmail.com  Tue Dec  6 06:44:26 2016
From: armin.rigo at gmail.com (Armin Rigo)
Date: Tue, 6 Dec 2016 12:44:26 +0100
Subject: [Python-Dev] PyPy progress: list of CPython 3.5 crashers and
 bugs
In-Reply-To: <1F0BFF6D-5AC5-4FED-AE15-AA8C5074E4CF@gmail.com>
References: <CAMSv6X0kPQV5S-JwatKvvNbwUSkZnq0RH-NxFmbV+dfAvE-LnA@mail.gmail.com>
 <o24c7j$hkd$1@blaine.gmane.org>
 <1F0BFF6D-5AC5-4FED-AE15-AA8C5074E4CF@gmail.com>
Message-ID: <CAMSv6X3jyw8OZm36Po0G8oVYarBTb0vxwxz1K+o3_Q95--UTBA@mail.gmail.com>

Hi Raymond,

On 6 December 2016 at 05:59, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
> Also, we use  {...} instead of OrderedDict(...).

No, at least CPython 3.5.2 uses ``...`` for OrderedDict, and not
``{...}``.  Following that example, deques should also use ``...``
instead of ``[...]``.  But I bow to your choice and remove my point
from cpython-crashers.rst anyway.


A bient?t,

Armin.

From armin.rigo at gmail.com  Tue Dec  6 07:07:52 2016
From: armin.rigo at gmail.com (Armin Rigo)
Date: Tue, 6 Dec 2016 13:07:52 +0100
Subject: [Python-Dev] PyPy progress: list of CPython 3.5 crashers and
 bugs
In-Reply-To: <CADiSq7dBwrphsyENXhmrqxTa3PG8OO=_S6ebSD5EHLJWbg53Hw@mail.gmail.com>
References: <CAMSv6X0kPQV5S-JwatKvvNbwUSkZnq0RH-NxFmbV+dfAvE-LnA@mail.gmail.com>
 <CADiSq7dBwrphsyENXhmrqxTa3PG8OO=_S6ebSD5EHLJWbg53Hw@mail.gmail.com>
Message-ID: <CAMSv6X1yd1qo5HbvuvxJb=CpP5WMs-Qvz-eJzKp3pgKrWGTyzw@mail.gmail.com>

Hi Nick,

On 5 December 2016 at 13:22, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I think 3 omnibus issues would be a reasonable way to go, with the
> discussion on those issues then splitting things out to either new
> issue reports, or entries in
> https://hg.python.org/cpython/file/default/Lib/test/crashers/ (if any
> of the crashers can't be readily resolved).

Ok, added:

http://bugs.python.org/issue28883
http://bugs.python.org/issue28884
http://bugs.python.org/issue28885


A bient?t,

Armin.

From patrickwesterhoff at gmail.com  Tue Dec  6 05:27:35 2016
From: patrickwesterhoff at gmail.com (Patrick Westerhoff)
Date: Tue, 6 Dec 2016 11:27:35 +0100
Subject: [Python-Dev] List mutation in list_repr?
Message-ID: <CAJSKCty+a3jK6Ap_=df3kjf_XRjZ_-1qhwDMA8Xegd=Xfdtq7w@mail.gmail.com>

Hey all,

I just stumbled on the following comment in the C source of the repr
implementation for the list object:

    /* Do repr() on each element. Note that this may mutate the list,
       so must refetch the list size on each iteration. */

(as seen in list_repr implementation [1])

I?m honestly very surprised about this remark since I can neither
understand why this would be the case (repr shouldn?t mutate the
list), and I also don?t see any clue in the source as to when this
would actually happen. Since inside the loop, the list object `v` is
never accessed other than passing `v->ob_item[i]` to the recursive
repr call, there shouldn?t be any mutation on the list object itself.

I understand that a custom repr implementation could theoretically
mutate an object, but this could only affect the object itself (or its
children), but not the container list. So the list object `v` here
should be safe from mutations.

I tried looking at the original change when this was introduced.
Unfortunately, this was in 2001 [2], so I don?t really expect Tim to
still know *why* the comment was added back then.

Do you have any insights on why the comment is there, and whether I am
missing something that could actually mutate the list, making the size
refetch necessary and the comment justified?

Thanks a lot!
Patrick


[1] https://github.com/python/cpython/blob/b8519e4d08a82da9aa438d531058100c0e3d04b4/Objects/listobject.c#L361
[2] https://github.com/python/cpython/commit/bce15a39b30b0f5866e7b48ba3c29c3aa430a766

From random832 at fastmail.com  Tue Dec  6 11:32:27 2016
From: random832 at fastmail.com (Random832)
Date: Tue, 06 Dec 2016 11:32:27 -0500
Subject: [Python-Dev] List mutation in list_repr?
In-Reply-To: <CAJSKCty+a3jK6Ap_=df3kjf_XRjZ_-1qhwDMA8Xegd=Xfdtq7w@mail.gmail.com>
References: <CAJSKCty+a3jK6Ap_=df3kjf_XRjZ_-1qhwDMA8Xegd=Xfdtq7w@mail.gmail.com>
Message-ID: <1481041947.3428329.810266073.275A4820@webmail.messagingengine.com>

On Tue, Dec 6, 2016, at 05:27, Patrick Westerhoff wrote:
> Hey all,
> 
> I just stumbled on the following comment in the C source of the repr
> implementation for the list object:
> 
>     /* Do repr() on each element. Note that this may mutate the list,
>        so must refetch the list size on each iteration. */
> 
> (as seen in list_repr implementation [1])
> 
> I?m honestly very surprised about this remark since I can neither
> understand why this would be the case (repr shouldn?t mutate the
> list)

It *shouldn't*, but it can't be enforced. It's one of those things where
if Python assumes all user code is sane (in this case, overridden
__repr__ not messing with the list) it can bite in a way that could
cause the interpreter to crash.

>>> class EvilClass:
...  def __repr__(x):
...   l.pop()
...   return 'x'
...
>>> l = [EvilClass()]*10
>>> l
[x, x, x, x, x]

>, and I also don?t see any clue in the source as to when this
> would actually happen. Since inside the loop, the list object `v` is
> never accessed other than passing `v->ob_item[i]` to the recursive
> repr call, there shouldn?t be any mutation on the list object itself.

The item may have or be able to a reference to the list object
otherwise, as I demonstrated.

From hrvoje.niksic at avl.com  Tue Dec  6 11:29:07 2016
From: hrvoje.niksic at avl.com (Hrvoje Niksic)
Date: Tue, 6 Dec 2016 17:29:07 +0100
Subject: [Python-Dev] List mutation in list_repr?
In-Reply-To: <CAJSKCty+a3jK6Ap_=df3kjf_XRjZ_-1qhwDMA8Xegd=Xfdtq7w@mail.gmail.com>
References: <CAJSKCty+a3jK6Ap_=df3kjf_XRjZ_-1qhwDMA8Xegd=Xfdtq7w@mail.gmail.com>
Message-ID: <eb565a02-e557-5789-785c-2523238bb4c4@avl.com>

 > and I also don?t see any clue in the source as to when [list mutation]
 > would actually happen. Since inside the loop, the list object `v` is
 > never accessed other than passing `v->ob_item[i]` to the recursive
 > repr call, there shouldn?t be any mutation on the list object itself.

The individual object can have a reference to the list and (in extreme 
cases) do with it what it pleases:

class Evil:
     def __init__(self, l):
         self.l = l

     def __repr__(self):
         del l[:]
         return "evil"

l = []
l.append(Evil(l))
l.append(Evil(l))
print(l)

That is not something normal Python code does, but it shouldn't be 
allowed to crash the interpreter, either.


From nad at python.org  Wed Dec  7 02:26:10 2016
From: nad at python.org (Ned Deily)
Date: Wed, 7 Dec 2016 02:26:10 -0500
Subject: [Python-Dev] [RELEASE] Python 3.6.0rc1 is now available
Message-ID: <56B63E55-9CD5-4823-8282-449F6E598702@python.org>

On behalf of the Python development community and the Python 3.6 release
team, I'm excited to announce the availability of Python 3.6.0rc1. 3.6.0rc1
is the release candiate for Python 3.6, the next major release of
Python.

Code for 3.6.0 is now frozen.  Assuming no release critical problems are
found prior to the 3.6.0 final release date, currently 2016-12-16, the
3.6.0 final release will be the same code base as this 3.6.0rc1.
Maintenance releases for the 3.6 series will follow at regular
intervals starting in the first quarter of 2017.

Among the new major new features in Python 3.6 are:

* PEP 468 - Preserving the order of **kwargs in a function
* PEP 487 - Simpler customization of class creation
* PEP 495 - Local Time Disambiguation
* PEP 498 - Literal String Formatting
* PEP 506 - Adding A Secrets Module To The Standard Library
* PEP 509 - Add a private version to dict
* PEP 515 - Underscores in Numeric Literals
* PEP 519 - Adding a file system path protocol
* PEP 520 - Preserving Class Attribute Definition Order
* PEP 523 - Adding a frame evaluation API to CPython
* PEP 524 - Make os.urandom() blocking on Linux (during system startup)
* PEP 525 - Asynchronous Generators (provisional)
* PEP 526 - Syntax for Variable Annotations (provisional)
* PEP 528 - Change Windows console encoding to UTF-8
* PEP 529 - Change Windows filesystem encoding to UTF-8
* PEP 530 - Asynchronous Comprehensions

Please see "What?s New In Python 3.6" for more information:

https://docs.python.org/3.6/whatsnew/3.6.html

You can find Python 3.6.0rc1 here:

https://www.python.org/downloads/release/python-360rc1/

Note that 3.6.0rc1 is still a preview release and thus its use is not
recommended for production environments.

More information about the release schedule can be found here:

https://www.python.org/dev/peps/pep-0494/

--
  Ned Deily
  nad at python.org -- []


From nad at python.org  Wed Dec  7 03:11:40 2016
From: nad at python.org (Ned Deily)
Date: Wed, 7 Dec 2016 03:11:40 -0500
Subject: [Python-Dev] 3.6 branch is now open for 3.6.1
Message-ID: <1E6DE848-D50D-4C8C-AF09-43AB6AFFF42B@python.org>

OK, rc1 is now out the door.  Thanks to everyone who helped resolve the remaining release blocker issues.

As of now, the code base for 3.6.0 final is frozen.  The 3.6 branch is now open for code that will be released in 3.6.1, the first 3.6 maintenance release.  As usual, that means bug fixes, security fixes, and documentation updates. Refer to the Developer's Guide for more information on the development cycle.  If you have any questions about whether a change is appropriate for a 3.6.x maintenance release, please ask.

http://cpython-devguide.readthedocs.io/en/latest/devcycle.html#maintenance-branches

During the period between rc1 and the final release (scheduled for 2016-12-16), please continue to test 3.6.0rc1 and encourage others to do so.  Repeating what I wrote earlier:

Should any emergency showstopper problems be discovered affecting 3.6.0rc1, please open an issue, mark it as "release blocker", if possible push a fix to the 3.6 branch for 3.6.1, and we will discuss what action to take for 3.6.0.  As I've mentioned many times now, my goal is to have *no* code changes for 3.6.0 after rc1 so you will have to make a *really* strong case to add any code changes after rc1 and prior to the final release scheduled for 12-16.  Should the need arise for such a change, it would be cherrypicked from the 3.6 branch.  I am more willing to consider cherry-picking pure doc changes after rc1 but these will also need to be pushed to 3.6 and marked as "release blocker".

Counting down the days to the final release!

--
  Ned Deily
  nad at python.org -- []


From PatrickWesterhoff+python at gmail.com  Wed Dec  7 05:19:40 2016
From: PatrickWesterhoff+python at gmail.com (Patrick Westerhoff)
Date: Wed, 7 Dec 2016 11:19:40 +0100
Subject: [Python-Dev] List mutation in list_repr?
In-Reply-To: <1481041947.3428329.810266073.275A4820@webmail.messagingengine.com>
References: <CAJSKCty+a3jK6Ap_=df3kjf_XRjZ_-1qhwDMA8Xegd=Xfdtq7w@mail.gmail.com>
 <1481041947.3428329.810266073.275A4820@webmail.messagingengine.com>
Message-ID: <CAJSKCtymY+Fs+CZ9Ey6zNTov1TVZ2ncagS_7d87d2L=M3OdD9g@mail.gmail.com>

On Tue, Dec 6, 2016 at 5:32 PM, Random832 <random832 at fastmail.com> wrote:
> It *shouldn't*, but it can't be enforced. It's one of those things where
> if Python assumes all user code is sane (in this case, overridden
> __repr__ not messing with the list) it can bite in a way that could
> cause the interpreter to crash.

I guess you are right. That makes sense. I didn?t think about the
possibility that although the repr implementation is happening in
native code where the user objects have no access to, the list object
could still be referenced outside of the repr call.

Thanks a lot for the explanation and your example!

And also thank you Hrvoje Niksic!

From storchaka at gmail.com  Wed Dec  7 13:18:55 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 7 Dec 2016 20:18:55 +0200
Subject: [Python-Dev] List mutation in list_repr?
In-Reply-To: <CAJSKCtymY+Fs+CZ9Ey6zNTov1TVZ2ncagS_7d87d2L=M3OdD9g@mail.gmail.com>
References: <CAJSKCty+a3jK6Ap_=df3kjf_XRjZ_-1qhwDMA8Xegd=Xfdtq7w@mail.gmail.com>
 <1481041947.3428329.810266073.275A4820@webmail.messagingengine.com>
 <CAJSKCtymY+Fs+CZ9Ey6zNTov1TVZ2ncagS_7d87d2L=M3OdD9g@mail.gmail.com>
Message-ID: <o29jqa$vsr$1@blaine.gmane.org>

On 07.12.16 12:19, Patrick Westerhoff wrote:
> On Tue, Dec 6, 2016 at 5:32 PM, Random832 <random832 at fastmail.com> wrote:
>> It *shouldn't*, but it can't be enforced. It's one of those things where
>> if Python assumes all user code is sane (in this case, overridden
>> __repr__ not messing with the list) it can bite in a way that could
>> cause the interpreter to crash.
>
> I guess you are right. That makes sense. I didn?t think about the
> possibility that although the repr implementation is happening in
> native code where the user objects have no access to, the list object
> could still be referenced outside of the repr call.

There is another reason. Executing Python code can release GIL. The list 
object can be modified in other thread.



From nad at python.org  Wed Dec  7 21:07:42 2016
From: nad at python.org (Ned Deily)
Date: Wed, 7 Dec 2016 21:07:42 -0500
Subject: [Python-Dev] 3.6 What's New document changes for 3.6.0 final
Message-ID: <E63E9A9F-322C-4ED0-AC97-81AAB507D42B@python.org>

Since the question has already come up and there will likely be further changes, let's keep it simple: feel free to make changes in the 3.6 branch to Doc/whatsnew/3.6.rst for 3.6.0 and I will cherrypick those changes just prior to producing the 3.6.0 final.  Likewise with Misc/NEWS.  As stated before, any other potential changes require a 3.6 checkin and a "release blocker" issue in the tracker.

Thanks!
--Ned

--
  Ned Deily
  nad at python.org -- []


From larry at hastings.org  Thu Dec  8 17:12:54 2016
From: larry at hastings.org (Larry Hastings)
Date: Thu, 8 Dec 2016 14:12:54 -0800
Subject: [Python-Dev] Release schedule for 3.5.3 and 3.4.6
Message-ID: <d7ceb6ed-3b9b-b985-5b63-8d7c0d73a33f@hastings.org>



Here's the release schedule for Python versions 3.5.3 and 3.4.6.

    Sun Jan  1st, 2017 - tag 3.5.3rc1and 3.4.6rc1
    Mon Jan  2nd, 2017 - release 3.5.3rc1and 3.4.6rc1
    Sun Jan 15th, 2017 - tag 3.5.3 finaland 3.4.6final
    Mon Jan 16th, 2017 - release 3.5.3 finaland 3.4.6final


The 3.5 branch is still in maintenance mode.  I don't plan to transition 
it to security-fixes-only mode until 3.6 has been out for a while (e.g. 
once 3.6.1 comes out).  So 3.5.3 will be released both with source code 
and binary installers for Windows and OS X.

The 3.4 branch is already in security-fixes-only mode, and 3.4.6 will be 
a source-code-only release.


Looking forward to {next_python_version} in {days_until_release},


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161208/950cbc2e/attachment.html>

From status at bugs.python.org  Fri Dec  9 12:09:10 2016
From: status at bugs.python.org (Python tracker)
Date: Fri,  9 Dec 2016 18:09:10 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20161209170910.0DDD456349@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2016-12-02 - 2016-12-09)
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    5621 ( +8)
  closed 35057 (+55)
  total  40678 (+63)

Open issues with patches: 2440 


Issues opened (40)
==================

#28864: Add devnull file-like object
http://bugs.python.org/issue28864  opened by rhettinger

#28866: Type cache is not correctly invalidated on a class defining mr
http://bugs.python.org/issue28866  opened by sjpalt

#28867: NamedTemporaryFile does not generate a ResourceWarning for unc
http://bugs.python.org/issue28867  opened by jdufresne

#28869: __module__ attribute is not set correctly for a class created 
http://bugs.python.org/issue28869  opened by levkivskyi

#28870: Refactor PyObject_CallFunctionObjArgs() and like
http://bugs.python.org/issue28870  opened by serhiy.storchaka

#28871: Destructor of ElementTree.Element is recursive
http://bugs.python.org/issue28871  opened by serhiy.storchaka

#28874: test_logging fails and freezes
http://bugs.python.org/issue28874  opened by Whitequill Riclo

#28876: bool of large range raises OverflowError
http://bugs.python.org/issue28876  opened by mark.dickinson

#28877: Cannot compile _ssl.o on HP-UX
http://bugs.python.org/issue28877  opened by James Matthews

#28879: smtplib send_message should add Date header if it is missing, 
http://bugs.python.org/issue28879  opened by Henning.von.Bargen

#28881: int no attribute 'lower' iterating email.Message
http://bugs.python.org/issue28881  opened by Vitold S

#28882: RFC: Slice confusing with negative strides and the 0th element
http://bugs.python.org/issue28882  opened by hardkrash

#28883: Python 3.5.2 crashers (from PyPy)
http://bugs.python.org/issue28883  opened by arigo

#28884: Python 3.5.2 non-segfaulting bugs (from PyPy)
http://bugs.python.org/issue28884  opened by arigo

#28885: Python 3.5.2 strange-behavior issues (from PyPy)
http://bugs.python.org/issue28885  opened by arigo

#28886: Move deprecated abc module decorators to separate section in d
http://bugs.python.org/issue28886  opened by John Hagen

#28888: Installer fails when newer version of CRT is pending installat
http://bugs.python.org/issue28888  opened by steve.dower

#28889: IDLE needs the ability to pass in command-line arguments
http://bugs.python.org/issue28889  opened by rhettinger

#28890: logging.handlers: Document that QueueListener is a daemon thre
http://bugs.python.org/issue28890  opened by Julien Castiaux

#28891: Standardise more behaviours for zero-argument super() __class_
http://bugs.python.org/issue28891  opened by ncoghlan

#28893: Make sure exceptions raised in __aiter__ are properly chained 
http://bugs.python.org/issue28893  opened by yselivanov

#28895: Two suggestions for windows.html
http://bugs.python.org/issue28895  opened by mark

#28896: Embeddable zip allows Windows registry to override module loca
http://bugs.python.org/issue28896  opened by izbyshev

#28898: Can't compile gdb with Python 3.6
http://bugs.python.org/issue28898  opened by cstratak

#28900: update 'docs for other versions'
http://bugs.python.org/issue28900  opened by Matthias v/d Meent

#28901: Windows: document that site is not imported by default by embe
http://bugs.python.org/issue28901  opened by Matthias v/d Meent

#28902: 3.6.0rc1 installer fails to install / uninstall.
http://bugs.python.org/issue28902  opened by Decorater

#28907: test_pydoc fails if build is in sub-directory
http://bugs.python.org/issue28907  opened by nascheme

#28908: pydoc getdocloc() is broken
http://bugs.python.org/issue28908  opened by nascheme

#28909: Adding LTTng-UST tracing support
http://bugs.python.org/issue28909  opened by Francis Deslauriers

#28911: Clarify the behaviour of assert_called_once_with
http://bugs.python.org/issue28911  opened by 153957

#28912: collections.abc.OrderedMapping
http://bugs.python.org/issue28912  opened by jab

#28913: "Fatal Python error: Cannot recover from stack overflow." from
http://bugs.python.org/issue28913  opened by Richard Eames

#28914: selectmodule build fails
http://bugs.python.org/issue28914  opened by sxsns243

#28916: Not matched behavior of modulo operator % with the description
http://bugs.python.org/issue28916  opened by woo yoo

#28918: cross compiling xxlimited fails with "Py_LIMITED_API is incomp
http://bugs.python.org/issue28918  opened by xdegaye

#28919: Simplify `_copy_func_details` in unittest.mock
http://bugs.python.org/issue28919  opened by Jiajun Huang

#28920: Dangerous usage of "O" format string in _asynciomodule.c
http://bugs.python.org/issue28920  opened by haypo

#28921: Make str.count one character for latin1 string faster
http://bugs.python.org/issue28921  opened by xiang.zhang

#28922: Add fixer for "import exceptions"
http://bugs.python.org/issue28922  opened by Valentin.Lorentz



Most recent 15 issues with no replies (15)
==========================================

#28922: Add fixer for "import exceptions"
http://bugs.python.org/issue28922

#28919: Simplify `_copy_func_details` in unittest.mock
http://bugs.python.org/issue28919

#28913: "Fatal Python error: Cannot recover from stack overflow." from
http://bugs.python.org/issue28913

#28911: Clarify the behaviour of assert_called_once_with
http://bugs.python.org/issue28911

#28909: Adding LTTng-UST tracing support
http://bugs.python.org/issue28909

#28907: test_pydoc fails if build is in sub-directory
http://bugs.python.org/issue28907

#28895: Two suggestions for windows.html
http://bugs.python.org/issue28895

#28890: logging.handlers: Document that QueueListener is a daemon thre
http://bugs.python.org/issue28890

#28889: IDLE needs the ability to pass in command-line arguments
http://bugs.python.org/issue28889

#28888: Installer fails when newer version of CRT is pending installat
http://bugs.python.org/issue28888

#28877: Cannot compile _ssl.o on HP-UX
http://bugs.python.org/issue28877

#28871: Destructor of ElementTree.Element is recursive
http://bugs.python.org/issue28871

#28859: os.path.ismount sometimes raises FileNotFoundError on Windows
http://bugs.python.org/issue28859

#28856: %b format for bytes does not support objects that follow the b
http://bugs.python.org/issue28856

#28850: Regression in Python 3: Subclassing PrettyPrinter.format doesn
http://bugs.python.org/issue28850



Most recent 15 issues waiting for review (15)
=============================================

#28921: Make str.count one character for latin1 string faster
http://bugs.python.org/issue28921

#28920: Dangerous usage of "O" format string in _asynciomodule.c
http://bugs.python.org/issue28920

#28919: Simplify `_copy_func_details` in unittest.mock
http://bugs.python.org/issue28919

#28918: cross compiling xxlimited fails with "Py_LIMITED_API is incomp
http://bugs.python.org/issue28918

#28914: selectmodule build fails
http://bugs.python.org/issue28914

#28912: collections.abc.OrderedMapping
http://bugs.python.org/issue28912

#28911: Clarify the behaviour of assert_called_once_with
http://bugs.python.org/issue28911

#28909: Adding LTTng-UST tracing support
http://bugs.python.org/issue28909

#28907: test_pydoc fails if build is in sub-directory
http://bugs.python.org/issue28907

#28896: Embeddable zip allows Windows registry to override module loca
http://bugs.python.org/issue28896

#28893: Make sure exceptions raised in __aiter__ are properly chained 
http://bugs.python.org/issue28893

#28885: Python 3.5.2 strange-behavior issues (from PyPy)
http://bugs.python.org/issue28885

#28876: bool of large range raises OverflowError
http://bugs.python.org/issue28876

#28870: Refactor PyObject_CallFunctionObjArgs() and like
http://bugs.python.org/issue28870

#28867: NamedTemporaryFile does not generate a ResourceWarning for unc
http://bugs.python.org/issue28867



Top 10 most discussed issues (10)
=================================

#28838: Using consistent naming for arguments of "call" functions (C A
http://bugs.python.org/issue28838  14 msgs

#28884: Python 3.5.2 non-segfaulting bugs (from PyPy)
http://bugs.python.org/issue28884  14 msgs

#28885: Python 3.5.2 strange-behavior issues (from PyPy)
http://bugs.python.org/issue28885  14 msgs

#28147: Unbounded memory growth resizing split-table dicts
http://bugs.python.org/issue28147  11 msgs

#28866: Type cache is not correctly invalidated on a class defining mr
http://bugs.python.org/issue28866  10 msgs

#28089: asyncio: Document that TCP_NODELAY is now used by default
http://bugs.python.org/issue28089   9 msgs

#28896: Embeddable zip allows Windows registry to override module loca
http://bugs.python.org/issue28896   9 msgs

#28867: NamedTemporaryFile does not generate a ResourceWarning for unc
http://bugs.python.org/issue28867   8 msgs

#28900: update 'docs for other versions'
http://bugs.python.org/issue28900   8 msgs

#28091: Document PEP 525
http://bugs.python.org/issue28091   7 msgs



Issues closed (52)
==================

#12660: test_gdb fails when installed
http://bugs.python.org/issue12660  closed by inada.naoki

#26566: Failures on FreeBSD CURRENT buildbot
http://bugs.python.org/issue26566  closed by haypo

#26769: Python 2.7: make private file descriptors non inheritable
http://bugs.python.org/issue26769  closed by haypo

#26937: the chown() method of the tarfile.TarFile class fails on Andro
http://bugs.python.org/issue26937  closed by xdegaye

#26939: android: test_functools hangs on armv7
http://bugs.python.org/issue26939  closed by xdegaye

#26940: android: test_importlib hangs on armv7
http://bugs.python.org/issue26940  closed by xdegaye

#26941: android: test_threading hangs on armv7
http://bugs.python.org/issue26941  closed by xdegaye

#27050: Demote run() below the high level APIs in subprocess docs
http://bugs.python.org/issue27050  closed by ncoghlan

#27367: Windows buildbot: random timeout failure on test_threading
http://bugs.python.org/issue27367  closed by haypo

#27784: Random failure of test_TCPServer() of test.test_socketserver.S
http://bugs.python.org/issue27784  closed by haypo

#27791: test_threading: test_threads_join_2() failed with "Fatal Pytho
http://bugs.python.org/issue27791  closed by haypo

#27829: test.regrtest: changed environment variables are not logged
http://bugs.python.org/issue27829  closed by haypo

#27864: test_socket: unknown thread blocks forever on "AMD64 FreeBSD 9
http://bugs.python.org/issue27864  closed by haypo

#27971: utf-16 decoding can't handle lone surrogates
http://bugs.python.org/issue27971  closed by lazka

#28050: test_traceback is broken by new CALL_FUNCTION* opcodes
http://bugs.python.org/issue28050  closed by haypo

#28152: Clang warnings: code will never be executed
http://bugs.python.org/issue28152  closed by haypo

#28731: _PyDict_NewPresized() creates too small dict
http://bugs.python.org/issue28731  closed by inada.naoki

#28770: Update python-gdb.py for fastcalls
http://bugs.python.org/issue28770  closed by haypo

#28797: Modifying class __dict__ inside __set_name__
http://bugs.python.org/issue28797  closed by ncoghlan

#28808: Make PyUnicode_CompareWithASCIIString() never failing
http://bugs.python.org/issue28808  closed by serhiy.storchaka

#28818: simplify lookdict functions
http://bugs.python.org/issue28818  closed by inada.naoki

#28829: Tkinter messagebox cx_freeze Python 3.4
http://bugs.python.org/issue28829  closed by terry.reedy

#28835: Change in behavior when overriding warnings.showwarning and wi
http://bugs.python.org/issue28835  closed by ned.deily

#28846: Add a ProviderKey to the installer bundle
http://bugs.python.org/issue28846  closed by steve.dower

#28847: dumbdbm should not commit if in read mode
http://bugs.python.org/issue28847  closed by serhiy.storchaka

#28852: sorted(range(1000)) is slower in Python 3.7 than in 3.5
http://bugs.python.org/issue28852  closed by haypo

#28853: locals() and free variables
http://bugs.python.org/issue28853  closed by marco.buttu

#28854: FIPS mode causes dead-lock in ssl module
http://bugs.python.org/issue28854  closed by christian.heimes

#28858: Fastcall uses more C stack
http://bugs.python.org/issue28858  closed by haypo

#28860: Fixed all the doctest failures in Doc/library/configparser.rst
http://bugs.python.org/issue28860  closed by marco.buttu

#28861: Type Hints Syntax
http://bugs.python.org/issue28861  closed by YoSTEALTH

#28862: test_import.py leaks on 2.7
http://bugs.python.org/issue28862  closed by python-dev

#28863: Doc/includes/*.py files and doctests
http://bugs.python.org/issue28863  closed by marco.buttu

#28865: [MinGW32-x64]-PyList_Check PyDict_Check does not work
http://bugs.python.org/issue28865  closed by mifik

#28868: Python advertising BeOpen.com domain
http://bugs.python.org/issue28868  closed by ebarry

#28872: test_builtin failures when refleak hunting
http://bugs.python.org/issue28872  closed by ned.deily

#28873: test_unittest failures when refleak hunting
http://bugs.python.org/issue28873  closed by berker.peksag

#28875: test fails and freezes
http://bugs.python.org/issue28875  closed by martin.panter

#28878: datetime should not be a subclass of date
http://bugs.python.org/issue28878  closed by r.david.murray

#28880: range(i, j) doesn't work
http://bugs.python.org/issue28880  closed by r.david.murray

#28887: Login with Google not working on PyPi site
http://bugs.python.org/issue28887  closed by SilentGhost

#28892: pandas.to_datetime crashes in 3.6b4
http://bugs.python.org/issue28892  closed by ned.deily

#28894: Memory leak in dict.pop()
http://bugs.python.org/issue28894  closed by xiang.zhang

#28897: Python 3.6.0rc1 breaks NumPy tests.
http://bugs.python.org/issue28897  closed by ncoghlan

#28899: Symbols doesn't match in VS for python.exe and python35.dll
http://bugs.python.org/issue28899  closed by Arkady ???KindDragon??? Shapkin

#28903: Windows Embeddable Python exit not defined
http://bugs.python.org/issue28903  closed by zach.ware

#28904: add more format conversion flags eg. "len" and "id"
http://bugs.python.org/issue28904  closed by Samuel Colvin

#28905: re.sub appears not to check count optional argument for intege
http://bugs.python.org/issue28905  closed by r.david.murray

#28906: Can't inherit sockets with multiprocessing on Windows
http://bugs.python.org/issue28906  closed by planders

#28910: Async generator does not raise RuntimeError if finalizer not s
http://bugs.python.org/issue28910  closed by yselivanov

#28915: Modify PyObject_CallFunction() to use fast call internally
http://bugs.python.org/issue28915  closed by haypo

#28917: Docs: Add missing protocol to pickle
http://bugs.python.org/issue28917  closed by ChillarAnand

From victor.stinner at gmail.com  Fri Dec  9 12:46:32 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 9 Dec 2016 18:46:32 +0100
Subject: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
Message-ID: <CAMpsgwbHYAa_kshEBgZcZerywdMpV779P4jT4ncyiNPOdC1WJA@mail.gmail.com>

Hi,

The PyObject_CallFunction() function has a special case when the
format string is "O", to pass exactly one Python object:

* If the argument is a tuple, the tuple is unpacked: it behaves like func(*arg)
* Otherwise, it behaves like func(arg)

This case is not documented in the C API !
https://docs.python.org/dev/c-api/object.html#c.PyObject_CallFunction


The following C functions have the special case:

* PyObject_CallFunction(), _PyObject_CallFunction_SizeT()
* PyObject_CallMethod(), _PyObject_CallMethod_SizeT()
* _PyObject_CallMethodId(), _PyObject_CallMethodId_SizeT()


I guess that it's a side effect of the implementation: the code uses
Py_BuildValue() and then checks if the value is a tuple or not.
Py_BuildValue() is a little bit surprising:

* "i" creates an integer object
* "ii" creates a tuple
* "(i)" and "(ii)" create a tuple.

Getting a tuple or not depends on the length of the format string. It
is not obvious when you have nested tuples like "O(OO)".

Because of the special case, passing a tuple as the only argument
requires to write "((...))" instead of just "(...)".


In the past, this special behaviour caused a bug in
generator.send(arg), probably because the author of the C code
implementing generator.send() wasn't aware of the special case. See
the issue:
http://bugs.python.org/issue21209

I found code using "O" format in the new _asyncio module, and I'm
quite sure that unpacking special case is not expected. So I opened an
issue:
http://bugs.python.org/issue28920


Last days, I patched functions of PyObject_CallFunction() family to
use internally fast calls. I implemented the special case to keep
backward compatibility.

I replaced a lot of code using PyObject_CallFunction() with
PyObject_CallFunctionObjArgs() when the format string was only made of
"O", PyObject* arguments. I made this change to optimize the code, but
indirectly, it avoids also the special case for code which used
exactly "O" format. See:
http://bugs.python.org/issue28915

When I made these changes, I found some functions which rely the
unpacking feature!

* time_strptime() (change 49a7fdc0d40a)
* unpickle() of _ctypes (change ceb22b8f6d32)

I don't know well what we are supposed to do. I don't think that
changing the behaviour of PyObject_CallFunction() to remove the
special case is a good idea. It would be an obvious backward
incompatible change which can break applications.

I guess that the minimum is to document the special case?

Victor

From victor.stinner at gmail.com  Fri Dec  9 13:03:44 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 9 Dec 2016 19:03:44 +0100
Subject: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
In-Reply-To: <CAMpsgwbHYAa_kshEBgZcZerywdMpV779P4jT4ncyiNPOdC1WJA@mail.gmail.com>
References: <CAMpsgwbHYAa_kshEBgZcZerywdMpV779P4jT4ncyiNPOdC1WJA@mail.gmail.com>
Message-ID: <CAMpsgwYWr_G3Oy66Xd3npXUK7Uds=GTLP94nLwXaDq0iYRa0eg@mail.gmail.com>

2016-12-09 18:46 GMT+01:00 Victor Stinner <victor.stinner at gmail.com>:
> Last days, I patched functions of PyObject_CallFunction() family to
> use internally fast calls.
> (...)
> http://bugs.python.org/issue28915

Oh, I forgot to mention the performance results of these changes.
Python slots are now a little bit faster. Extract of the issue:
http://bugs.python.org/issue28915#msg282748

Microbenchmark on a simple class with an __int__() method, call int(o):
int(o): Median +- std dev: [ref] 239 ns +- 13 ns -> [patch] 219 ns +-
14 ns: 1.10x faster (-9%)

Microbenchmark on a simple class with an __getitem__() method, call o[100]:
o[100]: Median +- std dev: [ref] 211 ns +- 11 ns -> [patch] 172 ns +-
11 ns: 1.23x faster (-19%)


Comparison between Python 2.7, 3.5, 3.7 and 3.7+patch, 3.5 is used as
the reference:

int(o)
======

Median +- std dev: [3.5] 271 ns +- 15 ns -> [3.7] 239 ns +- 13 ns:
1.13x faster (-12%)
Median +- std dev: [3.5] 271 ns +- 15 ns -> [patch] 219 ns +- 14 ns:
1.24x faster (-19%)
Median +- std dev: [3.5] 271 ns +- 15 ns -> [2.7] 401 ns +- 21 ns:
1.48x slower (+48%)

o[100]
======

Median +- std dev: [3.5] 206 ns +- 5 ns -> [3.7] 211 ns +- 11 ns:
1.02x slower (+2%)
Not significant!
Median +- std dev: [3.5] 206 ns +- 5 ns -> [patch] 172 ns +- 11 ns:
1.20x faster (-17%)
Median +- std dev: [3.5] 206 ns +- 5 ns -> [2.7] 254 ns +- 15 ns:
1.23x slower (+23%)

Victor

From brett at python.org  Fri Dec  9 19:31:13 2016
From: brett at python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 00:31:13 +0000
Subject: [Python-Dev] Checking over the devguide before the GitHub migration
Message-ID: <CAP1=2W7W3-3b9MMtPtYRpYMshTy=di5h0y4ntS=0fD1b5BV=BA@mail.gmail.com>

With Python 3.6.0 quickly approaching it means the GitHub migration should
also be happening sometime soon (basically as soon as all pieces are in
place and we're sure we won't be doing an emergency 3.6.1 release, so
probably either this month or next). While we wait for that to occur, if
people want to help then please read through the GitHub version of the
devguide at http://cpython-devguide.readthedocs.io/en/github/ and if you
find any issues then please submit a PR at
https://github.com/python/devguide.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/ddee1f8b/attachment.html>

From brett at python.org  Fri Dec  9 20:21:25 2016
From: brett at python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 01:21:25 +0000
Subject: [Python-Dev] New core-workflow issue tracker
Message-ID: <CAP1=2W41DbtZcw2+-x9Btm65iCEdZbFqY=RcAimxaYLbmOkn4g@mail.gmail.com>

I have created https://github.com/python/core-workflow to track plans and
ideas for our workflow. Discussions will continue on the core-workflow
mailing list, but since there are things to plan and this sort of thing
doesn't really belong on bugs.python.org I figured a separate tracker would
be best.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/7e799524/attachment.html>

From larry at hastings.org  Sat Dec 10 00:56:44 2016
From: larry at hastings.org (Larry Hastings)
Date: Fri, 9 Dec 2016 21:56:44 -0800
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
Message-ID: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>



"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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161209/ab830bee/attachment.html>

From storchaka at gmail.com  Sat Dec 10 01:43:57 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 10 Dec 2016 08:43:57 +0200
Subject: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
In-Reply-To: <CAMpsgwbHYAa_kshEBgZcZerywdMpV779P4jT4ncyiNPOdC1WJA@mail.gmail.com>
References: <CAMpsgwbHYAa_kshEBgZcZerywdMpV779P4jT4ncyiNPOdC1WJA@mail.gmail.com>
Message-ID: <o2g879$89u$1@blaine.gmane.org>

On 09.12.16 19:46, Victor Stinner wrote:
> The PyObject_CallFunction() function has a special case when the
> format string is "O", to pass exactly one Python object:
>
> * If the argument is a tuple, the tuple is unpacked: it behaves like func(*arg)
> * Otherwise, it behaves like func(arg)
>
> This case is not documented in the C API !
> https://docs.python.org/dev/c-api/object.html#c.PyObject_CallFunction

It is documented for Py_BuildValue(), and the documentation of 
PyObject_CallFunction() refers to Py_BuildValue().

I just found that in spite of your changes of parameter names, the 
documentation still have old names:

     PyObject* PyObject_CallMethod(PyObject *o, const char *method, 
const char *format, ...)



From storchaka at gmail.com  Sat Dec 10 01:55:23 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 10 Dec 2016 08:55:23 +0200
Subject: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
In-Reply-To: <CAMpsgwbHYAa_kshEBgZcZerywdMpV779P4jT4ncyiNPOdC1WJA@mail.gmail.com>
References: <CAMpsgwbHYAa_kshEBgZcZerywdMpV779P4jT4ncyiNPOdC1WJA@mail.gmail.com>
Message-ID: <o2g8so$8bo$1@blaine.gmane.org>

On 09.12.16 19:46, Victor Stinner wrote:
> Last days, I patched functions of PyObject_CallFunction() family to
> use internally fast calls. I implemented the special case to keep
> backward compatibility.
>
> I replaced a lot of code using PyObject_CallFunction() with
> PyObject_CallFunctionObjArgs() when the format string was only made of
> "O", PyObject* arguments. I made this change to optimize the code, but
> indirectly, it avoids also the special case for code which used
> exactly "O" format. See:
> http://bugs.python.org/issue28915

I didn't have a change to make a review of your patches, because they 
were pushed 7 minutes after publishing a patch. I'm still in the process 
of post-commit reviewing. Could you please give more time for pre-commit 
review?

I thought about similar changes, but since I didn't have evidences that 
they cause performance gain, I dropped my patches. Do you have benchmark 
results that proof the speed up for all your changes?

Did you checked that your changes do not increase C stack consumption?



From ncoghlan at gmail.com  Sat Dec 10 02:24:04 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 10 Dec 2016 17:24:04 +1000
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
Message-ID: <CADiSq7egdy0ccZcFucN5qE78maOiGmwpY=Hxq3Tsk6EB0XiTSg@mail.gmail.com>

On 10 December 2016 at 15:56, Larry Hastings <larry at hastings.org> wrote:
>
> "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

Aye, I saw that recently in an Infoworld article. One area where this
could be particularly interesting is for folks embedding Python in
larger commercial applications (ArcGIS, Maya, etc) that already build
their own Python from source with the same C/C++ compiler that they
use to build the rest of the application (so arbitrary Python C
extensions aren't supported).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From storchaka at gmail.com  Sat Dec 10 02:58:40 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 10 Dec 2016 09:58:40 +0200
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
Message-ID: <o2gcjb$p79$1@blaine.gmane.org>

On 10.12.16 07:56, Larry Hastings wrote:
> "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."

I think this project should be renamed.



From steve at pearwood.info  Sat Dec 10 03:09:31 2016
From: steve at pearwood.info (Steven D'Aprano)
Date: Sat, 10 Dec 2016 19:09:31 +1100
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
Message-ID: <20161210080930.GY3365@ando.pearwood.info>

On Fri, Dec 09, 2016 at 09:56:44PM -0800, Larry Hastings wrote:
> 
> "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
[...]
> https://github.com/naftaliharris/python2.8

I seem to recall that when we discussed the future of Python 2.x, and 
the decision that 2.7 would be the final version and there would be no 
2.8, we reached a consensus that if anyone did backport Python 3 
features to a Python 2 fork, they should not call it Python 2.8 as that 
could mislead people into thinking it was officially supported.

I think the project should be renamed to make it clear that its a fork, 
like Stackless.



-- 
Steve

From barry at python.org  Sat Dec 10 03:18:37 2016
From: barry at python.org (Barry Warsaw)
Date: Sat, 10 Dec 2016 09:18:37 +0100
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <20161210080930.GY3365@ando.pearwood.info>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
Message-ID: <20161210091837.2c8ca8e0.barry@wooz.org>

On Dec 10, 2016, at 07:09 PM, Steven D'Aprano wrote:

>I seem to recall that when we discussed the future of Python 2.x, and the
>decision that 2.7 would be the final version and there would be no 2.8, we
>reached a consensus that if anyone did backport Python 3 features to a Python
>2 fork, they should not call it Python 2.8 as that could mislead people into
>thinking it was officially supported.
>
>I think the project should be renamed to make it clear that its a fork, 
>like Stackless.

Yes, exactly right.  It's not sanctioned by the PSF and should not be called
"Python" anything.

-Barry

From mertz at gnosis.cx  Sat Dec 10 04:05:37 2016
From: mertz at gnosis.cx (David Mertz)
Date: Sat, 10 Dec 2016 01:05:37 -0800
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <20161210091837.2c8ca8e0.barry@wooz.org>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
Message-ID: <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>

I'm forwarding this to the PSF Trademarks committee. If there is a
violation, it's a misuse of trademark, not copyright on the code which has
the Python license stack.

I'm on that committee and agree this is improper use. Let's see what other
members think.

On Dec 10, 2016 12:19 AM, "Barry Warsaw" <barry at python.org> wrote:

On Dec 10, 2016, at 07:09 PM, Steven D'Aprano wrote:

>I seem to recall that when we discussed the future of Python 2.x, and the
>decision that 2.7 would be the final version and there would be no 2.8, we
>reached a consensus that if anyone did backport Python 3 features to a
Python
>2 fork, they should not call it Python 2.8 as that could mislead people
into
>thinking it was officially supported.
>
>I think the project should be renamed to make it clear that its a fork,
>like Stackless.

Yes, exactly right.  It's not sanctioned by the PSF and should not be called
"Python" anything.

-Barry
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/
mertz%40gnosis.cx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/50631b45/attachment.html>

From tjreedy at udel.edu  Sat Dec 10 05:15:30 2016
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 10 Dec 2016 05:15:30 -0500
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
Message-ID: <o2gkjv$4uj$1@blaine.gmane.org>

On 12/10/2016 4:05 AM, David Mertz wrote:
> I'm forwarding this to the PSF Trademarks committee. If there is a
> violation, it's a misuse of trademark, not copyright on the code which
> has the Python license stack.

I believe that this 'derived work' is both a trademark and a license 
violation.  Clause 7 of the PSF License V. 2, as displayed by '>>> 
license()', explicitly denies permission to make derivative works that 
violate PSF Trademarks.  Perhaps Github and Infoworld should be informed 
also, but our lawyer can decide.

"This License Agreement does not grant permission to use PSF
trademarks ..."

Perhaps that document should mention somewhere at the top that "Python" 
is a PSF Trademark for computer languages.

> I'm on that committee and agree this is improper use. Let's see what
> other members think.
>
> On Dec 10, 2016 12:19 AM, "Barry Warsaw" <barry at python.org
> <mailto:barry at python.org>> wrote:
>
>     On Dec 10, 2016, at 07:09 PM, Steven D'Aprano wrote:
>
>     >I seem to recall that when we discussed the future of Python 2.x,
>     and the
>     >decision that 2.7 would be the final version and there would be no
>     2.8, we
>     >reached a consensus that if anyone did backport Python 3 features
>     to a Python
>     >2 fork, they should not call it Python 2.8 as that could mislead
>     people into
>     >thinking it was officially supported.
>     >
>     >I think the project should be renamed to make it clear that its a fork,
>     >like Stackless.
>
>     Yes, exactly right.  It's not sanctioned by the PSF and should not
>     be called
>     "Python" anything.
>
>     -Barry
>     _______________________________________________
>     Python-Dev mailing list
>     Python-Dev at python.org <mailto:Python-Dev at python.org>
>     https://mail.python.org/mailman/listinfo/python-dev
>     <https://mail.python.org/mailman/listinfo/python-dev>
>     Unsubscribe:
>     https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>     <https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx>
>
>
>
>


-- 
Terry Jan Reedy


From p.f.moore at gmail.com  Sat Dec 10 05:36:16 2016
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 10 Dec 2016 10:36:16 +0000
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <o2gkjv$4uj$1@blaine.gmane.org>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <o2gkjv$4uj$1@blaine.gmane.org>
Message-ID: <CACac1F-iYjLKvs5+=uwk68MrBYnSV_5na-0S389g6RmvOGD7VA@mail.gmail.com>

On 10 December 2016 at 10:15, Terry Reedy <tjreedy at udel.edu> wrote:
> On 12/10/2016 4:05 AM, David Mertz wrote:
>>
>> I'm forwarding this to the PSF Trademarks committee. If there is a
>> violation, it's a misuse of trademark, not copyright on the code which
>> has the Python license stack.
>
>
> I believe that this 'derived work' is both a trademark and a license
> violation.  Clause 7 of the PSF License V. 2, as displayed by '>>>
> license()', explicitly denies permission to make derivative works that
> violate PSF Trademarks.  Perhaps Github and Infoworld should be informed
> also, but our lawyer can decide.
>
> "This License Agreement does not grant permission to use PSF
> trademarks ..."
>
> Perhaps that document should mention somewhere at the top that "Python" is a
> PSF Trademark for computer languages.

Someone has raised an issue against the project at
https://github.com/naftaliharris/python2.8/issues/47 We should
probably see what the project owner's response to that is.

Paul

From p.f.moore at gmail.com  Sat Dec 10 05:40:36 2016
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 10 Dec 2016 10:40:36 +0000
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CACac1F-iYjLKvs5+=uwk68MrBYnSV_5na-0S389g6RmvOGD7VA@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <o2gkjv$4uj$1@blaine.gmane.org>
 <CACac1F-iYjLKvs5+=uwk68MrBYnSV_5na-0S389g6RmvOGD7VA@mail.gmail.com>
Message-ID: <CACac1F8rpa2n=NjhdFF9zq2K+Hdc9aD+bpj3mJDg-auPHdkcwg@mail.gmail.com>

On 10 December 2016 at 10:36, Paul Moore <p.f.moore at gmail.com> wrote:
> Someone has raised an issue against the project at
> https://github.com/naftaliharris/python2.8/issues/47 We should
> probably see what the project owner's response to that is.

By the way, looking at the project history, it seems to have been
round for some time (there's no obvious way that I can see in the
github UI to see when a project was forked from its parent, but I can
see branches by the project owner from a year ago).

Paul

From xavier.combelle at gmail.com  Sat Dec 10 07:18:22 2016
From: xavier.combelle at gmail.com (Xavier Combelle)
Date: Sat, 10 Dec 2016 13:18:22 +0100
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <o2gkjv$4uj$1@blaine.gmane.org>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <o2gkjv$4uj$1@blaine.gmane.org>
Message-ID: <c987ebc2-743f-7d56-5fd4-104dc99fae03@gmail.com>


> I believe that this 'derived work' is both a trademark and a license
> violation.  Clause 7 of the PSF License V. 2, as displayed by '>>>
> license()', explicitly denies permission to make derivative works that
> violate PSF Trademarks.  Perhaps Github and Infoworld should be
> informed also, but our lawyer can decide.
>
> "This License Agreement does not grant permission to use PSF
> trademarks ..."
>
> Perhaps that document should mention somewhere at the top that
> "Python" is a PSF Trademark for computer languages.
I am not a lawyer, but to my understanding, violating the trademark is
not a violation of the license. The fact that the license mention it
doesn't grant permission to use PSF trademarks doesn't mean that by
violating the trademark you also violate the license.

From ncoghlan at gmail.com  Sat Dec 10 08:15:00 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 10 Dec 2016 23:15:00 +1000
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <20161210091837.2c8ca8e0.barry@wooz.org>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
Message-ID: <CADiSq7dXMLBYWrbRpYoJ_fr5peQuUb+ciFWSJ04vPJ-7uUF2tQ@mail.gmail.com>

On 10 December 2016 at 18:18, Barry Warsaw <barry at python.org> wrote:
> On Dec 10, 2016, at 07:09 PM, Steven D'Aprano wrote:
>
>>I seem to recall that when we discussed the future of Python 2.x, and the
>>decision that 2.7 would be the final version and there would be no 2.8, we
>>reached a consensus that if anyone did backport Python 3 features to a Python
>>2 fork, they should not call it Python 2.8 as that could mislead people into
>>thinking it was officially supported.
>>
>>I think the project should be renamed to make it clear that its a fork,
>>like Stackless.
>
> Yes, exactly right.  It's not sanctioned by the PSF and should not be called
> "Python" anything.

NorwegianBlue would be thematically appropriate ;)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From mal at egenix.com  Sat Dec 10 08:49:30 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat, 10 Dec 2016 14:49:30 +0100
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
Message-ID: <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>

On 10.12.2016 10:05, David Mertz wrote:
> I'm forwarding this to the PSF Trademarks committee. If there is a
> violation, it's a misuse of trademark, not copyright on the code which has
> the Python license stack.
> 
> I'm on that committee and agree this is improper use. Let's see what other
> members think.

Our trademark policy for the word mark Python does allow
for such use and without asking for permissions:

https://www.python.org/psf/trademarks/
"""
...
As such, stating accurately that software is written in the Python
programming language, that it is compatible with the Python programming
language, or that it contains the Python programming language, is always
allowed. In those cases, you may use the word "Python" or the unaltered
logos to indicate this, without our prior approval. This is true both
for non-commercial and commercial uses.

This clause overrides other clauses of this policy.
...
"""

and this is on purpose, since Python is BSD software which
anyone can use, modify, fork, etc.

The fork also contains a list of differences compared to
Python 2.7 as shipped by the PSF, so the license is fulfilled
as well:

https://github.com/naftaliharris/python2.8

All that said, I still believe we should contact the author
and ask for a name change to make it clear to our users that
the PSF is not endorsing this fork, nor does it provide
support for it:

https://github.com/naftaliharris
https://www.naftaliharris.com/contact/

Regardless of the name, it'll be interesting to see whether
there's demand for such a fork. Without a website, binaries
to download, documentation, etc. it's still in the very early
stages.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Dec 10 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
                      http://www.malemburg.com/


From gjcarneiro at gmail.com  Sat Dec 10 10:09:51 2016
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Sat, 10 Dec 2016 15:09:51 +0000
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
Message-ID: <CAO-CpELoCX8wy6NsRNoq5pVT13kPuVDypSzkaz0mnbfEhNGFCw@mail.gmail.com>

On 10 December 2016 at 13:49, M.-A. Lemburg <mal at egenix.com> wrote:
[...]

> Regardless of the name, it'll be interesting to see whether
> there's demand for such a fork. Without a website, binaries
> to download, documentation, etc. it's still in the very early
> stages.
>

IMHO, whether or not there is demand for this release should be
irrelevant.  Caving in to Python 2.8 demand is trading off some short term
gains (adding some Python 3 features to code bases locked into Python 2),
in detriment of a big long-term risk, which is that the Python language
permanently forks into two versions: Python 2 and Python 3.

Right now we have a solid expectation that eventually Python 2 is going to
be legacy and most code bases will convert to Python 3.  If we somehow
endorse Python 2.8, many developers will be tempted to just stick with
Python 2 forever.  This would be very very bad for the future of the
language as whole.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/a15a651c/attachment-0001.html>

From guido at python.org  Sat Dec 10 11:07:01 2016
From: guido at python.org (Guido van Rossum)
Date: Sat, 10 Dec 2016 08:07:01 -0800
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CAO-CpELoCX8wy6NsRNoq5pVT13kPuVDypSzkaz0mnbfEhNGFCw@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CAO-CpELoCX8wy6NsRNoq5pVT13kPuVDypSzkaz0mnbfEhNGFCw@mail.gmail.com>
Message-ID: <CAP7+vJLTTEx4A_BWR75P3aOnfPSY2iafk5Fw2rUCSFyq6EnfrA@mail.gmail.com>

While I think the name is misleading and in violation of PSF policy and/or
license, I am not too worried about this. I expect it will be tough to port
libraries from Python 3 reliably because it is not true Python 3 (e.g.
str/bytes). So then it's just a toy. Who cares about having 'async def' if
there's no backport of asyncio?

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/a87a0743/attachment.html>

From flying-sheep at web.de  Sat Dec 10 08:00:30 2016
From: flying-sheep at web.de (Philipp A.)
Date: Sat, 10 Dec 2016 13:00:30 +0000
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CACac1F-iYjLKvs5+=uwk68MrBYnSV_5na-0S389g6RmvOGD7VA@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <o2gkjv$4uj$1@blaine.gmane.org>
 <CACac1F-iYjLKvs5+=uwk68MrBYnSV_5na-0S389g6RmvOGD7VA@mail.gmail.com>
Message-ID: <CAN8d9g=TR=3U9LtT9_LLOtTx0E2F8A=MWwn2tza7NadwYf3_dQ@mail.gmail.com>

Paul Moore <p.f.moore at gmail.com> schrieb am Sa., 10. Dez. 2016 um 11:38 Uhr:

> Someone has raised an issue against the project at
> https://github.com/naftaliharris/python2.8/issues/47 We should
> probably see what the project owner's response to that is.
>

That would be me, hi.

I really hope this is resolved in a constructive way, without resorting to
lawyers sending cease-and-desist letters. So yeah, please let?s wait!

Also interesting what cropped up as first comment. People seem to be really
emotional about this. But no matter how the transition experience could
have been improved: 8 years are a long time to transition your stuff if you
accept the fact that a transition is necessary. Sorry for bringing this up,
that?s not the right place to discuss this.

Best, Philipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/ee94f9ea/attachment.html>

From wes.turner at gmail.com  Sat Dec 10 13:42:24 2016
From: wes.turner at gmail.com (Wes Turner)
Date: Sat, 10 Dec 2016 12:42:24 -0600
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
Message-ID: <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>

On Saturday, December 10, 2016, M.-A. Lemburg <mal at egenix.com> wrote:

> On 10.12.2016 10:05, David Mertz wrote:
> > I'm forwarding this to the PSF Trademarks committee. If there is a
> > violation, it's a misuse of trademark, not copyright on the code which
> has
> > the Python license stack.
> >
> > I'm on that committee and agree this is improper use. Let's see what
> other
> > members think.
>
> Our trademark policy for the word mark Python does allow
> for such use and without asking for permissions:
>
> https://www.python.org/psf/trademarks/
> """
> ...
> As such, stating accurately that software is written in the Python
> programming language, that it is compatible with the Python programming
> language, or that it contains the Python programming language, is always
> allowed. In those cases, you may use the word "Python" or the unaltered
> logos to indicate this, without our prior approval. This is true both
> for non-commercial and commercial uses.
>
> This clause overrides other clauses of this policy.
> ...
> """
>
> and this is on purpose, since Python is BSD software which
> anyone can use, modify, fork, etc.
>
>
So, otherwise everyone who forks for any reason is in violation of the
trademark policy?


> The fork also contains a list of differences compared to
> Python 2.7 as shipped by the PSF, so the license is fulfilled
> as well:
>
> https://github.com/naftaliharris/python2.8


This could be easier (and linked-to):
https://github.com/naftaliharris/python2.8/compare/master...python/cpython:2.7

https://github.com/python/cpython/compare/2.7...naftaliharris/python2.8:master

git rebase -i?


> All that said, I still believe we should contact the author
> and ask for a name change to make it clear to our users that
> the PSF is not endorsing this fork, nor does it provide
> support for it:


>From README.md: "Python 2.8 is licensed under the Python Software License,
(see the LICENSE file for details). This is not an official Python release;
see PEP 404 <https://www.python.org/dev/peps/pep-0404/>."

https://www.python.org/dev/peps/pep-0404/


>
> https://github.com/naftaliharris
> https://www.naftaliharris.com/contact/
>
> Regardless of the name, it'll be interesting to see whether
> there's demand for such a fork. Without a website, binaries
> to download, documentation, etc. it's still in the very early
> stages.



What could've been! (Intimidating an incompatible fork would be somewhat
hypocritical at this point).

Do you really think it appropriate to demand a name change because you
disagree with the fork's backward compatibility?

What a useful list of new features (and potential backports), IMHO

https://pypi.python.org/pypi/backports

https://github.com/naftaliharris/python2.8/compare/asyncio


> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Dec 10 2016)
> >>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
> >>> Python Database Interfaces ...           http://products.egenix.com/
> >>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
> ________________________________________________________________________
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>            Registered at Amtsgericht Duesseldorf: HRB 46611
>                http://www.egenix.com/company/contact/
>                       http://www.malemburg.com/
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org <javascript:;>
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> wes.turner%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/731ce956/attachment.html>

From wes.turner at gmail.com  Sat Dec 10 13:47:10 2016
From: wes.turner at gmail.com (Wes Turner)
Date: Sat, 10 Dec 2016 12:47:10 -0600
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
Message-ID: <CACfEFw9WbVgOPh3S4YDN_6riri4X9YpdHZ=UQrKnnXVw3DdvyQ@mail.gmail.com>

s/python/pythone28000/g. There; now I can read the diff's.

On Saturday, December 10, 2016, Wes Turner <wes.turner at gmail.com> wrote:

>
>
> On Saturday, December 10, 2016, M.-A. Lemburg <mal at egenix.com
> <javascript:_e(%7B%7D,'cvml','mal at egenix.com');>> wrote:
>
>> On 10.12.2016 10:05, David Mertz wrote:
>> > I'm forwarding this to the PSF Trademarks committee. If there is a
>> > violation, it's a misuse of trademark, not copyright on the code which
>> has
>> > the Python license stack.
>> >
>> > I'm on that committee and agree this is improper use. Let's see what
>> other
>> > members think.
>>
>> Our trademark policy for the word mark Python does allow
>> for such use and without asking for permissions:
>>
>> https://www.python.org/psf/trademarks/
>> """
>> ...
>> As such, stating accurately that software is written in the Python
>> programming language, that it is compatible with the Python programming
>> language, or that it contains the Python programming language, is always
>> allowed. In those cases, you may use the word "Python" or the unaltered
>> logos to indicate this, without our prior approval. This is true both
>> for non-commercial and commercial uses.
>>
>> This clause overrides other clauses of this policy.
>> ...
>> """
>>
>> and this is on purpose, since Python is BSD software which
>> anyone can use, modify, fork, etc.
>>
>>
> So, otherwise everyone who forks for any reason is in violation of the
> trademark policy?
>
>
>> The fork also contains a list of differences compared to
>> Python 2.7 as shipped by the PSF, so the license is fulfilled
>> as well:
>>
>> https://github.com/naftaliharris/python2.8
>
>
> This could be easier (and linked-to):
> https://github.com/naftaliharris/python2.8/compare/master...python/
> cpython:2.7
>
> https://github.com/python/cpython/compare/2.7...
> naftaliharris/python2.8:master
>
> git rebase -i?
>
>
>> All that said, I still believe we should contact the author
>> and ask for a name change to make it clear to our users that
>> the PSF is not endorsing this fork, nor does it provide
>> support for it:
>
>
> From README.md: "Python 2.8 is licensed under the Python Software License,
> (see the LICENSE file for details). This is not an official Python release;
> see PEP 404 <https://www.python.org/dev/peps/pep-0404/>."
>
> https://www.python.org/dev/peps/pep-0404/
>
>
>>
>> https://github.com/naftaliharris
>> https://www.naftaliharris.com/contact/
>>
>> Regardless of the name, it'll be interesting to see whether
>> there's demand for such a fork. Without a website, binaries
>> to download, documentation, etc. it's still in the very early
>> stages.
>
>
>
> What could've been! (Intimidating an incompatible fork would be somewhat
> hypocritical at this point).
>
> Do you really think it appropriate to demand a name change because you
> disagree with the fork's backward compatibility?
>
> What a useful list of new features (and potential backports), IMHO
>
> https://pypi.python.org/pypi/backports
>
> https://github.com/naftaliharris/python2.8/compare/asyncio
>
>
>> --
>> Marc-Andre Lemburg
>> eGenix.com
>>
>> Professional Python Services directly from the Experts (#1, Dec 10 2016)
>> >>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>> >>> Python Database Interfaces ...           http://products.egenix.com/
>> >>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
>> ________________________________________________________________________
>>
>> ::: We implement business ideas - efficiently in both time and costs :::
>>
>>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>>            Registered at Amtsgericht Duesseldorf: HRB 46611
>>                http://www.egenix.com/company/contact/
>>                       http://www.malemburg.com/
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.
>> turner%40gmail.com
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/f854eecc/attachment.html>

From wes.turner at gmail.com  Sat Dec 10 14:03:41 2016
From: wes.turner at gmail.com (Wes Turner)
Date: Sat, 10 Dec 2016 13:03:41 -0600
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CACfEFw9WbVgOPh3S4YDN_6riri4X9YpdHZ=UQrKnnXVw3DdvyQ@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CACfEFw9WbVgOPh3S4YDN_6riri4X9YpdHZ=UQrKnnXVw3DdvyQ@mail.gmail.com>
Message-ID: <CACfEFw861z3389OQMffqCB8rU6mDbe7RYMBjRjKfU0Xt1OjP=Q@mail.gmail.com>

On Saturday, December 10, 2016, Wes Turner <wes.turner at gmail.com> wrote:

> s/python/pythone28000/g. There; now I can read the diff's.
>
> On Saturday, December 10, 2016, Wes Turner <wes.turner at gmail.com
> <javascript:_e(%7B%7D,'cvml','wes.turner at gmail.com');>> wrote:
>
>>
>>
>> On Saturday, December 10, 2016, M.-A. Lemburg <mal at egenix.com> wrote:
>>
>>> On 10.12.2016 10:05, David Mertz wrote:
>>> > I'm forwarding this to the PSF Trademarks committee. If there is a
>>> > violation, it's a misuse of trademark, not copyright on the code which
>>> has
>>> > the Python license stack.
>>> >
>>> > I'm on that committee and agree this is improper use. Let's see what
>>> other
>>> > members think.
>>>
>>> Our trademark policy for the word mark Python does allow
>>> for such use and without asking for permissions:
>>>
>>> https://www.python.org/psf/trademarks/
>>> """
>>> ...
>>> As such, stating accurately that software is written in the Python
>>> programming language, that it is compatible with the Python programming
>>> language, or that it contains the Python programming language, is always
>>> allowed. In those cases, you may use the word "Python" or the unaltered
>>> logos to indicate this, without our prior approval. This is true both
>>> for non-commercial and commercial uses.
>>>
>>> This clause overrides other clauses of this policy.
>>> ...
>>> """
>>>
>>> and this is on purpose, since Python is BSD software which
>>> anyone can use, modify, fork, etc.
>>>
>>>
>> So, otherwise everyone who forks for any reason is in violation of the
>> trademark policy?
>>
>>
>>> The fork also contains a list of differences compared to
>>> Python 2.7 as shipped by the PSF, so the license is fulfilled
>>> as well:
>>>
>>> https://github.com/naftaliharris/python2.8
>>
>>
>> This could be easier (and linked-to):
>> https://github.com/naftaliharris/python2.8/compare/master...
>> python/cpython:2.7
>>
>> https://github.com/python/cpython/compare/2.7...naftaliharri
>> s/python2.8:master
>>
>> git rebase -i?
>>
>>
>>> All that said, I still believe we should contact the author
>>> and ask for a name change to make it clear to our users that
>>> the PSF is not endorsing this fork, nor does it provide
>>> support for it:
>>
>>
>> From README.md: "Python 2.8 is licensed under the Python Software
>> License, (see the LICENSE file for details). This is not an official Python
>> release; see PEP 404 <https://www.python.org/dev/peps/pep-0404/>."
>>
>> https://www.python.org/dev/peps/pep-0404/
>>
>
Helpfully, what could this also say?

- Not supported
- Not approved
- Links to cpython hg and git
-


>
>>
>>>
>>> https://github.com/naftaliharris
>>> https://www.naftaliharris.com/contact/
>>>
>>> Regardless of the name, it'll be interesting to see whether
>>> there's demand for such a fork. Without a website, binaries
>>> to download, documentation, etc. it's still in the very early
>>> stages.
>>
>>
>>
>> What could've been! (Intimidating an incompatible fork would be somewhat
>> hypocritical at this point).
>>
>> Do you really think it appropriate to demand a name change because you
>> disagree with the fork's backward compatibility?
>>
>> What a useful list of new features (and potential backports), IMHO
>>
>> https://pypi.python.org/pypi/backports
>>
>> https://github.com/naftaliharris/python2.8/compare/asyncio
>>
>>
>>> --
>>> Marc-Andre Lemburg
>>> eGenix.com
>>>
>>> Professional Python Services directly from the Experts (#1, Dec 10 2016)
>>> >>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> >>> Python Database Interfaces ...           http://products.egenix.com/
>>> >>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
>>> ________________________________________________________________________
>>>
>>> ::: We implement business ideas - efficiently in both time and costs :::
>>>
>>>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>>>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>>>            Registered at Amtsgericht Duesseldorf: HRB 46611
>>>                http://www.egenix.com/company/contact/
>>>                       http://www.malemburg.com/
>>>
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe: https://mail.python.org/mailma
>>> n/options/python-dev/wes.turner%40gmail.com
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/12cd3a67/attachment-0001.html>

From mertz at gnosis.cx  Sat Dec 10 16:05:26 2016
From: mertz at gnosis.cx (David Mertz)
Date: Sat, 10 Dec 2016 13:05:26 -0800
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CAP7+vJLTTEx4A_BWR75P3aOnfPSY2iafk5Fw2rUCSFyq6EnfrA@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CAO-CpELoCX8wy6NsRNoq5pVT13kPuVDypSzkaz0mnbfEhNGFCw@mail.gmail.com>
 <CAP7+vJLTTEx4A_BWR75P3aOnfPSY2iafk5Fw2rUCSFyq6EnfrA@mail.gmail.com>
Message-ID: <CAEbHw4aPDPtzmjsyudGOoi1x_tjbU=OaeF=JvanOFTUOcQA95w@mail.gmail.com>

I am more worried about the confusion than Guido is. I agree that this will
remain a toy project. But as someone who trains scientist to use Python and
consults with large companies with large Python 2 codebases, I think the
very existence of a thing called "Python 2.8" will serve as a pretext for
managers to drag their feet further on migration plans... Ultimately
hurting their own business, but that becomes harder to explain.


On Dec 10, 2016 8:07 AM, "Guido van Rossum" <guido at python.org> wrote:

While I think the name is misleading and in violation of PSF policy and/or
license, I am not too worried about this. I expect it will be tough to port
libraries from Python 3 reliably because it is not true Python 3 (e.g.
str/bytes). So then it's just a toy. Who cares about having 'async def' if
there's no backport of asyncio?

-- 
--Guido van Rossum (python.org/~guido)

_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/
mertz%40gnosis.cx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/3a6dc87a/attachment.html>

From mertz at gnosis.cx  Sat Dec 10 16:22:06 2016
From: mertz at gnosis.cx (David Mertz)
Date: Sat, 10 Dec 2016 13:22:06 -0800
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
Message-ID: <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>

On Dec 10, 2016 10:42 AM, "Wes Turner" <wes.turner at gmail.com> wrote:

and this is on purpose, since Python is BSD software which
> anyone can use, modify, fork, etc.
>

So, otherwise everyone who forks for any reason is in violation of the
trademark policy?


The trademark issue has nothing to do with the code copyright or forking.
PyPy, Brython, IronPython, Jython are all distinct code bases that
implement (mostly) the same language semantics. Probably all of those use
some code from CPython, but even if some other implementation used zero
common code it wouldn't matter.

None of those projects are allowed to call their next release "Python 2.8"
either, regardless of precise semantics implemented. I could call some
project Foothon 2.8 if I wanted, because it wouldn't invite confusion about
official status for the PDF.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/0d7e4456/attachment.html>

From gvanrossum at gmail.com  Sat Dec 10 17:26:33 2016
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Sat, 10 Dec 2016 14:26:33 -0800
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
Message-ID: <CAP7+vJKVVY7RHBUY0rc6_fu-Y8EudmDn-AHMJPK6SocgeAbCMA@mail.gmail.com>

FWIW the author is amenable to renaming, so that's the end for me. See the
issue referenced earlier in the thread.

--Guido (mobile)

On Dec 10, 2016 1:24 PM, "David Mertz" <mertz at gnosis.cx> wrote:

>
>
> On Dec 10, 2016 10:42 AM, "Wes Turner" <wes.turner at gmail.com> wrote:
>
> and this is on purpose, since Python is BSD software which
>> anyone can use, modify, fork, etc.
>>
>
> So, otherwise everyone who forks for any reason is in violation of the
> trademark policy?
>
>
> The trademark issue has nothing to do with the code copyright or forking.
> PyPy, Brython, IronPython, Jython are all distinct code bases that
> implement (mostly) the same language semantics. Probably all of those use
> some code from CPython, but even if some other implementation used zero
> common code it wouldn't matter.
>
> None of those projects are allowed to call their next release "Python 2.8"
> either, regardless of precise semantics implemented. I could call some
> project Foothon 2.8 if I wanted, because it wouldn't invite confusion about
> official status for the PDF.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/71a06c8c/attachment.html>

From wes.turner at gmail.com  Sat Dec 10 17:28:08 2016
From: wes.turner at gmail.com (Wes Turner)
Date: Sat, 10 Dec 2016 16:28:08 -0600
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
Message-ID: <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>

So forks with modules added or removed cannot be called Python? Forks
without the blessing of the PSF cannot be called Python? That's really not
open source.

- https://cloud.google.com/appengine/docs/python/python25/diff27
- "PEP: Distributing a Subset of the Standard Library" https://
groups.google.com/forum/m/#!topic/python-ideas/DP5OeJu94eI
  - https://www.python.org/dev/peps/pep-0534/

https://www.python.org/psf/trademarks/

I think trying to maintain a fork without support from the community is a
bad idea for a number of reasons:

- How quickly are vulnerability fixes to be backported? (if ever)
- Duplication of effort
- Fragmentation

But as an academic exercise, what a useful way to review both Python 2 and
3.

But it's very common for folks to apply patches and still call the package
and the binary 'python' (with the same version number):

- https://github.com/ContinuumIO/anaconda-recipes/tree/master/python-2.7
*.patch
- https://apps.fedoraproject.org/packages/python-devel/sources/
- http://packages.ubuntu.com/source/xenial/python-defaults
- Distribution XYZ redistribution [Python 2.7.12]
- Unmerged development forks

With these license and trademark policies, does unblessed fork need to:

- change their project name to not include the word "python"
- change the binary name so that simple PATH changes don't work
- clutter their diffs with noise
- use an arbitrary version number

Where is that stated?

Are all unmerged development forks / branches in violation of said policy?

The fork in immediate question is not backwards-compatible with Python 2.

It's clear that the PSF position is that there will never be an official
Python 2.8; and that development time and effort are better spent porting
things to the backwards-incompatible Python 3.4/3.6.



On Saturday, December 10, 2016, David Mertz <mertz at gnosis.cx> wrote:

>
>
> On Dec 10, 2016 10:42 AM, "Wes Turner" <wes.turner at gmail.com
> <javascript:_e(%7B%7D,'cvml','wes.turner at gmail.com');>> wrote:
>
> and this is on purpose, since Python is BSD software which
>> anyone can use, modify, fork, etc.
>>
>
> So, otherwise everyone who forks for any reason is in violation of the
> trademark policy?
>
>
> The trademark issue has nothing to do with the code copyright or forking.
> PyPy, Brython, IronPython, Jython are all distinct code bases that
> implement (mostly) the same language semantics. Probably all of those use
> some code from CPython, but even if some other implementation used zero
> common code it wouldn't matter.
>
> None of those projects are allowed to call their next release "Python 2.8"
> either, regardless of precise semantics implemented. I could call some
> project Foothon 2.8 if I wanted, because it wouldn't invite confusion about
> official status for the PDF.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/d2e5d623/attachment.html>

From tjreedy at udel.edu  Sat Dec 10 22:11:18 2016
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 10 Dec 2016 22:11:18 -0500
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
Message-ID: <o2ig4i$190$1@blaine.gmane.org>

On 12/10/2016 5:28 PM, Wes Turner wrote:
>
> So forks with modules added or removed cannot be called Python?

Distributions that make parts of the stdlib optional are not forks.  The 
PSF Windows installer makes tcl/tk, tkinter, IDLE, and turtle? modules 
optional.

Distributions that package additional modules with unmodified python x.y 
are also, to me, not forks.  But they are always given other names for 
the combined package.  ActiveState Python, Enthought Python, Anaconda 
(Python).  Separate names for separate distribution allow people to 
search for particular distributions and discuss questions like "Which 
distribution is best for purpose A?"

I am sure that ActiveState Software Inc. would not be happy if you 
distributed Python + selected modules and called it 'ActiveState Python' 
;-),  Some for other distributions.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Sat Dec 10 22:22:40 2016
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 10 Dec 2016 22:22:40 -0500
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <o2ig4i$190$1@blaine.gmane.org>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
 <o2ig4i$190$1@blaine.gmane.org>
Message-ID: <o2igps$ufs$1@blaine.gmane.org>

On 12/10/2016 10:11 PM, Terry Reedy wrote:
> On 12/10/2016 5:28 PM, Wes Turner wrote:
>>
>> So forks with modules added or removed cannot be called Python?
>
> Distributions that make parts of the stdlib optional are not forks.  The
> PSF Windows installer makes tcl/tk, tkinter, IDLE, and turtle? modules
> optional.
>
> Distributions that package additional modules with unmodified python x.y
> are also, to me, not forks.  But they are always given other names for
> the combined package.  ActiveState Python, Enthought Python, Anaconda
> (Python).  Separate names for separate distribution allow people to
> search for particular distributions and discuss questions like "Which
> distribution is best for purpose A?"
>
> I am sure that ActiveState Software Inc. would not be happy if you
> distributed Python + selected modules and called it 'ActiveState Python'
> ;-),  Some for other distributions.

I just found the small gray print: "? 2016 ActiveState Software Inc. All 
rights reserved. ActiveState?, Komodo?, ActiveState Perl Dev Kit?, 
ActiveState Tcl Dev Kit?, ActivePerl?, ActivePython?, and ActiveTcl? are 
registered trademarks of ActiveState."

-- 
Terry Jan Reedy



From wes.turner at gmail.com  Sat Dec 10 22:23:15 2016
From: wes.turner at gmail.com (Wes Turner)
Date: Sat, 10 Dec 2016 21:23:15 -0600
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <o2ig4i$190$1@blaine.gmane.org>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
 <o2ig4i$190$1@blaine.gmane.org>
Message-ID: <CACfEFw9fVMN0Uuy+rP-bbCEm3gX9CSk2bWBL2zgBhGV_pJZZSg@mail.gmail.com>

On Saturday, December 10, 2016, Terry Reedy <tjreedy at udel.edu> wrote:

> On 12/10/2016 5:28 PM, Wes Turner wrote:
>
>>
>> So forks with modules added or removed cannot be called Python?
>>
>
> Distributions that make parts of the stdlib optional are not forks.  The
> PSF Windows installer makes tcl/tk, tkinter, IDLE, and turtle? modules
> optional.
>
> Distributions that package additional modules with unmodified python x.y
> are also, to me, not forks.  But they are always given other names for the
> combined package.  ActiveState Python, Enthought Python, Anaconda
> (Python).  Separate names for separate distribution allow people to search
> for particular distributions and discuss questions like "Which distribution
> is best for purpose A?"
>
> I am sure that ActiveState Software Inc. would not be happy if you
> distributed Python + selected modules and called it 'ActiveState Python'
> ;-),  Some for other distributions.


So there needs to be a prefix or a suffix?

  [prefix] Python
  Python [suffix]


>
> --
> Terry Jan Reedy
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.
> turner%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/bc20983d/attachment.html>

From wes.turner at gmail.com  Sat Dec 10 22:25:55 2016
From: wes.turner at gmail.com (Wes Turner)
Date: Sat, 10 Dec 2016 21:25:55 -0600
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CACfEFw9fVMN0Uuy+rP-bbCEm3gX9CSk2bWBL2zgBhGV_pJZZSg@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
 <o2ig4i$190$1@blaine.gmane.org>
 <CACfEFw9fVMN0Uuy+rP-bbCEm3gX9CSk2bWBL2zgBhGV_pJZZSg@mail.gmail.com>
Message-ID: <CACfEFw_9mzT=UBx_3tgBzY7a+OvMBoDOFG_83jedXLCsJJfm2w@mail.gmail.com>

On Saturday, December 10, 2016, Wes Turner <wes.turner at gmail.com> wrote:

>
>
> On Saturday, December 10, 2016, Terry Reedy <tjreedy at udel.edu
> <javascript:_e(%7B%7D,'cvml','tjreedy at udel.edu');>> wrote:
>
>> On 12/10/2016 5:28 PM, Wes Turner wrote:
>>
>>>
>>> So forks with modules added or removed cannot be called Python?
>>>
>>
>> Distributions that make parts of the stdlib optional are not forks.  The
>> PSF Windows installer makes tcl/tk, tkinter, IDLE, and turtle? modules
>> optional.
>>
>> Distributions that package additional modules with unmodified python x.y
>> are also, to me, not forks.  But they are always given other names for the
>> combined package.  ActiveState Python, Enthought Python, Anaconda
>> (Python).  Separate names for separate distribution allow people to search
>> for particular distributions and discuss questions like "Which distribution
>> is best for purpose A?"
>>
>> I am sure that ActiveState Software Inc. would not be happy if you
>> distributed Python + selected modules and called it 'ActiveState Python'
>> ;-),  Some for other distributions.
>
>
> So there needs to be a prefix or a suffix?
>
>   [prefix] Python
>   Python [suffix]
>

https://github.com/ContinuumIO/anaconda-recipes/blob/master/python-2.7/version.patch

What is the objective here?


>
>>
>> --
>> Terry Jan Reedy
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.turne
>> r%40gmail.com
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/72f2b01e/attachment-0001.html>

From wes.turner at gmail.com  Sat Dec 10 22:49:05 2016
From: wes.turner at gmail.com (Wes Turner)
Date: Sat, 10 Dec 2016 21:49:05 -0600
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CACfEFw_9mzT=UBx_3tgBzY7a+OvMBoDOFG_83jedXLCsJJfm2w@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
 <o2ig4i$190$1@blaine.gmane.org>
 <CACfEFw9fVMN0Uuy+rP-bbCEm3gX9CSk2bWBL2zgBhGV_pJZZSg@mail.gmail.com>
 <CACfEFw_9mzT=UBx_3tgBzY7a+OvMBoDOFG_83jedXLCsJJfm2w@mail.gmail.com>
Message-ID: <CACfEFw-oyD2CyHJZvnty5B-AqK8N5uumL6DczRNjH=mM-6=vZw@mail.gmail.com>

...

- https://twitter.com/VanL/status/807697111886286852
- From https://news.ycombinator.com/item?id=13147972 :

```
(Replying to the top-ranked comment so that as many people as possible see
it)

While I wish Naftali well in his efforts - I have a private Python-derived
language myself! - this is not "Python 2.8." For trademark purposes,
"Python" is only what is released or endorsed by the PSF.

We have already reached out to Naftali and asked him to change the name of
his project and update this blog post accordingly.

Obviously, though, this is someone who cares a lot about Python, so let's
be sure not to rain down on him with a lot of scorn; I admire that he was
willing to sit down and 'scratch his own itch.'

Source: I am the General Counsel of the PSF.
```

On Saturday, December 10, 2016, Wes Turner <wes.turner at gmail.com> wrote:

>
>
> On Saturday, December 10, 2016, Wes Turner <wes.turner at gmail.com
> <javascript:_e(%7B%7D,'cvml','wes.turner at gmail.com');>> wrote:
>
>>
>>
>> On Saturday, December 10, 2016, Terry Reedy <tjreedy at udel.edu> wrote:
>>
>>> On 12/10/2016 5:28 PM, Wes Turner wrote:
>>>
>>>>
>>>> So forks with modules added or removed cannot be called Python?
>>>>
>>>
>>> Distributions that make parts of the stdlib optional are not forks.  The
>>> PSF Windows installer makes tcl/tk, tkinter, IDLE, and turtle? modules
>>> optional.
>>>
>>> Distributions that package additional modules with unmodified python x.y
>>> are also, to me, not forks.  But they are always given other names for the
>>> combined package.  ActiveState Python, Enthought Python, Anaconda
>>> (Python).  Separate names for separate distribution allow people to search
>>> for particular distributions and discuss questions like "Which distribution
>>> is best for purpose A?"
>>>
>>> I am sure that ActiveState Software Inc. would not be happy if you
>>> distributed Python + selected modules and called it 'ActiveState Python'
>>> ;-),  Some for other distributions.
>>
>>
>> So there needs to be a prefix or a suffix?
>>
>>   [prefix] Python
>>   Python [suffix]
>>
>
> https://github.com/ContinuumIO/anaconda-recipes/blob/master/python-2.7/
> version.patch
>
> What is the objective here?
>
>
>>
>>>
>>> --
>>> Terry Jan Reedy
>>>
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe: https://mail.python.org/mailma
>>> n/options/python-dev/wes.turner%40gmail.com
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161210/79f7fdda/attachment.html>

From ncoghlan at gmail.com  Sun Dec 11 08:41:07 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 11 Dec 2016 23:41:07 +1000
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CACfEFw9fVMN0Uuy+rP-bbCEm3gX9CSk2bWBL2zgBhGV_pJZZSg@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
 <o2ig4i$190$1@blaine.gmane.org>
 <CACfEFw9fVMN0Uuy+rP-bbCEm3gX9CSk2bWBL2zgBhGV_pJZZSg@mail.gmail.com>
Message-ID: <CADiSq7fqsdUbruf9jV1tKHWLxjyQrYiCduAbTs7xXsLX-Bu-Zg@mail.gmail.com>

On 11 December 2016 at 13:23, Wes Turner <wes.turner at gmail.com> wrote:
> On Saturday, December 10, 2016, Terry Reedy <tjreedy at udel.edu> wrote:
>> On 12/10/2016 5:28 PM, Wes Turner wrote:
>>> So forks with modules added or removed cannot be called Python?
>>
>> Distributions that make parts of the stdlib optional are not forks.  The
>> PSF Windows installer makes tcl/tk, tkinter, IDLE, and turtle? modules
>> optional.
>>
>> Distributions that package additional modules with unmodified python x.y
>> are also, to me, not forks.  But they are always given other names for the
>> combined package.  ActiveState Python, Enthought Python, Anaconda (Python).
>> Separate names for separate distribution allow people to search for
>> particular distributions and discuss questions like "Which distribution is
>> best for purpose A?"
>>
>> I am sure that ActiveState Software Inc. would not be happy if you
>> distributed Python + selected modules and called it 'ActiveState Python'
>> ;-),  Some for other distributions.
>
> So there needs to be a prefix or a suffix?
>
>   [prefix] Python
>   Python [suffix]

There needs to be an avoidance of confusion, such that folks are aware
of what's being published directly under the PSF's authority (by way
of python-dev's selected release managers), and what's being modified
by other people.

Linux distros probably diverge the furthest out of anyone distributing
binaries that are still recognised as a third party build of CPython,
such that the Linux system Python releases are more properly called
"<distro> Python" rather than just Python. However, distro packaging
formats are also generally designed to clearly distinguish between the
unmodified upstream source code and any distro-specific patches, so
the likelihood of confusion is low (in a legal sense).

As Terry notes, other redistributors are similar (just with fewer
patches in most cases) - providing pre-built, potentially patched,
binaries is standard practice, but the end result is branded as
something *other* than an unqualified "Python" release.

Alternative *implementations* that embed the word mark in their name,
like MicroPython and IronPython, can diverge even further, and will
often mix and match the specifics of which versions they support (e.g.
if their base version is 3.X, and a neat feature comes out in 3.X+2,
they're free to add that if they want to do so, even if there are
still other features from 3.X+1 that they're still working on).

The simplest option from a legal perspective is for folks to use a
clearly distinct name (e.g. PyPy, Jython, Cython, Pyjion, Numba, VOC,
Batavia, Mython), as then the question of appropriate use of the
"Python" word mark doesn't even come up - it only gets used in a
nominative sense (i.e. "this is a Python implementation" or "this is a
Python superset"), which is always OK.

In this particular case, there just happened to be an obvious name for
the project (courtesy of PEP 404) that was nevertheless problematic on
the "potential for confusion" trademark front. Fortunately, there have
been a few interesting alternative name suggestions on the GitHub
issue, so once Naftali picks one that the PSF agrees is fine, the
issue will be resolved.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From turnbull.stephen.fw at u.tsukuba.ac.jp  Mon Dec 12 03:40:37 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Mon, 12 Dec 2016 17:40:37 +0900
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
Message-ID: <22606.25221.667266.206330@turnbull.sk.tsukuba.ac.jp>

Wes Turner writes:

 > So forks with modules added or removed cannot be called Python? 
 > Forks without the blessing of the PSF cannot be called Python? 
 > That's really not open source.

Of course it is.  The source is open and free.

But that's not what is in play here.  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 and promises
(or lack thereof) of support are valid, and to avoid gratuitous claims
against the PSF by people who take use of the trademark to mean that
it's PSF-sponsored or at least PSF-sanctioned.  That is a perfectly
reasonable way for third parties to behave, since it's the PSF's
responsibility to defend its trademark.

Note that trademark is unlike patent and copyright, which are
unconditional whether or not infringers have been punished before.
OTOH, trademark must be defended, because when the reputational
capital depreciates too much US courts will refuse to enforce
trademark.  We say trademark protection is "use it or lose it".

It's a moot point here because Guido and Van are satisfied with the
response of the author so far.  But I fear that since Guido declared
that no "Python 2.8" will ever exist, failure to object to that name
would be all the evidence a court would need to decide that we don't
care enough about the trademark, making it that much more difficult to
enforce in the future.  (IANAL and it's been ~15 years since I've
looked at law or cases on trademark, but I suppose it's still true.)

Exactly how lenient an open source project can be with naming of
forks, I don't know.  I would hope that courts would not look amiss at
the common practice of letting distros that patch Python or break out
the stdlib or docs into a separate package call their package
"python".  But you'd have to ask a real lawyer and maybe find a court
case on that.

Steve

From wes.turner at gmail.com  Mon Dec 12 04:10:09 2016
From: wes.turner at gmail.com (Wes Turner)
Date: Mon, 12 Dec 2016 03:10:09 -0600
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <22606.25221.667266.206330@turnbull.sk.tsukuba.ac.jp>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
 <22606.25221.667266.206330@turnbull.sk.tsukuba.ac.jp>
Message-ID: <CACfEFw_Z6c0bqN_XRwvDTb1fho2Gq1h+yvcQkN0fjZMoK112NA@mail.gmail.com>

[Continuing to play devil's advocate for the sake of clarification]

On Mon, Dec 12, 2016 at 2:40 AM, Stephen J. Turnbull <turnbull.stephen.fw at u.
tsukuba.ac.jp> wrote:

> Wes Turner writes:
>
>  > So forks with modules added or removed cannot be called Python?
>  > Forks without the blessing of the PSF cannot be called Python?
>  > That's really not open source.
>
> Of course it is.  The source is open and free.
>
> But that's not what is in play here.  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:

https://www.python.org/downloads/

Other [prefix] Python [suffix] distributions are not officially QA'd by the
core Python team.


> and promises
> (or lack thereof) of support are valid,


https://docs.python.org/3/license.html#terms-and-
conditions-for-accessing-or-otherwise-using-python

```
4. PSF is making Python 3.5.2 available to Licensee on an "AS IS" basis.
   PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED.  BY WAY
OF
   EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY
REPRESENTATION OR
   WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR
THAT THE
   USE OF PYTHON 3.5.2 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS.

5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON 3.5.2
   FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A
RESULT OF
   MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 3.5.2, OR ANY
DERIVATIVE
   THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.
```

>
> and to avoid gratuitous claims
> against the PSF by people who take use of the trademark to mean that
> it's PSF-sponsored or at least PSF-sanctioned.


These are the PSF releases: https://www.python.org/downloads/

There are many redistributions with various patches applied.


>   That is a perfectly
> reasonable way for third parties to behave, since it's the PSF's
> responsibility to defend its trademark.
>
> Note that trademark is unlike patent and copyright, which are
> unconditional whether or not infringers have been punished before.
> OTOH, trademark must be defended, because when the reputational
> capital depreciates too much US courts will refuse to enforce
> trademark.  We say trademark protection is "use it or lose it".
>
> It's a moot point here because Guido and Van are satisfied with the
> response of the author so far.  But I fear that since Guido declared
> that no "Python 2.8" will ever exist, failure to object to that name
> would be all the evidence a court would need to decide that we don't
> care enough about the trademark, making it that much more difficult to
> enforce in the future.  (IANAL and it's been ~15 years since I've
> looked at law or cases on trademark, but I suppose it's still true.)
>
> Exactly how lenient an open source project can be with naming of
> forks, I don't know.  I would hope that courts would not look amiss at
> the common practice of letting distros that patch Python or break out
> the stdlib or docs into a separate package call their package
> "python".  But you'd have to ask a real lawyer and maybe find a court
> case on that.
>

There's really a "ship of theseus" argument: it is defacto standard
practice for downstream distributions to distribute modified copies of
Python while retaining the name Python. How extensive those patches are is
likely irrelevant to a trademark dispute (of which there is none here).

IIUC, when a developer forks (e.g. clicks "fork" w/
github.com/python/cpython), there is still no need to change the repository
name.


>
> Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161212/13fe5551/attachment.html>

From steve at pearwood.info  Mon Dec 12 05:53:57 2016
From: steve at pearwood.info (Steven D'Aprano)
Date: Mon, 12 Dec 2016 21:53:57 +1100
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CACfEFw_Z6c0bqN_XRwvDTb1fho2Gq1h+yvcQkN0fjZMoK112NA@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
 <22606.25221.667266.206330@turnbull.sk.tsukuba.ac.jp>
 <CACfEFw_Z6c0bqN_XRwvDTb1fho2Gq1h+yvcQkN0fjZMoK112NA@mail.gmail.com>
Message-ID: <20161212105356.GZ3365@ando.pearwood.info>

On Mon, Dec 12, 2016 at 03:10:09AM -0600, Wes Turner wrote:
> [Continuing to play devil's advocate for the sake of clarification]

Clarification of *what* exactly? You don't seem to be asking any 
questions, just making statements.

If you have a concrete, specific question, please ask it. If its a 
general question, you can ask it too, but don't be surprised if the 
answer is "it depends on the specific circumstances".


-- 
Steve

From burkhardameier at gmail.com  Mon Dec 12 07:15:52 2016
From: burkhardameier at gmail.com (Burkhard Meier)
Date: Mon, 12 Dec 2016 04:15:52 -0800
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <20161212105356.GZ3365@ando.pearwood.info>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
 <22606.25221.667266.206330@turnbull.sk.tsukuba.ac.jp>
 <CACfEFw_Z6c0bqN_XRwvDTb1fho2Gq1h+yvcQkN0fjZMoK112NA@mail.gmail.com>
 <20161212105356.GZ3365@ando.pearwood.info>
Message-ID: <CACKxkAxXrSUp3vkHSWYugvyS_U0qpkGfek9ge3BpBVZv-LwNOw@mail.gmail.com>

~ Just upgrade to Python 3.6 and forget about this non~sense! ~

On Mon, Dec 12, 2016 at 2:53 AM, Steven D'Aprano <steve at pearwood.info>
wrote:

> On Mon, Dec 12, 2016 at 03:10:09AM -0600, Wes Turner wrote:
> > [Continuing to play devil's advocate for the sake of clarification]
>
> Clarification of *what* exactly? You don't seem to be asking any
> questions, just making statements.
>
> If you have a concrete, specific question, please ask it. If its a
> general question, you can ask it too, but don't be surprised if the
> answer is "it depends on the specific circumstances".
>
>
> --
> Steve
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> burkhardameier%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161212/9ba10cb2/attachment.html>

From ncoghlan at gmail.com  Mon Dec 12 08:18:30 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 12 Dec 2016 23:18:30 +1000
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CACfEFw_Z6c0bqN_XRwvDTb1fho2Gq1h+yvcQkN0fjZMoK112NA@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
 <22606.25221.667266.206330@turnbull.sk.tsukuba.ac.jp>
 <CACfEFw_Z6c0bqN_XRwvDTb1fho2Gq1h+yvcQkN0fjZMoK112NA@mail.gmail.com>
Message-ID: <CADiSq7fTVw2BaFmY+JjYhohUNivGE8nVnNi1CfvHobJ4ujpEGA@mail.gmail.com>

On 12 December 2016 at 19:10, Wes Turner <wes.turner at gmail.com> wrote:
> On Mon, Dec 12, 2016 at 2:40 AM, Stephen J. Turnbull
> <turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:
>> Exactly how lenient an open source project can be with naming of
>> forks, I don't know.  I would hope that courts would not look amiss at
>> the common practice of letting distros that patch Python or break out
>> the stdlib or docs into a separate package call their package
>> "python".  But you'd have to ask a real lawyer and maybe find a court
>> case on that.
>
> There's really a "ship of theseus" argument: it is defacto standard practice
> for downstream distributions to distribute modified copies of Python while
> retaining the name Python. How extensive those patches are is likely
> irrelevant to a trademark dispute (of which there is none here).

It absolutely *is* relevant, as is how diligent the redistributors are
in differentiating between the unmodified upstream project and the
patches we have applied post-release (rather than just posting the end
result without a clear audit trail). Distros don't do all that extra
work just for the fun of it - it's an essential part of keeping track
of who's ultimately responsible for which pieces in a way that's
transparent to recipients of the software. Ensuring we aren't taking
excessive liberties with the language definition is also one of the
reasons we sometimes seek explicit permission for deviations - it
documents that those particular changes still fit within the bounds of
what counts as "Python".

However, we've drifted well off-topic for python-dev now (the PSF's
management of the legal marks is handled by the Trademarks Comittee
and the PSF Board rather than python-dev), so if you'd like to learn
more about trademark law and how it applies to open source projects in
general, I'd suggest taking advantage of the extensive material
available online rather than posting further here (the history of the
Firefox/Iceweasel disagreement between Mozilla and Debian is a
particularly interesting case study).

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From annakoppad at gmail.com  Fri Dec  9 13:08:24 2016
From: annakoppad at gmail.com (Annapoornima Koppad)
Date: Fri, 9 Dec 2016 23:38:24 +0530
Subject: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
In-Reply-To: <CAMpsgwYWr_G3Oy66Xd3npXUK7Uds=GTLP94nLwXaDq0iYRa0eg@mail.gmail.com>
References: <CAMpsgwbHYAa_kshEBgZcZerywdMpV779P4jT4ncyiNPOdC1WJA@mail.gmail.com>
 <CAMpsgwYWr_G3Oy66Xd3npXUK7Uds=GTLP94nLwXaDq0iYRa0eg@mail.gmail.com>
Message-ID: <CAGmxLZ=NiJ01p-Mq1AM9LH=XeY4-_m9eMp3VaQZxCFa-bUZsXg@mail.gmail.com>

I am not sure, but soon, I will be a great fan of your work, once I get to
work on this!

Thank your for inspiring me to work on these stuff!

Best regards,
Annapoornima

On Fri, Dec 9, 2016 at 11:33 PM, Victor Stinner <victor.stinner at gmail.com>
wrote:

> 2016-12-09 18:46 GMT+01:00 Victor Stinner <victor.stinner at gmail.com>:
> > Last days, I patched functions of PyObject_CallFunction() family to
> > use internally fast calls.
> > (...)
> > http://bugs.python.org/issue28915
>
> Oh, I forgot to mention the performance results of these changes.
> Python slots are now a little bit faster. Extract of the issue:
> http://bugs.python.org/issue28915#msg282748
>
> Microbenchmark on a simple class with an __int__() method, call int(o):
> int(o): Median +- std dev: [ref] 239 ns +- 13 ns -> [patch] 219 ns +-
> 14 ns: 1.10x faster (-9%)
>
> Microbenchmark on a simple class with an __getitem__() method, call o[100]:
> o[100]: Median +- std dev: [ref] 211 ns +- 11 ns -> [patch] 172 ns +-
> 11 ns: 1.23x faster (-19%)
>
>
> Comparison between Python 2.7, 3.5, 3.7 and 3.7+patch, 3.5 is used as
> the reference:
>
> int(o)
> ======
>
> Median +- std dev: [3.5] 271 ns +- 15 ns -> [3.7] 239 ns +- 13 ns:
> 1.13x faster (-12%)
> Median +- std dev: [3.5] 271 ns +- 15 ns -> [patch] 219 ns +- 14 ns:
> 1.24x faster (-19%)
> Median +- std dev: [3.5] 271 ns +- 15 ns -> [2.7] 401 ns +- 21 ns:
> 1.48x slower (+48%)
>
> o[100]
> ======
>
> Median +- std dev: [3.5] 206 ns +- 5 ns -> [3.7] 211 ns +- 11 ns:
> 1.02x slower (+2%)
> Not significant!
> Median +- std dev: [3.5] 206 ns +- 5 ns -> [patch] 172 ns +- 11 ns:
> 1.20x faster (-17%)
> Median +- std dev: [3.5] 206 ns +- 5 ns -> [2.7] 254 ns +- 15 ns:
> 1.23x slower (+23%)
>
> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> annakoppad%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161209/1037b029/attachment-0001.html>

From almeidaraf at gmail.com  Sun Dec 11 16:38:47 2016
From: almeidaraf at gmail.com (Rafael Almeida)
Date: Sun, 11 Dec 2016 21:38:47 +0000
Subject: [Python-Dev] On time complexity of heapq.heapify
Message-ID: <CAKCnWVk48A9fcR46HMGtHBZM5JdDfgBFG8h-GS+ZGHokCpJOMQ@mail.gmail.com>

Hello,

Current heapify documentation says it takes linear time

    https://docs.python.org/3/library/heapq.html#heapq.heapify

However, investigating the code (Python 3.5.2) I saw this:

    def heapify(x):
        """Transform list into a heap, in-place, in O(len(x)) time."""
        n = len(x)
        # Transform bottom-up.  The largest index there's any point to
looking at
        # is the largest with a child index in-range, so must have 2*i + 1
< n,
        # or i < (n-1)/2.  If n is even = 2*j, this is (2*j-1)/2 = j-1/2 so
        # j-1 is the largest, which is n//2 - 1.  If n is odd = 2*j+1, this
is
        # (2*j+1-1)/2 = j so j-1 is the largest, and that's again n//2-1.
        for i in reversed(range(n//2)):
            _siftup(x, i)

>From what I gather, _siftup(heap, pos) does not run in constant time, but
rather it runs in time proportional to the height of the subtree with root
in ``pos''. Although, according to the in-code comments, it should be
faster than creating a heap by calling heappush multiple times, I believe
the time complexity remains the same.

Although I had a hard time finding out the exact time complexity for that
particular function, I think it is closer to O(log(n!)) than to O(n). I
would be very happy to see an explanation as to why the time is O(n) (it
does not seem possible to me to create a heap of n numbers in such
runtime). However, if no one has a convincing argument, I'd rather omit
time complexity information from documentation (given that this analysis is
not made for the other functions either).

[]'s
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161211/fa3f063e/attachment-0001.html>

From raymond.hettinger at gmail.com  Mon Dec 12 11:12:08 2016
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 12 Dec 2016 08:12:08 -0800
Subject: [Python-Dev] On time complexity of heapq.heapify
In-Reply-To: <CAKCnWVk48A9fcR46HMGtHBZM5JdDfgBFG8h-GS+ZGHokCpJOMQ@mail.gmail.com>
References: <CAKCnWVk48A9fcR46HMGtHBZM5JdDfgBFG8h-GS+ZGHokCpJOMQ@mail.gmail.com>
Message-ID: <AFDD0535-6E67-4A1D-8342-A58F66E2C088@gmail.com>


> On Dec 11, 2016, at 1:38 PM, Rafael Almeida <almeidaraf at gmail.com> wrote:
> 
> From what I gather, _siftup(heap, pos) does not run in constant time, but rather it runs in time proportional to the height of the subtree with root in ``pos''. Although, according to the in-code comments, it should be faster than creating a heap by calling heappush multiple times, I believe the time complexity remains the same.
> 
> Although I had a hard time finding out the exact time complexity for that particular function, I think it is closer to O(log(n!)) than to O(n).

Hello Rafael,

The heapify() algorithm is well known and well studied.   A quick Google search turns up plenty of explanations: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=complexity%20of%20heapify 

algorithm - How can building a heap be O(n) time complexity? - StackOverflow
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=complexity%20of%20heapify

Data Structures Heap, Heap Sort & Priority Queue
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=complexity%20of%20heapify
Sub tree rooted at i is a max heap. Simple bound: 
? O(n) calls to MAX-HEAPIFY, 
? Each of which takes O(lg n), ? Complexity: O(n lg n). 
? Thus, the running time of BUILD-MAX-HEAP is O(n).

Here's a more detailed explanation:  http://www.cs.umd.edu/~meesh/351/mount/lectures/lect14-heapsort-analysis-part.pdf

If you have other follow-ups, please take this discussion to another list.  This list is for the development of the Python core and not for general questions about algorithms or use of the language.



Raymond Hettinger

From rosuav at gmail.com  Mon Dec 12 11:12:42 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 13 Dec 2016 03:12:42 +1100
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CADiSq7fTVw2BaFmY+JjYhohUNivGE8nVnNi1CfvHobJ4ujpEGA@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
 <22606.25221.667266.206330@turnbull.sk.tsukuba.ac.jp>
 <CACfEFw_Z6c0bqN_XRwvDTb1fho2Gq1h+yvcQkN0fjZMoK112NA@mail.gmail.com>
 <CADiSq7fTVw2BaFmY+JjYhohUNivGE8nVnNi1CfvHobJ4ujpEGA@mail.gmail.com>
Message-ID: <CAPTjJmpCduK1c21WD=-vR39R1MDi4Zmf_V3_w=WM=HRQRF1jJQ@mail.gmail.com>

On Tue, Dec 13, 2016 at 12:18 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> It absolutely *is* relevant, as is how diligent the redistributors are
> in differentiating between the unmodified upstream project and the
> patches we have applied post-release (rather than just posting the end
> result without a clear audit trail). Distros don't do all that extra
> work just for the fun of it - it's an essential part of keeping track
> of who's ultimately responsible for which pieces in a way that's
> transparent to recipients of the software. Ensuring we aren't taking
> excessive liberties with the language definition is also one of the
> reasons we sometimes seek explicit permission for deviations - it
> documents that those particular changes still fit within the bounds of
> what counts as "Python".

For clarification: By "we" in the above paragraph, you mean Red Hat,
not the PSF, right? You have two affiliations. :)

ChrisA

From raymond.hettinger at gmail.com  Mon Dec 12 11:43:29 2016
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 12 Dec 2016 08:43:29 -0800
Subject: [Python-Dev] On time complexity of heapq.heapify
In-Reply-To: <AFDD0535-6E67-4A1D-8342-A58F66E2C088@gmail.com>
References: <CAKCnWVk48A9fcR46HMGtHBZM5JdDfgBFG8h-GS+ZGHokCpJOMQ@mail.gmail.com>
 <AFDD0535-6E67-4A1D-8342-A58F66E2C088@gmail.com>
Message-ID: <12505033-66ED-4E93-9536-90F07D38B923@gmail.com>


> On Dec 12, 2016, at 8:12 AM, Raymond Hettinger <raymond.hettinger at gmail.com> wrote:
> 
> The heapify() algorithm is well known and well studied.   A quick Google search turns up plenty of explanations: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=complexity%20of%20heapify 
> 
> algorithm - How can building a heap be O(n) time complexity? - StackOverflow
> https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=complexity%20of%20heapify
> 
> Data Structures Heap, Heap Sort & Priority Queue
> https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=complexity%20of%20heapify
> Sub tree rooted at i is a max heap. Simple bound: 
> ? O(n) calls to MAX-HEAPIFY, 
> ? Each of which takes O(lg n), ? Complexity: O(n lg n). 
> ? Thus, the running time of BUILD-MAX-HEAP is O(n).
> 
> Here's a more detailed explanation:  http://www.cs.umd.edu/~meesh/351/mount/lectures/lect14-heapsort-analysis-part.pdf
> 
> If you have other follow-ups, please take this discussion to another list.  This list is for the development of the Python core and not for general questions about algorithms or use of the language.

I forgot to attach the measurements that demonstrate the O(n) complexity:

# Python 3 Code
from heapq import heapify
from random import randrange

cmp_cnt = 0

class Int(int):
    def __lt__(self, other):
        global cmp_cnt
        cmp_cnt += 1
        return super.__lt__(self, other)

def trial(n):
    global cmp_cnt
    
    data = [Int(randrange(1000000)) for i in range(n)]
    cmp_cnt = 0
    heapify(data)
    return cmp_cnt

for n in [100, 1000, 10000, 100000, 1000000, 10000000]:
    print("n = {:<10d}    compares = {}".format(n, trial(n)))

Which outputs:

n = 100           compares = 155
n = 1000          compares = 1620
n = 10000         compares = 16446
n = 100000        compares = 164779
n = 1000000       compares = 1649165
n = 10000000      compares = 16493429



From ncoghlan at gmail.com  Mon Dec 12 23:50:23 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 13 Dec 2016 14:50:23 +1000
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CAPTjJmpCduK1c21WD=-vR39R1MDi4Zmf_V3_w=WM=HRQRF1jJQ@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
 <22606.25221.667266.206330@turnbull.sk.tsukuba.ac.jp>
 <CACfEFw_Z6c0bqN_XRwvDTb1fho2Gq1h+yvcQkN0fjZMoK112NA@mail.gmail.com>
 <CADiSq7fTVw2BaFmY+JjYhohUNivGE8nVnNi1CfvHobJ4ujpEGA@mail.gmail.com>
 <CAPTjJmpCduK1c21WD=-vR39R1MDi4Zmf_V3_w=WM=HRQRF1jJQ@mail.gmail.com>
Message-ID: <CADiSq7dfGtpLYoNqFf=0RX+CU=aFyTfD1uk20gES5yDW-E_KBQ@mail.gmail.com>

On 13 December 2016 at 02:12, Chris Angelico <rosuav at gmail.com> wrote:
> On Tue, Dec 13, 2016 at 12:18 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> It absolutely *is* relevant, as is how diligent the redistributors are
>> in differentiating between the unmodified upstream project and the
>> patches we have applied post-release (rather than just posting the end
>> result without a clear audit trail). Distros don't do all that extra
>> work just for the fun of it - it's an essential part of keeping track
>> of who's ultimately responsible for which pieces in a way that's
>> transparent to recipients of the software. Ensuring we aren't taking
>> excessive liberties with the language definition is also one of the
>> reasons we sometimes seek explicit permission for deviations - it
>> documents that those particular changes still fit within the bounds of
>> what counts as "Python".
>
> For clarification: By "we" in the above paragraph, you mean Red Hat,
> not the PSF, right? You have two affiliations. :)

You're right, I should be clearer about my pronouns. Technically I'm
referring to the Fedora Python SIG here, as I don't have the authority
to speak on behalf of Red Hat itself. There may be visible
correlations between the redistribution practices of Fedora, RHEL, and
CentOS, though :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From sesha.subbiah at gmail.com  Tue Dec 13 03:11:36 2016
From: sesha.subbiah at gmail.com (Sesha Narayanan Subbiah)
Date: Tue, 13 Dec 2016 13:41:36 +0530
Subject: [Python-Dev] Removing memoryview object patch from Python 2.7
Message-ID: <CA+MtcFy19g4=OmTQGTzmy=OALZ_Y2-CDMr-EixhNxT7R-736TA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161213/a303b4f7/attachment.html>

From sesha.subbiah at gmail.com  Tue Dec 13 03:14:54 2016
From: sesha.subbiah at gmail.com (Sesha Narayanan Subbiah)
Date: Tue, 13 Dec 2016 13:44:54 +0530
Subject: [Python-Dev] Fwd: Removing memoryview object patch from Python 2.7
In-Reply-To: <CA+MtcFy19g4=OmTQGTzmy=OALZ_Y2-CDMr-EixhNxT7R-736TA@mail.gmail.com>
References: <CA+MtcFy19g4=OmTQGTzmy=OALZ_Y2-CDMr-EixhNxT7R-736TA@mail.gmail.com>
Message-ID: <CA+MtcFyZWqiG_dgqqUmZL7s9_dWA3SOZtXcuV+FvrCGxa+5Tug@mail.gmail.com>

---------- Forwarded message ----------
From: Sesha Narayanan Subbiah <sesha.subbiah at gmail.com>
Date: Tue, Dec 13, 2016 at 1:41 PM
Subject: Removing memoryview object patch from Python 2.7
To: python-dev at python.org


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161213/abc31b91/attachment.html>

From maxmoroz at gmail.com  Tue Dec 13 04:51:08 2016
From: maxmoroz at gmail.com (Max Moroz)
Date: Tue, 13 Dec 2016 01:51:08 -0800
Subject: [Python-Dev] Making sure dictionary adds/deletes during iteration
 always raise exception
Message-ID: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>

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-iteration-doesnt-always-raise-exception.

Max

From turnbull.stephen.fw at u.tsukuba.ac.jp  Tue Dec 13 06:56:08 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Tue, 13 Dec 2016 20:56:08 +0900
Subject: [Python-Dev] Someons's put a "Python 2.8" on GitHub
In-Reply-To: <CACfEFw8F1dQ1TBF65Q4Bm=k-4Rr5QVv7+AJNaD2bKQPFdweHmA@mail.gmail.com>
References: <86203c27-80ab-36e5-c6c6-2ffe33599b2d@hastings.org>
 <20161210080930.GY3365@ando.pearwood.info>
 <20161210091837.2c8ca8e0.barry@wooz.org>
 <CAEbHw4Y0fTzkGyunbowBz5gq0gGz7keeVBF=sO6xpRpRamSHfQ@mail.gmail.com>
 <a0eab2f7-6c3e-deac-b077-ec2b3650e9b8@egenix.com>
 <CACfEFw_8+Fi5bmPQXaVYKjZkoAYvke9T+M1M=qHnrUYS5_oM_Q@mail.gmail.com>
 <CAEbHw4ZGprd1kUddTW_4VdeqoZRjYn3zC8tpAgb4R2vJ1z5K9Q@mail.gmail.com>
 <CACfEFw-ygoCB13JirG23=-=g3TdruwEJy8jpaRBOgYyLo8t3Sw@mail.gmail.com>
 <22606.25221.667266.206330@turnbull.sk.tsukuba.ac.jp>
 <CACfEFw8F1dQ1TBF65Q4Bm=k-4Rr5QVv7+AJNaD2bKQPFdweHmA@mail.gmail.com>
Message-ID: <22607.57816.909849.95311@turnbull.sk.tsukuba.ac.jp>

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 at 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. :-(

From khlukekim at gmail.com  Tue Dec 13 06:31:06 2016
From: khlukekim at gmail.com (KH Luke Kim)
Date: Tue, 13 Dec 2016 20:31:06 +0900
Subject: [Python-Dev] Implementation difference of audioop.lin2lin in
 Python2 and Python3
Message-ID: <CAAP64MJG_vqi-djvQzTsYcj8ezLveby4RWtdsqH3G5f-NMntAQ@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161213/766e5b48/attachment-0001.html>

From sesha.subbiah at gmail.com  Tue Dec 13 07:23:48 2016
From: sesha.subbiah at gmail.com (Sesha Narayanan Subbiah)
Date: Tue, 13 Dec 2016 17:53:48 +0530
Subject: [Python-Dev] Removing memoryview object patch from Python 2.7
Message-ID: <CA+MtcFxWNRy8wtmPv5tTUtDV5rfgN1wppD2fLVHtWuARv=qB1g@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161213/52f5bfc0/attachment-0001.html>

From sesha.subbiah at gmail.com  Tue Dec 13 07:26:35 2016
From: sesha.subbiah at gmail.com (Sesha Narayanan Subbiah)
Date: Tue, 13 Dec 2016 17:56:35 +0530
Subject: [Python-Dev]  Removing memoryview object patch from Python 2.7
Message-ID: <CA+MtcFwf_sEGpcp6oRu2oNQGWRR9S1pnnP-dW-ddfM9pxgWABA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161213/0e6fe781/attachment-0001.html>

From python at mrabarnett.plus.com  Tue Dec 13 08:37:21 2016
From: python at mrabarnett.plus.com (MRAB)
Date: Tue, 13 Dec 2016 13:37:21 +0000
Subject: [Python-Dev] Implementation difference of audioop.lin2lin in
 Python2 and Python3
In-Reply-To: <CAAP64MJG_vqi-djvQzTsYcj8ezLveby4RWtdsqH3G5f-NMntAQ@mail.gmail.com>
References: <CAAP64MJG_vqi-djvQzTsYcj8ezLveby4RWtdsqH3G5f-NMntAQ@mail.gmail.com>
Message-ID: <75c1d303-f111-645e-4524-892f2dd4a8c0@mrabarnett.plus.com>

On 2016-12-13 11:31, KH Luke Kim wrote:
> 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?
>
The Python docs say that support for 3-byte (24-bit) samples was added 
in Python 3.4, so anyone using a version before that one is out of luck!


From raymond.hettinger at gmail.com  Tue Dec 13 11:42:27 2016
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Tue, 13 Dec 2016 08:42:27 -0800
Subject: [Python-Dev] Making sure dictionary adds/deletes during
 iteration always raise exception
In-Reply-To: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>
References: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>
Message-ID: <30C2E63F-101C-4B2A-948B-F2BE6E177A8C@gmail.com>


> On Dec 13, 2016, at 1:51 AM, Max Moroz <maxmoroz at gmail.com> wrote:
> 
> Would it be worth ensuring that an exception is ALWAYS raised if a key
> is added to or deleted from a dictionary during iteration?
> <snip>
> I suspect the cost of a more comprehensive error reporting is not
> worth the benefit, but I thought I'd ask anyway.

I think what we have has proven itself to be good enough to detect the common cases, and it isn't worth it to have dicts grow an extra field which has to be checked or updated on every operation.


Raymond


From raymond.hettinger at gmail.com  Tue Dec 13 11:54:28 2016
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Tue, 13 Dec 2016 08:54:28 -0800
Subject: [Python-Dev] Making sure dictionary adds/deletes during
 iteration always raise exception
In-Reply-To: <30C2E63F-101C-4B2A-948B-F2BE6E177A8C@gmail.com>
References: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>
 <30C2E63F-101C-4B2A-948B-F2BE6E177A8C@gmail.com>
Message-ID: <459C88C9-84B6-4B2C-8E4E-6128B99849C3@gmail.com>


> On Dec 13, 2016, at 8:42 AM, Raymond Hettinger <raymond.hettinger at gmail.com> wrote:
> 
>> On Dec 13, 2016, at 1:51 AM, Max Moroz <maxmoroz at gmail.com> wrote:
>> 
>> Would it be worth ensuring that an exception is ALWAYS raised if a key
>> is added to or deleted from a dictionary during iteration?
>> <snip>
>> I suspect the cost of a more comprehensive error reporting is not
>> worth the benefit, but I thought I'd ask anyway.
> 
> I think what we have has proven itself to be good enough to detect the common cases, and it isn't worth it to have dicts grow an extra field which has to be checked or updated on every operation.

Hmm, I just looked at the latest dictobject.h and remembered that Victor already added a version tag to track state changes.


Raymond

From eric at trueblade.com  Tue Dec 13 11:52:18 2016
From: eric at trueblade.com (Eric V. Smith)
Date: Tue, 13 Dec 2016 11:52:18 -0500
Subject: [Python-Dev] Making sure dictionary adds/deletes during
 iteration always raise exception
In-Reply-To: <30C2E63F-101C-4B2A-948B-F2BE6E177A8C@gmail.com>
References: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>
 <30C2E63F-101C-4B2A-948B-F2BE6E177A8C@gmail.com>
Message-ID: <2EE2E6FC-90B9-4DD3-8E33-D9533899F1AB@trueblade.com>


> On Dec 13, 2016, at 11:42 AM, Raymond Hettinger <raymond.hettinger at gmail.com> wrote:
> 
> 
>> On Dec 13, 2016, at 1:51 AM, Max Moroz <maxmoroz at gmail.com> wrote:
>> 
>> Would it be worth ensuring that an exception is ALWAYS raised if a key
>> is added to or deleted from a dictionary during iteration?
>> <snip>
>> I suspect the cost of a more comprehensive error reporting is not
>> worth the benefit, but I thought I'd ask anyway.
> 
> I think what we have has proven itself to be good enough to detect the common cases, and it isn't worth it to have dicts grow an extra field which has to be checked or updated on every operation.
> 

I agree that we shouldn't complicate things, but wouldn't PEP 509 be a cheap way to check this?

Eric. 

From guido at python.org  Tue Dec 13 12:48:35 2016
From: guido at python.org (Guido van Rossum)
Date: Tue, 13 Dec 2016 09:48:35 -0800
Subject: [Python-Dev] Making sure dictionary adds/deletes during
 iteration always raise exception
In-Reply-To: <2EE2E6FC-90B9-4DD3-8E33-D9533899F1AB@trueblade.com>
References: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>
 <30C2E63F-101C-4B2A-948B-F2BE6E177A8C@gmail.com>
 <2EE2E6FC-90B9-4DD3-8E33-D9533899F1AB@trueblade.com>
Message-ID: <CAP7+vJLJQOTMTTc3c42w28C5XX8c3RVhfMVTQqwT5Tjssv2sCA@mail.gmail.com>

On Tue, Dec 13, 2016 at 8:52 AM, Eric V. Smith <eric at trueblade.com> wrote:

>
> > On Dec 13, 2016, at 11:42 AM, Raymond Hettinger <
> raymond.hettinger at gmail.com> wrote:
> >
> >> On Dec 13, 2016, at 1:51 AM, Max Moroz <maxmoroz at gmail.com> wrote:
> >>
> >> Would it be worth ensuring that an exception is ALWAYS raised if a key
> >> is added to or deleted from a dictionary during iteration?
> >> <snip>
> >> I suspect the cost of a more comprehensive error reporting is not
> >> worth the benefit, but I thought I'd ask anyway.
> >
> > I think what we have has proven itself to be good enough to detect the
> common cases, and it isn't worth it to have dicts grow an extra field which
> has to be checked or updated on every operation.
> >
>
> I agree that we shouldn't complicate things, but wouldn't PEP 509 be a
> cheap way to check this?
>

IIUC the private version gets updated every time the dict gets modified --
but what we need here should only trigger when a key is added or removed,
not when a value is updated. (It's a guarantee that updating the value
doesn't change the iteration order -- though perhaps it isn't spelled out,
it's implicit.)

I agree with Raymond that we should not change anything.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161213/d17e5f90/attachment.html>

From rosuav at gmail.com  Tue Dec 13 12:55:20 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 14 Dec 2016 04:55:20 +1100
Subject: [Python-Dev] Making sure dictionary adds/deletes during
 iteration always raise exception
In-Reply-To: <CAP7+vJLJQOTMTTc3c42w28C5XX8c3RVhfMVTQqwT5Tjssv2sCA@mail.gmail.com>
References: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>
 <30C2E63F-101C-4B2A-948B-F2BE6E177A8C@gmail.com>
 <2EE2E6FC-90B9-4DD3-8E33-D9533899F1AB@trueblade.com>
 <CAP7+vJLJQOTMTTc3c42w28C5XX8c3RVhfMVTQqwT5Tjssv2sCA@mail.gmail.com>
Message-ID: <CAPTjJmpAx2-YzKA3Q+00p2cK8SnF7Y7j2iK3WbVAE+c7w-dVxw@mail.gmail.com>

On Wed, Dec 14, 2016 at 4:48 AM, Guido van Rossum <guido at python.org> wrote:
> IIUC the private version gets updated every time the dict gets modified --
> but what we need here should only trigger when a key is added or removed,
> not when a value is updated.

Is it possible to add a key, triggering a resize of the dict, then
remove one, and continue iterating through the old (deallocated)
memory? If so, that could potentially cause a crash.

ChrisA

From eric at trueblade.com  Tue Dec 13 12:56:17 2016
From: eric at trueblade.com (Eric V. Smith)
Date: Tue, 13 Dec 2016 12:56:17 -0500
Subject: [Python-Dev] Making sure dictionary adds/deletes during
 iteration always raise exception
In-Reply-To: <CAP7+vJLJQOTMTTc3c42w28C5XX8c3RVhfMVTQqwT5Tjssv2sCA@mail.gmail.com>
References: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>
 <30C2E63F-101C-4B2A-948B-F2BE6E177A8C@gmail.com>
 <2EE2E6FC-90B9-4DD3-8E33-D9533899F1AB@trueblade.com>
 <CAP7+vJLJQOTMTTc3c42w28C5XX8c3RVhfMVTQqwT5Tjssv2sCA@mail.gmail.com>
Message-ID: <0CD6A717-80BD-445A-9B08-C29A19F71D41@trueblade.com>


> On Dec 13, 2016, at 12:48 PM, Guido van Rossum <guido at python.org> wrote:
> 
>> On Tue, Dec 13, 2016 at 8:52 AM, Eric V. Smith <eric at trueblade.com> wrote:
>> 
>> > On Dec 13, 2016, at 11:42 AM, Raymond Hettinger <raymond.hettinger at gmail.com> wrote:
>> >
>> >> On Dec 13, 2016, at 1:51 AM, Max Moroz <maxmoroz at gmail.com> wrote:
>> >>
>> >> Would it be worth ensuring that an exception is ALWAYS raised if a key
>> >> is added to or deleted from a dictionary during iteration?
>> >> <snip>
>> >> I suspect the cost of a more comprehensive error reporting is not
>> >> worth the benefit, but I thought I'd ask anyway.
>> >
>> > I think what we have has proven itself to be good enough to detect the common cases, and it isn't worth it to have dicts grow an extra field which has to be checked or updated on every operation.
>> >
>> 
>> I agree that we shouldn't complicate things, but wouldn't PEP 509 be a cheap way to check this?
> 
> IIUC the private version gets updated every time the dict gets modified -- but what we need here should only trigger when a key is added or removed, not when a value is updated. (It's a guarantee that updating the value doesn't change the iteration order -- though perhaps it isn't spelled out, it's implicit.)
> 

Ah, yes. That's over-zealous for this case. 

> I agree with Raymond that we should not change anything.

Agreed. 

Eric. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161213/022a4fe1/attachment.html>

From rosuav at gmail.com  Tue Dec 13 13:17:06 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 14 Dec 2016 05:17:06 +1100
Subject: [Python-Dev] Making sure dictionary adds/deletes during
 iteration always raise exception
In-Reply-To: <CAFo6DPaSwE213dg2UP6-JtcwKJE52fSxzvwRoWGBHXY8XLHAcg@mail.gmail.com>
References: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>
 <30C2E63F-101C-4B2A-948B-F2BE6E177A8C@gmail.com>
 <2EE2E6FC-90B9-4DD3-8E33-D9533899F1AB@trueblade.com>
 <CAP7+vJLJQOTMTTc3c42w28C5XX8c3RVhfMVTQqwT5Tjssv2sCA@mail.gmail.com>
 <CAPTjJmpAx2-YzKA3Q+00p2cK8SnF7Y7j2iK3WbVAE+c7w-dVxw@mail.gmail.com>
 <CAFo6DPaSwE213dg2UP6-JtcwKJE52fSxzvwRoWGBHXY8XLHAcg@mail.gmail.com>
Message-ID: <CAPTjJmq0VRrzQP_J6VRVQZwREu05K18aowN5hhgFFJN0L_G4=A@mail.gmail.com>

On Wed, Dec 14, 2016 at 5:13 AM, Joe Jevnik <jjevnik at quantopian.com> wrote:
>> Is it possible to add a key, triggering a resize of the dict, then
> remove one, and continue iterating through the old (deallocated)
> memory?
>
> You can add and remove keys between calling next which would resize the
> dictionary; however, it will not iterate through uninitialized memory. The
> dictiter holds the current index and each time next is called it goes
> directly to ma_keys->dk_entries[saved_index] or ma_values[saved_index]

Okay, so it's fine then. Cool. Thanks for the info.

ChrisA

From robertc at robertcollins.net  Tue Dec 13 13:19:11 2016
From: robertc at robertcollins.net (Robert Collins)
Date: Wed, 14 Dec 2016 07:19:11 +1300
Subject: [Python-Dev] Removing memoryview object patch from Python 2.7
In-Reply-To: <CA+MtcFwf_sEGpcp6oRu2oNQGWRR9S1pnnP-dW-ddfM9pxgWABA@mail.gmail.com>
References: <CA+MtcFwf_sEGpcp6oRu2oNQGWRR9S1pnnP-dW-ddfM9pxgWABA@mail.gmail.com>
Message-ID: <CAJ3HoZ3OKjJoe+KFYJ=WGMU88DpzKvCL2M-iCTWyS3d0T1-vvQ@mail.gmail.com>

On 14 December 2016 at 01:26, Sesha Narayanan Subbiah
<sesha.subbiah at gmail.com> wrote:
> 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?

I'm not sure - if you're going to run with old, custom, builds of
Python, you're probably best served by testing comprehensively for
this yourself.

That said, I have to presume that the error you're getting is from
some code that should be changed anyway, and will need to be changed
when you move to Python 3. Please remember that Python 2.7.6 was
released in 2013 - there have been many security issues since then,
including some of the most egregious SSL issues ever, which should
prompt you to run the latest 2.7 branch (if you're unable to migrate
straight to 3.x.

-Rob

From vadmium+py at gmail.com  Tue Dec 13 14:58:22 2016
From: vadmium+py at gmail.com (Martin Panter)
Date: Tue, 13 Dec 2016 19:58:22 +0000
Subject: [Python-Dev] Implementation difference of audioop.lin2lin in
 Python2 and Python3
In-Reply-To: <75c1d303-f111-645e-4524-892f2dd4a8c0@mrabarnett.plus.com>
References: <CAAP64MJG_vqi-djvQzTsYcj8ezLveby4RWtdsqH3G5f-NMntAQ@mail.gmail.com>
 <75c1d303-f111-645e-4524-892f2dd4a8c0@mrabarnett.plus.com>
Message-ID: <CA+eR4cEpXi2uc4REJmCUSmwSYkMwahgmRy0TsvpQP=RY3gBWLw@mail.gmail.com>

On 13 December 2016 at 13:37, MRAB <python at mrabarnett.plus.com> wrote:
> On 2016-12-13 11:31, KH Luke Kim wrote:
>>
>> 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?
>>
> The Python docs say that support for 3-byte (24-bit) samples was added in
> Python 3.4, so anyone using a version before that one is out of luck!

The 3.4 reference leads you to What?s New, which leads to discussion
in the bug tracker:
https://docs.python.org/3/whatsnew/3.4.html#audioop
https://bugs.python.org/issue12866

From storchaka at gmail.com  Tue Dec 13 18:02:50 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 14 Dec 2016 01:02:50 +0200
Subject: [Python-Dev] Making sure dictionary adds/deletes during
 iteration always raise exception
In-Reply-To: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>
References: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>
Message-ID: <o2pumm$7pj$1@blaine.gmane.org>

On 13.12.16 11:51, Max Moroz wrote:
> 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.

The patch implementing this was rejected.

http://bugs.python.org/issue19332



From songofacandy at gmail.com  Tue Dec 13 22:55:46 2016
From: songofacandy at gmail.com (INADA Naoki)
Date: Wed, 14 Dec 2016 12:55:46 +0900
Subject: [Python-Dev] Making sure dictionary adds/deletes during
 iteration always raise exception
In-Reply-To: <o2pumm$7pj$1@blaine.gmane.org>
References: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>
 <o2pumm$7pj$1@blaine.gmane.org>
Message-ID: <CAEfz+TyHLV5Fb0sbAzAcAnwQ1Pgmf3=SocETeRRKBxuPr312-g@mail.gmail.com>

When adding new key, dk_usable is decremented.
When removing key, dk_usable is not decremented.

So I think dk_usable & ma_used pair can be used to detect dict size
modification.

On Wed, Dec 14, 2016 at 8:02 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> On 13.12.16 11:51, Max Moroz wrote:
>>
>> 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.
>
>
> The patch implementing this was rejected.
>
> http://bugs.python.org/issue19332
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com



-- 
INADA Naoki  <songofacandy at gmail.com>

From robertc at robertcollins.net  Wed Dec 14 07:03:20 2016
From: robertc at robertcollins.net (Robert Collins)
Date: Thu, 15 Dec 2016 01:03:20 +1300
Subject: [Python-Dev] Removing memoryview object patch from Python 2.7
In-Reply-To: <CA+MtcFxOU=bgLZMOu6WYtk+DO6G=RVVtxPQZiufJjYNKbbnDLg@mail.gmail.com>
References: <CA+MtcFwf_sEGpcp6oRu2oNQGWRR9S1pnnP-dW-ddfM9pxgWABA@mail.gmail.com>
 <CAJ3HoZ3OKjJoe+KFYJ=WGMU88DpzKvCL2M-iCTWyS3d0T1-vvQ@mail.gmail.com>
 <CA+MtcFxOU=bgLZMOu6WYtk+DO6G=RVVtxPQZiufJjYNKbbnDLg@mail.gmail.com>
Message-ID: <CAJ3HoZ1a-k_pzSyra9Bn0j5nn2=5d+_DiH10s0Lrz+YW8N-vaQ@mail.gmail.com>

On 14 December 2016 at 18:10, Sesha Narayanan Subbiah
<sesha.subbiah at gmail.com> wrote:
> Hi Rob
>
> Thanks for your reply.
>
> From http://legacy.python.org/download/, I could see that the current
> production releases are Python 3.4 and Python 2.7.6.

Nope - https://www.python.org/downloads/ - 2.7.12 and 3.5.2 are
current. The 'legacy' domain there was from a site revamp, I think its
causing confusion at this point and we should look at retiring it
completely.

> Since we use python for some our legacy applications, we don't want to
> switch to Python 3.0 right now. Moreover, since Python 2.6 is not supported
> anymore, we want to upgrade to Python 2.7.

> Do you suggest I should use Python 2.7.12 which is the latest version in 2.7
> series? I picked up 2.7.6, since it was listed as production release and
> assumed it is the most stable version.

If you can, 3.5.2 is where to switch to. If that won't work, 2.7.12 yes.

-Rob

From khlukekim at gmail.com  Tue Dec 13 08:47:33 2016
From: khlukekim at gmail.com (KH Luke Kim)
Date: Tue, 13 Dec 2016 22:47:33 +0900
Subject: [Python-Dev] Implementation difference of audioop.lin2lin in
 Python2 and Python3
In-Reply-To: <75c1d303-f111-645e-4524-892f2dd4a8c0@mrabarnett.plus.com>
References: <CAAP64MJG_vqi-djvQzTsYcj8ezLveby4RWtdsqH3G5f-NMntAQ@mail.gmail.com>
 <75c1d303-f111-645e-4524-892f2dd4a8c0@mrabarnett.plus.com>
Message-ID: <CAAP64M+5D7HhRgwh9_Pw90qqfmWPud_O8ePbMW4DPLMvwvKpLQ@mail.gmail.com>

Yeah, but is it supposed to be avoided to apply new features in Python 3.x
to Python 2.x? Sorry if there's already a consensus.

2016-12-13 22:37 GMT+09:00 MRAB <python at mrabarnett.plus.com>:

> On 2016-12-13 11:31, KH Luke Kim wrote:
>
>> 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?
>>
>> The Python docs say that support for 3-byte (24-bit) samples was added in
> Python 3.4, so anyone using a version before that one is out of luck!
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/khlukekim
> %40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161213/6991652e/attachment-0001.html>

From ronaldoussoren at me.com  Tue Dec 13 12:04:55 2016
From: ronaldoussoren at me.com (Ronald Oussoren)
Date: Tue, 13 Dec 2016 18:04:55 +0100
Subject: [Python-Dev] Making sure dictionary adds/deletes during
 iteration always raise exception
In-Reply-To: <2EE2E6FC-90B9-4DD3-8E33-D9533899F1AB@trueblade.com>
References: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>
 <30C2E63F-101C-4B2A-948B-F2BE6E177A8C@gmail.com>
 <2EE2E6FC-90B9-4DD3-8E33-D9533899F1AB@trueblade.com>
Message-ID: <76B73914-5B5C-460C-841F-4A71E86575B3@me.com>


> On 13 Dec 2016, at 17:52, Eric V. Smith <eric at trueblade.com> wrote:
> 
> 
>> On Dec 13, 2016, at 11:42 AM, Raymond Hettinger <raymond.hettinger at gmail.com> wrote:
>> 
>> 
>>> On Dec 13, 2016, at 1:51 AM, Max Moroz <maxmoroz at gmail.com> wrote:
>>> 
>>> Would it be worth ensuring that an exception is ALWAYS raised if a key
>>> is added to or deleted from a dictionary during iteration?
>>> <snip>
>>> I suspect the cost of a more comprehensive error reporting is not
>>> worth the benefit, but I thought I'd ask anyway.
>> 
>> I think what we have has proven itself to be good enough to detect the common cases, and it isn't worth it to have dicts grow an extra field which has to be checked or updated on every operation.
>> 
> 
> I agree that we shouldn't complicate things, but wouldn't PEP 509 be a cheap way to check this?

Doesn?t that update the version with every change to a dict instance? That is, not just when the set of keys for the dict changes.

Ronald


From jjevnik at quantopian.com  Tue Dec 13 13:13:13 2016
From: jjevnik at quantopian.com (Joe Jevnik)
Date: Tue, 13 Dec 2016 13:13:13 -0500
Subject: [Python-Dev] Making sure dictionary adds/deletes during
 iteration always raise exception
In-Reply-To: <CAPTjJmpAx2-YzKA3Q+00p2cK8SnF7Y7j2iK3WbVAE+c7w-dVxw@mail.gmail.com>
References: <CAOVPiMghrAG84e8R+iyK49Zx71dRYW6Tzm09XcFa12bWRhbZ8w@mail.gmail.com>
 <30C2E63F-101C-4B2A-948B-F2BE6E177A8C@gmail.com>
 <2EE2E6FC-90B9-4DD3-8E33-D9533899F1AB@trueblade.com>
 <CAP7+vJLJQOTMTTc3c42w28C5XX8c3RVhfMVTQqwT5Tjssv2sCA@mail.gmail.com>
 <CAPTjJmpAx2-YzKA3Q+00p2cK8SnF7Y7j2iK3WbVAE+c7w-dVxw@mail.gmail.com>
Message-ID: <CAFo6DPaSwE213dg2UP6-JtcwKJE52fSxzvwRoWGBHXY8XLHAcg@mail.gmail.com>

> Is it possible to add a key, triggering a resize of the dict, then
remove one, and continue iterating through the old (deallocated)
memory?

You can add and remove keys between calling next which would resize the
dictionary; however, it will not iterate through uninitialized memory. The
dictiter holds the current index and each time next is called it goes
directly to ma_keys->dk_entries[saved_index] or ma_values[saved_index]

On Tue, Dec 13, 2016 at 12:55 PM, Chris Angelico <rosuav at gmail.com> wrote:

> On Wed, Dec 14, 2016 at 4:48 AM, Guido van Rossum <guido at python.org>
> wrote:
> > IIUC the private version gets updated every time the dict gets modified
> --
> > but what we need here should only trigger when a key is added or removed,
> > not when a value is updated.
>
> Is it possible to add a key, triggering a resize of the dict, then
> remove one, and continue iterating through the old (deallocated)
> memory? If so, that could potentially cause a crash.
>
> ChrisA
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> joe%40quantopian.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161213/b6561bfa/attachment.html>

From sesha.subbiah at gmail.com  Wed Dec 14 00:10:50 2016
From: sesha.subbiah at gmail.com (Sesha Narayanan Subbiah)
Date: Wed, 14 Dec 2016 10:40:50 +0530
Subject: [Python-Dev] Removing memoryview object patch from Python 2.7
In-Reply-To: <CAJ3HoZ3OKjJoe+KFYJ=WGMU88DpzKvCL2M-iCTWyS3d0T1-vvQ@mail.gmail.com>
References: <CA+MtcFwf_sEGpcp6oRu2oNQGWRR9S1pnnP-dW-ddfM9pxgWABA@mail.gmail.com>
 <CAJ3HoZ3OKjJoe+KFYJ=WGMU88DpzKvCL2M-iCTWyS3d0T1-vvQ@mail.gmail.com>
Message-ID: <CA+MtcFxOU=bgLZMOu6WYtk+DO6G=RVVtxPQZiufJjYNKbbnDLg@mail.gmail.com>

Hi Rob

Thanks for your reply.

>From http://legacy.python.org/download/, I could see that the current
production releases are Python 3.4 and Python 2.7.6.

Since we use python for some our legacy applications, we don't want to
switch to Python 3.0 right now. Moreover, since Python 2.6 is not supported
anymore, we want to upgrade to Python 2.7.

Do you suggest I should use Python 2.7.12 which is the latest version in
2.7 series? I picked up 2.7.6, since it was listed as production release
and assumed it is the most stable version.

Thanks
Sesha




On Tue, Dec 13, 2016 at 11:49 PM, Robert Collins <robertc at robertcollins.net>
wrote:

> On 14 December 2016 at 01:26, Sesha Narayanan Subbiah
> <sesha.subbiah at gmail.com> wrote:
> > 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?
>
> I'm not sure - if you're going to run with old, custom, builds of
> Python, you're probably best served by testing comprehensively for
> this yourself.
>
> That said, I have to presume that the error you're getting is from
> some code that should be changed anyway, and will need to be changed
> when you move to Python 3. Please remember that Python 2.7.6 was
> released in 2013 - there have been many security issues since then,
> including some of the most egregious SSL issues ever, which should
> prompt you to run the latest 2.7 branch (if you're unable to migrate
> straight to 3.x.
>
> -Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161214/40cc46c6/attachment.html>

From khlukekim at gmail.com  Wed Dec 14 06:00:37 2016
From: khlukekim at gmail.com (KH Luke Kim)
Date: Wed, 14 Dec 2016 11:00:37 +0000
Subject: [Python-Dev] Implementation difference of audioop.lin2lin in
 Python2 and Python3
In-Reply-To: <CA+eR4cEpXi2uc4REJmCUSmwSYkMwahgmRy0TsvpQP=RY3gBWLw@mail.gmail.com>
References: <CAAP64MJG_vqi-djvQzTsYcj8ezLveby4RWtdsqH3G5f-NMntAQ@mail.gmail.com>
 <75c1d303-f111-645e-4524-892f2dd4a8c0@mrabarnett.plus.com>
 <CA+eR4cEpXi2uc4REJmCUSmwSYkMwahgmRy0TsvpQP=RY3gBWLw@mail.gmail.com>
Message-ID: <CAAP64M+8RAM_YW3RYbmE0L7QwL0746NkP_KpxAYQiSR_gmHmMg@mail.gmail.com>

That helped a lot, thanks!

On Wed, 14 Dec 2016 at 4:58 AM Martin Panter <vadmium+py at gmail.com> wrote:

> On 13 December 2016 at 13:37, MRAB <python at mrabarnett.plus.com> wrote:
>
> > On 2016-12-13 11:31, KH Luke Kim wrote:
>
> >>
>
> >> 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?
>
> >>
>
> > The Python docs say that support for 3-byte (24-bit) samples was added in
>
> > Python 3.4, so anyone using a version before that one is out of luck!
>
>
>
> The 3.4 reference leads you to What?s New, which leads to discussion
>
> in the bug tracker:
>
> https://docs.python.org/3/whatsnew/3.4.html#audioop
>
> https://bugs.python.org/issue12866
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161214/e6761e65/attachment.html>

From sesha.subbiah at gmail.com  Wed Dec 14 07:09:05 2016
From: sesha.subbiah at gmail.com (Sesha Narayanan Subbiah)
Date: Wed, 14 Dec 2016 12:09:05 +0000
Subject: [Python-Dev] Removing memoryview object patch from Python 2.7
In-Reply-To: <CAJ3HoZ1a-k_pzSyra9Bn0j5nn2=5d+_DiH10s0Lrz+YW8N-vaQ@mail.gmail.com>
References: <CA+MtcFwf_sEGpcp6oRu2oNQGWRR9S1pnnP-dW-ddfM9pxgWABA@mail.gmail.com>
 <CAJ3HoZ3OKjJoe+KFYJ=WGMU88DpzKvCL2M-iCTWyS3d0T1-vvQ@mail.gmail.com>
 <CA+MtcFxOU=bgLZMOu6WYtk+DO6G=RVVtxPQZiufJjYNKbbnDLg@mail.gmail.com>
 <CAJ3HoZ1a-k_pzSyra9Bn0j5nn2=5d+_DiH10s0Lrz+YW8N-vaQ@mail.gmail.com>
Message-ID: <CA+MtcFzO5iD4jfhpde2KqXwPBdnBvShEEZupJd5mFS-BCjn_xw@mail.gmail.com>

Thanks Rob. I will try upgrade to 2.7.12. Any idea of this memory view
object that has been back ported to 2.7 can be disabled in any way?

Thanks
Regards
Sesha

On Wed, Dec 14, 2016, 17:33 Robert Collins <robertc at robertcollins.net>
wrote:

> On 14 December 2016 at 18:10, Sesha Narayanan Subbiah
> <sesha.subbiah at gmail.com> wrote:
> > Hi Rob
> >
> > Thanks for your reply.
> >
> > From http://legacy.python.org/download/, I could see that the current
> > production releases are Python 3.4 and Python 2.7.6.
>
> Nope - https://www.python.org/downloads/ - 2.7.12 and 3.5.2 are
> current. The 'legacy' domain there was from a site revamp, I think its
> causing confusion at this point and we should look at retiring it
> completely.
>
> > Since we use python for some our legacy applications, we don't want to
> > switch to Python 3.0 right now. Moreover, since Python 2.6 is not
> supported
> > anymore, we want to upgrade to Python 2.7.
>
> > Do you suggest I should use Python 2.7.12 which is the latest version in
> 2.7
> > series? I picked up 2.7.6, since it was listed as production release and
> > assumed it is the most stable version.
>
> If you can, 3.5.2 is where to switch to. If that won't work, 2.7.12 yes.
>
> -Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161214/d49f7bf5/attachment.html>

From p.f.moore at gmail.com  Wed Dec 14 08:34:23 2016
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 14 Dec 2016 13:34:23 +0000
Subject: [Python-Dev] Implementation difference of audioop.lin2lin in
 Python2 and Python3
In-Reply-To: <CAAP64M+5D7HhRgwh9_Pw90qqfmWPud_O8ePbMW4DPLMvwvKpLQ@mail.gmail.com>
References: <CAAP64MJG_vqi-djvQzTsYcj8ezLveby4RWtdsqH3G5f-NMntAQ@mail.gmail.com>
 <75c1d303-f111-645e-4524-892f2dd4a8c0@mrabarnett.plus.com>
 <CAAP64M+5D7HhRgwh9_Pw90qqfmWPud_O8ePbMW4DPLMvwvKpLQ@mail.gmail.com>
Message-ID: <CACac1F9ZnaaJGwkznx1gFhLeFGAko_pGxZRcw+gOoMFJtdASaA@mail.gmail.com>

On 13 December 2016 at 13:47, KH Luke Kim <khlukekim at gmail.com> wrote:
> Yeah, but is it supposed to be avoided to apply new features in Python 3.x
> to Python 2.x? Sorry if there's already a consensus.

Yes. Only security-related new features will ever be backported to
Python 2 (and even those will be subject to discussion and probably
need a PEP, it's not a guarantee).
Paul

From p.f.moore at gmail.com  Wed Dec 14 08:35:48 2016
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 14 Dec 2016 13:35:48 +0000
Subject: [Python-Dev] Removing memoryview object patch from Python 2.7
In-Reply-To: <CA+MtcFxOU=bgLZMOu6WYtk+DO6G=RVVtxPQZiufJjYNKbbnDLg@mail.gmail.com>
References: <CA+MtcFwf_sEGpcp6oRu2oNQGWRR9S1pnnP-dW-ddfM9pxgWABA@mail.gmail.com>
 <CAJ3HoZ3OKjJoe+KFYJ=WGMU88DpzKvCL2M-iCTWyS3d0T1-vvQ@mail.gmail.com>
 <CA+MtcFxOU=bgLZMOu6WYtk+DO6G=RVVtxPQZiufJjYNKbbnDLg@mail.gmail.com>
Message-ID: <CACac1F8w0B7xbhg8eRHcrxK_FmAGcL-dz1FZOQgWmPLg6m8C9Q@mail.gmail.com>

On 14 December 2016 at 05:10, Sesha Narayanan Subbiah
<sesha.subbiah at gmail.com> wrote:
> From http://legacy.python.org/download/, I could see that the current
> production releases are Python 3.4 and Python 2.7.6.

That URL seems to be out of date. You should refer to www.python.org,
specifically https://www.python.org/downloads/

Paul

From christian at python.org  Wed Dec 14 09:31:49 2016
From: christian at python.org (Christian Heimes)
Date: Wed, 14 Dec 2016 15:31:49 +0100
Subject: [Python-Dev] 3.6.0: OpenSSL 1.1.0c is not supported
Message-ID: <b3f2cb13-a909-d9d1-ab68-b2f87d61e24e@python.org>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161214/e2fa4caa/attachment.sig>

From tjreedy at udel.edu  Wed Dec 14 14:57:52 2016
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 14 Dec 2016 14:57:52 -0500
Subject: [Python-Dev] Implementation difference of audioop.lin2lin in
 Python2 and Python3
In-Reply-To: <CAAP64M+5D7HhRgwh9_Pw90qqfmWPud_O8ePbMW4DPLMvwvKpLQ@mail.gmail.com>
References: <CAAP64MJG_vqi-djvQzTsYcj8ezLveby4RWtdsqH3G5f-NMntAQ@mail.gmail.com>
 <75c1d303-f111-645e-4524-892f2dd4a8c0@mrabarnett.plus.com>
 <CAAP64M+5D7HhRgwh9_Pw90qqfmWPud_O8ePbMW4DPLMvwvKpLQ@mail.gmail.com>
Message-ID: <o2s87t$kfr$1@blaine.gmane.org>

On 12/13/2016 8:47 AM, KH Luke Kim wrote:
> Yeah, but is it supposed to be avoided to apply new features in Python
> 3.x to Python 2.x? Sorry if there's already a consensus.

The feature set of every Pythonx.y version is frozen with the release of 
CPython x.y.0.  Thereafter, each x.y.1+ release only gets bug fixes. 
Note that the new audioop feature in 3.4.0 was not backported to the 
subsequent 3.3.? release.

Python 2.7 is generally no exception, but because of its extra long 
maintenance and projected life, a few security features *have* been 
backported.


-- 
Terry Jan Reedy


From ja.py at farowl.co.uk  Wed Dec 14 15:08:23 2016
From: ja.py at farowl.co.uk (Jeff Allen)
Date: Wed, 14 Dec 2016 20:08:23 +0000
Subject: [Python-Dev] Removing memoryview object patch from Python 2.7
In-Reply-To: <CA+MtcFzO5iD4jfhpde2KqXwPBdnBvShEEZupJd5mFS-BCjn_xw@mail.gmail.com>
References: <CA+MtcFwf_sEGpcp6oRu2oNQGWRR9S1pnnP-dW-ddfM9pxgWABA@mail.gmail.com>
 <CAJ3HoZ3OKjJoe+KFYJ=WGMU88DpzKvCL2M-iCTWyS3d0T1-vvQ@mail.gmail.com>
 <CA+MtcFxOU=bgLZMOu6WYtk+DO6G=RVVtxPQZiufJjYNKbbnDLg@mail.gmail.com>
 <CAJ3HoZ1a-k_pzSyra9Bn0j5nn2=5d+_DiH10s0Lrz+YW8N-vaQ@mail.gmail.com>
 <CA+MtcFzO5iD4jfhpde2KqXwPBdnBvShEEZupJd5mFS-BCjn_xw@mail.gmail.com>
Message-ID: <f16a1c8b-ec83-d99c-abc5-78519a602609@farowl.co.uk>

Hi Sesha:

memoryview is part of the language. Even if you could hide or remove the 
feature, you would be running a specially broken version of Python, 
which can't be good. There is surely a better way to fix the code. If it 
helps any, you're landing here:

https://hg.python.org/cpython/file/v2.7.12/Objects/stringobject.c#l819

in a function used to convert strings to an array of bytes within 
built-in functions. So something that expected a string is being given a 
memoryview object. But it's not possible to guess what or why, and this 
isn't the place to explore your code.

Python-dev is about developing the language. Python-list is the place to 
ask questions about using the language. However, good hunting!

Jeff Allen

On 14/12/2016 12:09, Sesha Narayanan Subbiah wrote:
>
> Thanks Rob. I will try upgrade to 2.7.12. Any idea of this memory view 
> object that has been back ported to 2.7 can be disabled in any way?
>
> Thanks
> Regards
> Sesha
>
>


From victor.stinner at gmail.com  Thu Dec 15 03:45:37 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 15 Dec 2016 09:45:37 +0100
Subject: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
In-Reply-To: <o2g879$89u$1@blaine.gmane.org>
References: <CAMpsgwbHYAa_kshEBgZcZerywdMpV779P4jT4ncyiNPOdC1WJA@mail.gmail.com>
 <o2g879$89u$1@blaine.gmane.org>
Message-ID: <CAMpsgwa7M4Hn2CPTV2PnD3OOmrg9axMexdWxi46aX2hF=nb89w@mail.gmail.com>

Hi,

2016-12-10 7:43 GMT+01:00 Serhiy Storchaka <storchaka at gmail.com>:
> It is documented for Py_BuildValue(), and the documentation of
> PyObject_CallFunction() refers to Py_BuildValue().

You're right, but even if I read the documentation of Py_BuildValue()
every week, I never noticed that PyObject_CallFunction() behaves
differently if the result of Py_BuildValue() is a tuple or not. It is
not explicit in the PyObject_CallFunction() documentation.

Anyway, as I wrote, it would be a bad idea to change the behaviour, it
would break too much C code in the wild, so I just proposed a patch to
enhance the documentation:
http://bugs.python.org/issue28977


> I just found that in spite of your changes of parameter names, the
> documentation still have old names:
>
>     PyObject* PyObject_CallMethod(PyObject *o, const char *method, const
> char *format, ...)

Ah? It's possible that I forgot to update the documentation of some
functions. But sorry, I don't see where. Can you point me which file
is outdated please?

Since I finished to "cleanup abstract.h" (issue #28838), I will now
work on updating the documentation (doc in .rst files and comments in
.h files) of functions of the PyObject_Call() family. At least, make
sure that .rst and .h almost contain the same doc ;-)

Victor

From storchaka at gmail.com  Thu Dec 15 04:46:52 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 11:46:52 +0200
Subject: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
In-Reply-To: <CAMpsgwa7M4Hn2CPTV2PnD3OOmrg9axMexdWxi46aX2hF=nb89w@mail.gmail.com>
References: <CAMpsgwbHYAa_kshEBgZcZerywdMpV779P4jT4ncyiNPOdC1WJA@mail.gmail.com>
 <o2g879$89u$1@blaine.gmane.org>
 <CAMpsgwa7M4Hn2CPTV2PnD3OOmrg9axMexdWxi46aX2hF=nb89w@mail.gmail.com>
Message-ID: <CAAuNNr7K6-G2aQC5vhbtaObA3kK6sSL=O613+5YYAi4XvvrP-A@mail.gmail.com>

On 15.12.16 10:45, Victor Stinner wrote:
> Ah? It's possible that I forgot to update the documentation of some
> functions. But sorry, I don't see where. Can you point me which file
> is outdated please?

https://docs.python.org/3/c-api/object.html#c.PyObject_CallMethod

Seems online documentation is not updated.

From victor.stinner at gmail.com  Thu Dec 15 04:54:36 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 15 Dec 2016 10:54:36 +0100
Subject: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
In-Reply-To: <CAAuNNr7K6-G2aQC5vhbtaObA3kK6sSL=O613+5YYAi4XvvrP-A@mail.gmail.com>
References: <CAMpsgwbHYAa_kshEBgZcZerywdMpV779P4jT4ncyiNPOdC1WJA@mail.gmail.com>
 <o2g879$89u$1@blaine.gmane.org>
 <CAMpsgwa7M4Hn2CPTV2PnD3OOmrg9axMexdWxi46aX2hF=nb89w@mail.gmail.com>
 <CAAuNNr7K6-G2aQC5vhbtaObA3kK6sSL=O613+5YYAi4XvvrP-A@mail.gmail.com>
Message-ID: <CAMpsgwb6en+rriLsH6CKBPqKTg7f-6Wi9X_Q0nWiMJ-84xfPsg@mail.gmail.com>

2016-12-15 10:46 GMT+01:00 Serhiy Storchaka <storchaka at gmail.com>:
> https://docs.python.org/3/c-api/object.html#c.PyObject_CallMethod
>
> Seems online documentation is not updated.

"Last updated on Dec 08, 2016."

Oh, right. No idea what/who compiles the documentation. I expected at
least one build per day?

Someone also proposed to have a mirror of the CPython documentation on
readthedocs.

Victor

From victor.stinner at gmail.com  Thu Dec 15 05:00:08 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 15 Dec 2016 11:00:08 +0100
Subject: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
In-Reply-To: <CAMpsgwb6en+rriLsH6CKBPqKTg7f-6Wi9X_Q0nWiMJ-84xfPsg@mail.gmail.com>
References: <CAMpsgwbHYAa_kshEBgZcZerywdMpV779P4jT4ncyiNPOdC1WJA@mail.gmail.com>
 <o2g879$89u$1@blaine.gmane.org>
 <CAMpsgwa7M4Hn2CPTV2PnD3OOmrg9axMexdWxi46aX2hF=nb89w@mail.gmail.com>
 <CAAuNNr7K6-G2aQC5vhbtaObA3kK6sSL=O613+5YYAi4XvvrP-A@mail.gmail.com>
 <CAMpsgwb6en+rriLsH6CKBPqKTg7f-6Wi9X_Q0nWiMJ-84xfPsg@mail.gmail.com>
Message-ID: <CAMpsgwafMV+mHAw9KKJDX=HovUOsRqBVhAQVtr_k3_iDrx9ytQ@mail.gmail.com>

2016-12-15 10:54 GMT+01:00 Victor Stinner <victor.stinner at gmail.com>:
> Oh, right. No idea what/who compiles the documentation. I expected at
> least one build per day?

I am told that it can be related to
https://github.com/python/docsbuild-scripts/pull/7

Victor

From victor.stinner at gmail.com  Thu Dec 15 05:22:10 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 15 Dec 2016 11:22:10 +0100
Subject: [Python-Dev] Cleanup of abstract.h header
Message-ID: <CAMpsgwZnE7pePvB611cCYgaMF0Rk_Bma+FDCOyh9qEJEH6+DXA@mail.gmail.com>

Hi,

I made multiple changes to the Include/abstract.h header file, because
it was inconsistent in different manners:

* Parameter names of functions of the PyObject_Call family were
inconsistent: "func" versus "callable" for a Python callable object
for example (sometimes, .c and .h files were inconsistent too)

* Only this header file used an indentation of 4 spaces in the whole space

* Only this header used comments *after* the function declaration and
with a newline between the comment and the declaration. Other headers
use a comment *before* the declaration and no newline.

* Some comments were far (100 lines) from function declaration, so it
wasn't possible anymore to understand these comments.

* Other tiny changes

Before:
https://hg.python.org/cpython/file/f692dafe6797/Include/abstract.h

Now:
https://hg.python.org/cpython/file/c4bcca326c0a/Include/abstract.h

(Not sure that it's easy to compare such long header file, ~1 200
lines, in a web browser.)

See http://bugs.python.org/issue28838 for more information.


Serhiy Storchaka was opposed to these changes, some extract of his comments:

* "Isn't this just a lot of churn for not a lot of benefit?" - Eric V.
Smith asked the same question
* "It breaks "hg annotation" and makes harder researching the history
of the file"

I already pushed all my changes anyway, but Serhiy asked me to discuss
these changes on Python-Dev, so here I am.


I decided to cleanup abstract.h because I had to modify it multiple
times last 2 years, especially when I added new functions for fast
calls, and I was always surprised and confused by the style of header.
I didn't know how to format my code, and it seems like I also
introduced some inconsistent coding style in the newly added code.

For the first change that I made recently, normalizing parameter
names, I first pushed directly a change without review, but Serhiy
asked me on this list to revert it. So I reverted the change and
continued the discussion on the issue #28838. We agreed on better
names, and so I pushed a different change.

Victor

From nad at python.org  Fri Dec 16 02:48:00 2016
From: nad at python.org (Ned Deily)
Date: Fri, 16 Dec 2016 02:48:00 -0500
Subject: [Python-Dev] Python 3.6.0rc2 coming soon, 3.6.0 final now 2016-12-23
Message-ID: <40659694-6ADF-472D-8792-C61CB0B58FED@python.org>

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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at python.org>
date:        Thu Dec 15 23:20:48 2016 -0500
files:       Misc/NEWS
description:
Issue #28898: add Misc/NEWS entry

--
  Ned Deily
  nad at python.org -- []


From benjamin at python.org  Fri Dec 16 02:51:51 2016
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 15 Dec 2016 23:51:51 -0800
Subject: [Python-Dev] Cleanup of abstract.h header
In-Reply-To: <CAMpsgwZnE7pePvB611cCYgaMF0Rk_Bma+FDCOyh9qEJEH6+DXA@mail.gmail.com>
References: <CAMpsgwZnE7pePvB611cCYgaMF0Rk_Bma+FDCOyh9qEJEH6+DXA@mail.gmail.com>
Message-ID: <1481874711.3416691.820916545.6F2B8099@webmail.messagingengine.com>

I think it looks better. Thank you.

On Thu, Dec 15, 2016, at 02:22, Victor Stinner wrote:
> Hi,
> 
> I made multiple changes to the Include/abstract.h header file, because
> it was inconsistent in different manners:
> 
> * Parameter names of functions of the PyObject_Call family were
> inconsistent: "func" versus "callable" for a Python callable object
> for example (sometimes, .c and .h files were inconsistent too)
> 
> * Only this header file used an indentation of 4 spaces in the whole
> space
> 
> * Only this header used comments *after* the function declaration and
> with a newline between the comment and the declaration. Other headers
> use a comment *before* the declaration and no newline.
> 
> * Some comments were far (100 lines) from function declaration, so it
> wasn't possible anymore to understand these comments.
> 
> * Other tiny changes
> 
> Before:
> https://hg.python.org/cpython/file/f692dafe6797/Include/abstract.h
> 
> Now:
> https://hg.python.org/cpython/file/c4bcca326c0a/Include/abstract.h
> 
> (Not sure that it's easy to compare such long header file, ~1 200
> lines, in a web browser.)
> 
> See http://bugs.python.org/issue28838 for more information.
> 
> 
> Serhiy Storchaka was opposed to these changes, some extract of his
> comments:
> 
> * "Isn't this just a lot of churn for not a lot of benefit?" - Eric V.
> Smith asked the same question
> * "It breaks "hg annotation" and makes harder researching the history
> of the file"
> 
> I already pushed all my changes anyway, but Serhiy asked me to discuss
> these changes on Python-Dev, so here I am.
> 
> 
> I decided to cleanup abstract.h because I had to modify it multiple
> times last 2 years, especially when I added new functions for fast
> calls, and I was always surprised and confused by the style of header.
> I didn't know how to format my code, and it seems like I also
> introduced some inconsistent coding style in the newly added code.
> 
> For the first change that I made recently, normalizing parameter
> names, I first pushed directly a change without review, but Serhiy
> asked me on this list to revert it. So I reverted the change and
> continued the discussion on the issue #28838. We agreed on better
> names, and so I pushed a different change.
> 
> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/benjamin%40python.org

From victor.stinner at gmail.com  Fri Dec 16 04:23:44 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 16 Dec 2016 10:23:44 +0100
Subject: [Python-Dev] Python 3.6.0rc2 coming soon,
 3.6.0 final now 2016-12-23
In-Reply-To: <40659694-6ADF-472D-8792-C61CB0B58FED@python.org>
References: <40659694-6ADF-472D-8792-C61CB0B58FED@python.org>
Message-ID: <CAMpsgwa4GqP-+EwdQ4Cn3HKc_Hu9Ek2-H4GXMzxS4znA0dCo=A@mail.gmail.com>

Ned Deily:
> 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.

No need to apologize, you are doing a great job! I'm not surprised at
all that major bugs are still found just a few days before the final
release: many people wait just before a final release to test their
code.

I'm happy that such bugs are found _before_ a release. Bugs like "my
applications takes 4 GB of memory with Python 3.6 but 40 MB with
Python 3.5" (#28147) seem so big that it would be a shame to "ship"
such bug in a final release!


> 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.)

test_gdb is broken in the RC1. To fix test_gdb, I convinced Ned to
also cherry-pick:
---
changeset:   105342:752863f96fb8
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Tue Nov 22 22:53:18 2016 +0100
files:       Lib/test/test_gdb.py Tools/gdb/libpython.py
description:
Issue #28770: Update python-gdb.py for fastcalls

Frame.is_other_python_frame() now also handles _PyCFunction_FastCallDict()
frames.

Thanks to the new code to handle fast calls, python-gdb.py is now also able to
detect the <built-in id method of module ...> frame.
----

Victor

From solipsis at pitrou.net  Fri Dec 16 05:24:37 2016
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 16 Dec 2016 11:24:37 +0100
Subject: [Python-Dev] Cleanup of abstract.h header
References: <CAMpsgwZnE7pePvB611cCYgaMF0Rk_Bma+FDCOyh9qEJEH6+DXA@mail.gmail.com>
Message-ID: <20161216112437.0faaaedc@fsol>

On Thu, 15 Dec 2016 11:22:10 +0100
Victor Stinner <victor.stinner at gmail.com> wrote:
> 
> Before:
> https://hg.python.org/cpython/file/f692dafe6797/Include/abstract.h
> 
> Now:
> https://hg.python.org/cpython/file/c4bcca326c0a/Include/abstract.h

Since you are cleaning up, you could remove the whole "PROPOSAL: A
Generic Python Object Interface for Python C Modules" introduction,
which isn't very interesting to read today.

Regards

Antoine.



From stephane at wirtel.be  Fri Dec 16 09:49:33 2016
From: stephane at wirtel.be (Stephane Wirtel)
Date: Fri, 16 Dec 2016 15:49:33 +0100
Subject: [Python-Dev] Last call for the Call For Proposals of PythonFOSDEM
 2017
Message-ID: <20161216144933.qquqd4ljjpqkuw3p@sg1>

Hello, this week-end is the last two days for the Call For Proposals of 
PythonFOSDEM 2017. We have received a lot of topics, but if you want to 
become a speaker and that you have a very cool topic to submit, please 
don't hesite and send us your proposal.

Deadline is 2016-12-18.

Stephane


Call For Proposals
==================

This is the official call for sessions for the Python devroom at FOSDEM 2017.

FOSDEM is the Free and Open source Software Developers' European Meeting, a free
and non-commercial two-day week-end that offers open source contributors a place
to meet, share ideas and collaborate.

It's the biggest event in Europe with +5000 hackers, +400 speakers.

For this edition, Python will be represented by its Community.
If you want to discuss with a lot of Python Users, it's the place to be!

Important dates
===============

* Submission deadlines: 2016-12-18
* Acceptance notifications: 2016-12-23

Practical
=========

* The duration for talks will be 30 minutes, including presentations and
questions and answers.
* Presentation can be recorded and streamed, sending your proposal implies
giving permission to be recorded.
* A mailing list for the Python devroom is available for discussions about
devroom organisation. You can register at this address:
https://lists.fosdem.org/listinfo/python-devroom

How to submit
=============

All submissions are made in the Pentabarf event planning tool at
https://penta.fosdem.org/submission/FOSDEM17

When submitting your talk in Pentabarf, make sure to select the Python devroom
as the Track.

Of course, if you already have a user account, please reuse it.

Questions
=========

Any questions, please send an email to info AT python-fosdem DOT org

Thank you for submitting your sessions and see you soon in Brussels to talk
about Python.

If you want to keep informed for this edition, you can follow our twitter
account @PythonFOSDEM.

* FOSDEM 2017: https://fosdem.org/2017
* Python Devroom: http://python-fosdem.org
* Twitter: https://twitter.com/PythonFOSDEM


Stephane

-- 
St?phane Wirtel - http://wirtel.be - @matrixise

From victor.stinner at gmail.com  Fri Dec 16 10:03:38 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 16 Dec 2016 16:03:38 +0100
Subject: [Python-Dev] Cleanup of abstract.h header
In-Reply-To: <20161216112437.0faaaedc@fsol>
References: <CAMpsgwZnE7pePvB611cCYgaMF0Rk_Bma+FDCOyh9qEJEH6+DXA@mail.gmail.com>
 <20161216112437.0faaaedc@fsol>
Message-ID: <CAMpsgwb68gMAnRctoxSa17G63bcx7gkH=hsMwjDzr9e9F=PCxA@mail.gmail.com>

2016-12-16 11:24 GMT+01:00 Antoine Pitrou <solipsis at pitrou.net>:
> Since you are cleaning up, you could remove the whole "PROPOSAL: A
> Generic Python Object Interface for Python C Modules" introduction,
> which isn't very interesting to read today.

Ah right, I noticed this huge comment but I didn't understand the
purpose. IMHO https://docs.python.org/dev/c-api/ is now a much better
documentation for the Python C API. I agree to remove the long
introduction.

By the way, I'm surprised by the "many thanks to Jim Fulton" in the
comment, since I'm not sure to what it is referred to. But in case of
doubt, I prefer to keep it :-)

/* Abstract Object Interface (many thanks to Jim Fulton) */

Victor

From guido at python.org  Fri Dec 16 11:44:12 2016
From: guido at python.org (Guido van Rossum)
Date: Fri, 16 Dec 2016 08:44:12 -0800
Subject: [Python-Dev] Cleanup of abstract.h header
In-Reply-To: <CAMpsgwb68gMAnRctoxSa17G63bcx7gkH=hsMwjDzr9e9F=PCxA@mail.gmail.com>
References: <CAMpsgwZnE7pePvB611cCYgaMF0Rk_Bma+FDCOyh9qEJEH6+DXA@mail.gmail.com>
 <20161216112437.0faaaedc@fsol>
 <CAMpsgwb68gMAnRctoxSa17G63bcx7gkH=hsMwjDzr9e9F=PCxA@mail.gmail.com>
Message-ID: <CAP7+vJ+2iJBn+8CerKwJ7oH_TKxpoSwM-V17=xev3gojeiyWDw@mail.gmail.com>

Many eons ago, Jim created abstract.h. The proposal comment (which you're
right to be cutting out now) was his and at some point it was accepted, but
I just copied-pasted the whole text into abstract.h. So yes, please keep
the "many thanks to Jim Fulton" in there!

On Fri, Dec 16, 2016 at 7:03 AM, Victor Stinner <victor.stinner at gmail.com>
wrote:

> 2016-12-16 11:24 GMT+01:00 Antoine Pitrou <solipsis at pitrou.net>:
> > Since you are cleaning up, you could remove the whole "PROPOSAL: A
> > Generic Python Object Interface for Python C Modules" introduction,
> > which isn't very interesting to read today.
>
> Ah right, I noticed this huge comment but I didn't understand the
> purpose. IMHO https://docs.python.org/dev/c-api/ is now a much better
> documentation for the Python C API. I agree to remove the long
> introduction.
>
> By the way, I'm surprised by the "many thanks to Jim Fulton" in the
> comment, since I'm not sure to what it is referred to. But in case of
> doubt, I prefer to keep it :-)
>
> /* Abstract Object Interface (many thanks to Jim Fulton) */
>
> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161216/fe8a3f4c/attachment.html>

From status at bugs.python.org  Fri Dec 16 12:09:06 2016
From: status at bugs.python.org (Python tracker)
Date: Fri, 16 Dec 2016 18:09:06 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20161216170906.B481C56416@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2016-12-09 - 2016-12-16)
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    5639 (+18)
  closed 35107 (+50)
  total  40746 (+68)

Open issues with patches: 2443 


Issues opened (53)
==================

#20754: Distribution.parse_config_files uses interpolation since Pytho
http://bugs.python.org/issue20754  reopened by jason.coombs

#28770: Update python-gdb.py for fastcalls
http://bugs.python.org/issue28770  reopened by ned.deily

#28923: Nonexisting encoding specified in Tix.py
http://bugs.python.org/issue28923  opened by Ivan.Pozdeev

#28926: subprocess.Popen + Sqlalchemy doesn't wait for process
http://bugs.python.org/issue28926  opened by s1113950

#28927: bytes.fromhex should ignore all whitespace
http://bugs.python.org/issue28927  opened by nneonneo

#28929: Provide a link from documentation back to its source file
http://bugs.python.org/issue28929  opened by brett.cannon

#28931: urllib ignores FTP 226 response, breaking further FTP requests
http://bugs.python.org/issue28931  opened by Ivan.Pozdeev

#28932: Fail compile Python 3.6.0rc1 on OpenBSD 6.0
http://bugs.python.org/issue28932  opened by shadchin

#28934: _mboxMMDF#get_message should delegate to get_bytes
http://bugs.python.org/issue28934  opened by bpoaugust

#28936: test_global_err_then_warn in test_syntax is no longer valid
http://bugs.python.org/issue28936  opened by serhiy.storchaka

#28937: str.split(): remove empty strings when sep is not None
http://bugs.python.org/issue28937  opened by barry

#28938: match_hostname treats SAN IP address as DNS name and fails to 
http://bugs.python.org/issue28938  opened by noxxi

#28940: __length_hint__ isn't a hint for list()
http://bugs.python.org/issue28940  opened by ronaldoussoren

#28941: Update the link to Source Code in Python Docs from hg to githu
http://bugs.python.org/issue28941  opened by Mariatta

#28942: await expressions in f-strings
http://bugs.python.org/issue28942  opened by Adam Gregory

#28945: get_boundary invokes unquote twice
http://bugs.python.org/issue28945  opened by bpoaugust

#28948: Facing issue while running Python 3.6.0rc1 windows x86-64 web 
http://bugs.python.org/issue28948  opened by arpit arora

#28949: Stdlib modules disappear from file system
http://bugs.python.org/issue28949  opened by jason.coombs

#28950: regrtest: -j0 fails the check -j is not allowed together with 
http://bugs.python.org/issue28950  opened by xiang.zhang

#28951: re.flags not documented in Module Contents as promised.
http://bugs.python.org/issue28951  opened by 4Dummies

#28952: csv.Sniffer().sniff(0 returns a value without the "strict" att
http://bugs.python.org/issue28952  opened by 4Dummies

#28953: Use `raise from` when raising new IncompleteRead
http://bugs.python.org/issue28953  opened by cool-RR

#28954: Incorrect EBNF rule of keywords_arguments
http://bugs.python.org/issue28954  opened by woo yoo

#28955: Not matched behavior of numeric comparison with the documentat
http://bugs.python.org/issue28955  opened by woo yoo

#28956: return minimum of modes for a multimodal distribution instead 
http://bugs.python.org/issue28956  opened by sria91

#28957: undefined symbol: PyUnicodeUCS2_FromUnicode when executing any
http://bugs.python.org/issue28957  opened by rkommine

#28958: Python should return comperhansive error when SSLContext canno
http://bugs.python.org/issue28958  opened by Ilya.Kulakov

#28960: Small typo in Thread.join docs
http://bugs.python.org/issue28960  opened by rcorre

#28961: unittest.mock._Call ignores `name` parameter
http://bugs.python.org/issue28961  opened by Jiajun Huang

#28962: Crash when throwing an exception with a malicious __hash__ ove
http://bugs.python.org/issue28962  opened by Jelle Zijlstra

#28963: Use-after-free in _asyncio_Future_remove_done_callback() of _a
http://bugs.python.org/issue28963  opened by Ned Williamson

#28964: AST literal_eval exceptions provide no information about line 
http://bugs.python.org/issue28964  opened by stevemerritt

#28965: Multiprocessing spawn/forkserver fails to pass Queues
http://bugs.python.org/issue28965  opened by Sean Murphy

#28967: copy.copy fails on threading.local subclass
http://bugs.python.org/issue28967  opened by Jelle Zijlstra

#28968: xml rpc server fails with connection reset by peer error no 10
http://bugs.python.org/issue28968  opened by manu

#28969: lru_cache is not threadsafe
http://bugs.python.org/issue28969  opened by Nicolas Savoire

#28970: ctypes.from_buffer counterpart to actively remove the mapping
http://bugs.python.org/issue28970  opened by frispete

#28971: nntplib is broken when responses are longer than _MAXLINE
http://bugs.python.org/issue28971  opened by xdegaye

#28972: Document all "python -m" utilities
http://bugs.python.org/issue28972  opened by tebeka

#28973: The fact that multiprocess.Queue uses serialization should be 
http://bugs.python.org/issue28973  opened by Bernhard10

#28974: Make default __format__ be equivalent to __str__
http://bugs.python.org/issue28974  opened by serhiy.storchaka

#28977: Document PyObject_CallFunction() special case more explicitly
http://bugs.python.org/issue28977  opened by haypo

#28978: a redundant right  parentheses in the EBNF rules of parameter_
http://bugs.python.org/issue28978  opened by woo yoo

#28980: ResourceWarning when imorting antigravity in 3.6
http://bugs.python.org/issue28980  opened by levkivskyi

#28981: distutils/check.py overzealous catch block hides errors
http://bugs.python.org/issue28981  opened by posita

#28982: multiprocessing.Queue.get(block=True, timeout=0) always raises
http://bugs.python.org/issue28982  opened by Ryan Brindley

#28983: Python 3.5.2 won't install on my computer
http://bugs.python.org/issue28983  opened by Rhesa Browning

#28985: sqlite3 authorizer codes constants not up to date
http://bugs.python.org/issue28985  opened by gumblex

#28986: Docs should say set.update takes iterable
http://bugs.python.org/issue28986  opened by nre3976

#28987: Remove typo in whats new entry on Descriptor Protocol Enhancem
http://bugs.python.org/issue28987  opened by Jim Fasarakis-Hilliard

#28988: Switch dict and set structures to PyVarObject
http://bugs.python.org/issue28988  opened by serhiy.storchaka

#28989: .dll files missing
http://bugs.python.org/issue28989  opened by Gabriel Lopez

#28990: asyncio SSL hangs if connection is closed before handshake com
http://bugs.python.org/issue28990  opened by yselivanov



Most recent 15 issues with no replies (15)
==========================================

#28987: Remove typo in whats new entry on Descriptor Protocol Enhancem
http://bugs.python.org/issue28987

#28981: distutils/check.py overzealous catch block hides errors
http://bugs.python.org/issue28981

#28974: Make default __format__ be equivalent to __str__
http://bugs.python.org/issue28974

#28970: ctypes.from_buffer counterpart to actively remove the mapping
http://bugs.python.org/issue28970

#28964: AST literal_eval exceptions provide no information about line 
http://bugs.python.org/issue28964

#28958: Python should return comperhansive error when SSLContext canno
http://bugs.python.org/issue28958

#28957: undefined symbol: PyUnicodeUCS2_FromUnicode when executing any
http://bugs.python.org/issue28957

#28954: Incorrect EBNF rule of keywords_arguments
http://bugs.python.org/issue28954

#28953: Use `raise from` when raising new IncompleteRead
http://bugs.python.org/issue28953

#28952: csv.Sniffer().sniff(0 returns a value without the "strict" att
http://bugs.python.org/issue28952

#28945: get_boundary invokes unquote twice
http://bugs.python.org/issue28945

#28940: __length_hint__ isn't a hint for list()
http://bugs.python.org/issue28940

#28932: Fail compile Python 3.6.0rc1 on OpenBSD 6.0
http://bugs.python.org/issue28932

#28926: subprocess.Popen + Sqlalchemy doesn't wait for process
http://bugs.python.org/issue28926

#28913: "Fatal Python error: Cannot recover from stack overflow." from
http://bugs.python.org/issue28913



Most recent 15 issues waiting for review (15)
=============================================

#28988: Switch dict and set structures to PyVarObject
http://bugs.python.org/issue28988

#28987: Remove typo in whats new entry on Descriptor Protocol Enhancem
http://bugs.python.org/issue28987

#28985: sqlite3 authorizer codes constants not up to date
http://bugs.python.org/issue28985

#28977: Document PyObject_CallFunction() special case more explicitly
http://bugs.python.org/issue28977

#28974: Make default __format__ be equivalent to __str__
http://bugs.python.org/issue28974

#28971: nntplib is broken when responses are longer than _MAXLINE
http://bugs.python.org/issue28971

#28969: lru_cache is not threadsafe
http://bugs.python.org/issue28969

#28964: AST literal_eval exceptions provide no information about line 
http://bugs.python.org/issue28964

#28963: Use-after-free in _asyncio_Future_remove_done_callback() of _a
http://bugs.python.org/issue28963

#28961: unittest.mock._Call ignores `name` parameter
http://bugs.python.org/issue28961

#28960: Small typo in Thread.join docs
http://bugs.python.org/issue28960

#28953: Use `raise from` when raising new IncompleteRead
http://bugs.python.org/issue28953

#28950: regrtest: -j0 fails the check -j is not allowed together with 
http://bugs.python.org/issue28950

#28941: Update the link to Source Code in Python Docs from hg to githu
http://bugs.python.org/issue28941

#28937: str.split(): remove empty strings when sep is not None
http://bugs.python.org/issue28937



Top 10 most discussed issues (10)
=================================

#28937: str.split(): remove empty strings when sep is not None
http://bugs.python.org/issue28937  22 msgs

#28949: Stdlib modules disappear from file system
http://bugs.python.org/issue28949  20 msgs

#28147: Unbounded memory growth resizing split-table dicts
http://bugs.python.org/issue28147  15 msgs

#5322: Python 2.6 object.__new__ argument calling autodetection fault
http://bugs.python.org/issue5322  12 msgs

#26110: Speedup method calls 1.2x
http://bugs.python.org/issue26110  12 msgs

#28180: sys.getfilesystemencoding() should default to utf-8
http://bugs.python.org/issue28180  11 msgs

#28190: Cross-build _curses failed if host ncurses headers and target 
http://bugs.python.org/issue28190  11 msgs

#28754: Argument Clinic for bisect.bisect_left
http://bugs.python.org/issue28754  10 msgs

#28971: nntplib is broken when responses are longer than _MAXLINE
http://bugs.python.org/issue28971  10 msgs

#25458: ftplib: command response shift - mismatch
http://bugs.python.org/issue25458   9 msgs



Issues closed (50)
==================

#16255: subrocess.Popen needs /bin/sh but Android only has /system/bin
http://bugs.python.org/issue16255  closed by xdegaye

#17430: missed peephole optimization
http://bugs.python.org/issue17430  closed by serhiy.storchaka

#21368: Check for systemd locale on startup if current locale is set t
http://bugs.python.org/issue21368  closed by ncoghlan

#23971: dict(list) and dict.fromkeys() doesn't account for 2/3 fill ra
http://bugs.python.org/issue23971  closed by inada.naoki

#26483: docs unclear on difference between str.isdigit() and str.isdec
http://bugs.python.org/issue26483  closed by martin.panter

#26856: android does not have pwd.getpwall()
http://bugs.python.org/issue26856  closed by xdegaye

#26919: on Android python fails to decode/encode command line argument
http://bugs.python.org/issue26919  closed by xdegaye

#26936: android: test_socket fails
http://bugs.python.org/issue26936  closed by xdegaye

#28089: asyncio: Document that TCP_NODELAY is now used by default
http://bugs.python.org/issue28089  closed by yselivanov

#28090: Document PEP 530
http://bugs.python.org/issue28090  closed by yselivanov

#28091: Document PEP 525 & 530
http://bugs.python.org/issue28091  closed by yselivanov

#28424: pkgutil.get_data() doesn't work with namespace packages
http://bugs.python.org/issue28424  closed by brett.cannon

#28680: bdist_wininst generated 64-bit executable looks for 3.5-32
http://bugs.python.org/issue28680  closed by steve.dower

#28683: bind() on a unix socket raises PermissionError on Android for 
http://bugs.python.org/issue28683  closed by xdegaye

#28689: OpenSSL 1.1.0c test failures
http://bugs.python.org/issue28689  closed by ned.deily

#28755: Rework syntax highlighing in howto/clinic.rst
http://bugs.python.org/issue28755  closed by martin.panter

#28759: access to mkfifo, mknod and hard links is controled by SELinux
http://bugs.python.org/issue28759  closed by xdegaye

#28764: test_mailbox fails when run as a non-root user on Android API 
http://bugs.python.org/issue28764  closed by xdegaye

#28771: Update documented signatures of tp_get/setattr
http://bugs.python.org/issue28771  closed by martin.panter

#28779: set_forkserver_preload() can crash the forkserver if preloaded
http://bugs.python.org/issue28779  closed by pitrou

#28794: inspect.isasyncgen and inspect.isasyncgenfunction aren't docum
http://bugs.python.org/issue28794  closed by berker.peksag

#28820: Typo in section 6 of the Python 3.4 documentation
http://bugs.python.org/issue28820  closed by martin.panter

#28838: Using consistent naming for arguments of "call" functions (C A
http://bugs.python.org/issue28838  closed by haypo

#28849: do not define sys.implementation._multiarch on Android
http://bugs.python.org/issue28849  closed by xdegaye

#28896: Embeddable zip allows Windows registry to override module loca
http://bugs.python.org/issue28896  closed by steve.dower

#28898: Can't compile gdb with Python 3.6
http://bugs.python.org/issue28898  closed by ned.deily

#28900: update 'docs for other versions'
http://bugs.python.org/issue28900  closed by ned.deily

#28912: collections.abc.OrderedMapping
http://bugs.python.org/issue28912  closed by rhettinger

#28916: Not matched behavior of modulo operator % with the description
http://bugs.python.org/issue28916  closed by martin.panter

#28918: cross compiling xxlimited fails with "Py_LIMITED_API is incomp
http://bugs.python.org/issue28918  closed by xdegaye

#28919: Simplify `_copy_func_details` in unittest.mock
http://bugs.python.org/issue28919  closed by berker.peksag

#28920: Dangerous usage of "O" format string in _asynciomodule.c
http://bugs.python.org/issue28920  closed by haypo

#28922: Add fixer for "import exceptions"
http://bugs.python.org/issue28922  closed by berker.peksag

#28924: Inline PyEval_EvalFrameEx() in callers
http://bugs.python.org/issue28924  closed by haypo

#28925: Confusing exception from cPickle on reduce failure
http://bugs.python.org/issue28925  closed by serhiy.storchaka

#28928: IDLE crashes when opening .py file from Finder
http://bugs.python.org/issue28928  closed by ned.deily

#28930: bytes_methods.c won't recompile if related stringlib/* changed
http://bugs.python.org/issue28930  closed by xiang.zhang

#28933: AC: Accept None as a Py_ssize_t default value
http://bugs.python.org/issue28933  closed by mdk

#28935: distutils use ConfigParser in Python 3.x and fails to parse se
http://bugs.python.org/issue28935  closed by jason.coombs

#28939: Groupby Is Roughly Equivalent To ...
http://bugs.python.org/issue28939  closed by greg.solomon

#28943: Use PyUnicode_MAX_CHAR_VALUE instead of PyUnicode_KIND in some
http://bugs.python.org/issue28943  closed by xiang.zhang

#28944: A lack of line 6
http://bugs.python.org/issue28944  closed by berker.peksag

#28946: AttributeError: module 'signal' has no attribute 'SIGALRM'
http://bugs.python.org/issue28946  closed by dd

#28947: Facing issue while running Python 3.6.0rc1 windows x86-64 web 
http://bugs.python.org/issue28947  closed by steve.dower

#28959: Add a macro for dict size
http://bugs.python.org/issue28959  closed by serhiy.storchaka

#28966: Menu.add_checkbutton has no checkmark on OS X
http://bugs.python.org/issue28966  closed by ned.deily

#28975: os.walk generator giving inconsistent results
http://bugs.python.org/issue28975  closed by Colin David Chen

#28976: incorrect description that dose not conform to the actual beha
http://bugs.python.org/issue28976  closed by r.david.murray

#28979: What's New entry on compact dict mentions "faster" implementat
http://bugs.python.org/issue28979  closed by ned.deily

#28984: json.dump + indent creates trailing extra spaces
http://bugs.python.org/issue28984  closed by ned.deily

From brett at python.org  Fri Dec 16 13:49:48 2016
From: brett at python.org (Brett Cannon)
Date: Fri, 16 Dec 2016 18:49:48 +0000
Subject: [Python-Dev] Blockers on GitHub migration and open windows to
 migrate
Message-ID: <CAP1=2W4LQ4L8R_C-Q2OdQrMUqxzpyjqWS25VS9-yMSj6Pv+oTw@mail.gmail.com>

[sending this independently to python-dev and core-workflow]

I have promised Ned that we will not migrate before 3.6.0 is released and
not for a week following in case an emergency 3.6.1 is necessary. I also
promised Larry we wouldn't migrate the week before 3.5.3 is released. That
means the windows for migrating are 2016-12-30 to 2017-01-09, and then any
time after 2016-01-16 (this of course assumes all release schedules don't
slip).

I'm now on vacation until January 3 so I will have time to work on the
migration some more. I will port hg.python.org/lookup to work with git, hg,
and svn probably this week or next. That leaves the only true blockers as
http://psf.upfronthosting.co.za/roundup/meta/issue589 and
http://psf.upfronthosting.co.za/roundup/meta/issue590 (webhook for PR to
issue and notifying an issue when a commit has occurred, respectively; we
already have a GitHub PR field on b.p.o for manual entry). Once those
changes to bugs.python.org land and have been tested live against the
GitHub mirror, we can do the migration (which will most likely take a day
or two). All other issues either require the repo to have already been
migrated and working or can wait post-migration (
https://www.python.org/dev/peps/pep-0512/#cpython-repo).

So if the above wasn't clear, if you want to help then please help with the
b.p.o issues as those are the remaining blockers I can't deal with on my
own. And I actually have GitHub-themed gifts I bought myself sitting under
my Xmas tree that I won't open until we migrate, so let's not take too
long. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161216/9980b21c/attachment.html>

From guido at python.org  Fri Dec 16 14:24:01 2016
From: guido at python.org (Guido van Rossum)
Date: Fri, 16 Dec 2016 11:24:01 -0800
Subject: [Python-Dev] Deprecate `from __future__ import unicode_literals`?
Message-ID: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>

I am beginning to think that `from __future__ import unicode_literals` does
more harm than good. I don't recall exactly why we introduced it, but with
the restoration of u"" literals in Python 3.3 we have a much better story
for writing straddling code that is unicode-correct.

The problem is that the future import does both too much and not enough --
it does too much because it changes literals to unicode even in contexts
where there is no benefit (e.g. the argument to getattr() -- I still hear
of code that breaks due to this occasionally) and at the same time it
doesn't do anything for strings that you read from files, receive from the
network, or even from other files that don't use the future import.

I wonder if we can add an official note to the 2.7 docs recommending
against it? (And maybe even to the 3.x docs if it's mentioned there at all.)

-- 
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161216/aeb0101d/attachment.html>

From robertc at robertcollins.net  Fri Dec 16 14:49:07 2016
From: robertc at robertcollins.net (Robert Collins)
Date: Sat, 17 Dec 2016 08:49:07 +1300
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
Message-ID: <CAJ3HoZ2mSh6GOwL8xt7r+Ftfn6rz2TJZAqmR4P_AaSn+LfR_Gg@mail.gmail.com>

On 17 December 2016 at 08:24, Guido van Rossum <guido at python.org> wrote:
> I am beginning to think that `from __future__ import unicode_literals` does
> more harm than good. I don't recall exactly why we introduced it, but with
> the restoration of u"" literals in Python 3.3 we have a much better story
> for writing straddling code that is unicode-correct.
>
> The problem is that the future import does both too much and not enough --
> it does too much because it changes literals to unicode even in contexts
> where there is no benefit (e.g. the argument to getattr() -- I still hear of
> code that breaks due to this occasionally) and at the same time it doesn't
> do anything for strings that you read from files, receive from the network,
> or even from other files that don't use the future import.
>
> I wonder if we can add an official note to the 2.7 docs recommending against
> it? (And maybe even to the 3.x docs if it's mentioned there at all.)

I think thats a good idea. I've found u"" to be entirely sufficient
and very robust.

Perhaps also have python2 -3 report on it?

-Rob

From xavier.combelle at gmail.com  Fri Dec 16 15:38:29 2016
From: xavier.combelle at gmail.com (Xavier Combelle)
Date: Fri, 16 Dec 2016 21:38:29 +0100
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
Message-ID: <b2551613-b891-7a58-b269-5a5465ed4b14@gmail.com>

I personally used it when I was forced to use python 2 and working
mainly with unicode processing (It is particularly handy when working
with json for example)


Le 16/12/2016 ? 20:24, Guido van Rossum a ?crit :
> I am beginning to think that `from __future__ import unicode_literals`
> does more harm than good. I don't recall exactly why we introduced it,
> but with the restoration of u"" literals in Python 3.3 we have a much
> better story for writing straddling code that is unicode-correct.
>
> The problem is that the future import does both too much and not
> enough -- it does too much because it changes literals to unicode even
> in contexts where there is no benefit (e.g. the argument to getattr()
> -- I still hear of code that breaks due to this occasionally) and at
> the same time it doesn't do anything for strings that you read from
> files, receive from the network, or even from other files that don't
> use the future import.
>
> I wonder if we can add an official note to the 2.7 docs recommending
> against it? (And maybe even to the 3.x docs if it's mentioned there at
> all.)
>
> -- 
> --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/xavier.combelle%40gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161216/76d3d352/attachment.html>

From ethan at stoneleaf.us  Fri Dec 16 16:07:01 2016
From: ethan at stoneleaf.us (Ethan Furman)
Date: Fri, 16 Dec 2016 13:07:01 -0800
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
Message-ID: <58545775.5050706@stoneleaf.us>

On 12/16/2016 11:24 AM, Guido van Rossum wrote:

> I am beginning to think that `from __future__ import unicode_literals` does
>  more harm than good. I don't recall exactly why we introduced it, but with
>  the restoration of u"" literals in Python 3.3 we have a much better story
>  for writing straddling code that is unicode-correct.

So cross-version code would be primarily 2.7 and 3.3+ ?  I can live with that.

--
~Ethan~

From rosuav at gmail.com  Fri Dec 16 16:17:27 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 17 Dec 2016 08:17:27 +1100
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <58545775.5050706@stoneleaf.us>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
 <58545775.5050706@stoneleaf.us>
Message-ID: <CAPTjJmoMfkm27bcBL1E0fWK=mfo_2v+nihAcFOPrys-UcgXaOA@mail.gmail.com>

On Sat, Dec 17, 2016 at 8:07 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
> On 12/16/2016 11:24 AM, Guido van Rossum wrote:
>
>> I am beginning to think that `from __future__ import unicode_literals`
>> does
>>  more harm than good. I don't recall exactly why we introduced it, but
>> with
>>  the restoration of u"" literals in Python 3.3 we have a much better story
>>  for writing straddling code that is unicode-correct.
>
>
> So cross-version code would be primarily 2.7 and 3.3+ ?  I can live with
> that.

Or 3.5+ so you get percent formatting for bytes.

+1 for deprecating unicode_literals; I don't remember ever using or wanting it.

ChrisA

From barry at python.org  Fri Dec 16 16:27:34 2016
From: barry at python.org (Barry Warsaw)
Date: Fri, 16 Dec 2016 16:27:34 -0500
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <58545775.5050706@stoneleaf.us>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
 <58545775.5050706@stoneleaf.us>
Message-ID: <20161216162734.1a7213bf.barry@wooz.org>

On Dec 16, 2016, at 01:07 PM, Ethan Furman wrote:

>On 12/16/2016 11:24 AM, Guido van Rossum wrote:
>
>> I am beginning to think that `from __future__ import unicode_literals` does
>>  more harm than good. I don't recall exactly why we introduced it, but with
>>  the restoration of u"" literals in Python 3.3 we have a much better story
>>  for writing straddling code that is unicode-correct.  
>
>So cross-version code would be primarily 2.7 and 3.3+ ?  I can live with that.

So can I.  I don't mind "silently" deprecating it, such as adding strong
admonitions against its use in the docs, but clearly it can't be removed (at
least until 3.7) and I worry about breaking existing code, even with a more
chatty DeprecationWarning.

At least in some circles, the problems of unicode_literals are known, but it's
still useful and it's used in lots of places.  Getting rid of cruft like this
is one of the more satisfying edits when dropping Python 2 support. :)

Cheers,
-Barry

From cory at lukasa.co.uk  Fri Dec 16 16:38:16 2016
From: cory at lukasa.co.uk (Cory Benfield)
Date: Fri, 16 Dec 2016 16:38:16 -0500
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <58545775.5050706@stoneleaf.us>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
 <58545775.5050706@stoneleaf.us>
Message-ID: <CE52CEE5-F2F0-4243-B807-B637AF2DF535@lukasa.co.uk>


> On 16 Dec 2016, at 16:07, Ethan Furman <ethan at stoneleaf.us> wrote:
> 
> On 12/16/2016 11:24 AM, Guido van Rossum wrote:
> 
>> I am beginning to think that `from __future__ import unicode_literals` does
>> more harm than good. I don't recall exactly why we introduced it, but with
>> the restoration of u"" literals in Python 3.3 we have a much better story
>> for writing straddling code that is unicode-correct.
> 
> So cross-version code would be primarily 2.7 and 3.3+ ?  I can live with that.

Speaking for third-party library authors, almost all cross-version code that does anything remotely close to a network is 2.7 and 3.3+. Requests dropped 3.2 support basically as soon as we could once 3.3?s unicode literals were restored, and since then I haven?t written anything that targets 3.2. It?s just too frustrating.

And while I?m shoving my oar in, I?ve never seen anyone be happy with using ?from __future__ import unicode_literals?. As others in this thread have said, it just points a loaded gun at your foot and lets you wait for it to go off.

Cory

From tseaver at palladion.com  Fri Dec 16 16:39:15 2016
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 16 Dec 2016 16:39:15 -0500
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <20161216162734.1a7213bf.barry@wooz.org>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
 <58545775.5050706@stoneleaf.us> <20161216162734.1a7213bf.barry@wooz.org>
Message-ID: <6a7a4391-d67e-7577-be53-f101c776b928@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/16/2016 04:27 PM, Barry Warsaw wrote:
> Getting rid of cruft like this is one of the more satisfying edits
> when dropping Python 2 support. :)

Ripping it out and replacing with explicit unicode literals is pretty
satisfying when straddling, too. ;)


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJYVF7+AAoJEPKpaDSJE9HYSF0P/Ax00KYJQpIQdr7U4vn3Sz6F
CpAfxIxR4uuZJMNwzxl1sBmsJ0xvoO2aldGwbbOzlvlbP1km4MlLfRC/ZFwoKWs0
yDA5xiUrwUGDPME6IEtTzn7CCk5INP6avX2zLkZg6qMfJ9Cd0VJkcJGAXE6CtAwS
swAEJcfeIhb+5gnyHHECLc6XC+LQPf6GHkD0im3ayACr73bMCvdHRYF7pJaZ/XWN
1WYbRlPup0//Ge0MbHAUdn8GwnEm+e2GB1roKEryaSBEHfhtDm1iKPjWeg/gic91
j76nTeQ0qepdjGjGAISiPersSPEW44bzXCSDLh6OfQAUtDqA9pWFbNfOtMkjuM89
+VRC606QinShzwVbmsTbVwl4VAmYqPg/BplteP81nV8uOrsRlFkNJ6oLqhsTM6eM
lFSBGnwDnrP1URt5r2LGs6aKKmZb5aGdW7puYgaaNzrzD5uMW5Kr1B7cPOwP//rD
Y37x4Cu5jq0v9K5yVEc4GbvBdCjgREAUxweS5xUwWoPxFEPcdJiGZqLeYzpV2Llm
K+J+Wa91RdKUtW3G/k16te9QVA0HWFSLMi1+v8XD4xoe3dmktxZeWSa6sUWaDeDT
gso1uABYrvssiNT9+iMLNXNtJ2o4ZytMp6P9uOIUkJWqval1jPzWFZzF5wJA98mI
ebthSapz3wpZQe6+ab17
=frxy
-----END PGP SIGNATURE-----


From raymond.hettinger at gmail.com  Fri Dec 16 17:56:55 2016
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Fri, 16 Dec 2016 14:56:55 -0800
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
Message-ID: <8D1D8F10-7F27-4F25-BD59-8A1B4D79385E@gmail.com>


> On Dec 16, 2016, at 11:24 AM, Guido van Rossum <guido at python.org> wrote:
> 
> I am beginning to think that `from __future__ import unicode_literals` does more harm than good. I don't recall exactly why we introduced it, but with the restoration of u"" literals in Python 3.3 we have a much better story for writing straddling code that is unicode-correct.
> 
> The problem is that the future import does both too much and not enough -- it does too much because it changes literals to unicode even in contexts where there is no benefit (e.g. the argument to getattr() -- I still hear of code that breaks due to this occasionally) and at the same time it doesn't do anything for strings that you read from files, receive from the network, or even from other files that don't use the future import.
> 
> I wonder if we can add an official note to the 2.7 docs recommending against it? (And maybe even to the 3.x docs if it's mentioned there at all.)

+1  Leaving it in place will likely cause more problems than it solves, so I think your suggest is a net win even if there is some bit of disruption.  Also, as far as I can tell, the adoption rate of Python 3.2 was very low.  Python 3's story didn't become attractive until later.
  

Raymond

From jelle.zijlstra at gmail.com  Fri Dec 16 18:09:11 2016
From: jelle.zijlstra at gmail.com (Jelle Zijlstra)
Date: Fri, 16 Dec 2016 15:09:11 -0800
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <8D1D8F10-7F27-4F25-BD59-8A1B4D79385E@gmail.com>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
 <8D1D8F10-7F27-4F25-BD59-8A1B4D79385E@gmail.com>
Message-ID: <CAFp3-p_d15aEo18D2FcR3CNesLQg5+DUN9x8aQABmuyKb6zmWA@mail.gmail.com>

I've actually found unicode_literals useful in getting code to be Python
2/3-compatible. I try to use a Python 3-like model of always using unicode
for text data and only using str for binary data, and unicode_literals
helps achieve that, since most string literals are meant to be text, not
binary data. The issue with functions like getattr is annoying, but in my
experience it's not a common problem (I don't often call getattr() with a
string literal as an argument).

2016-12-16 14:56 GMT-08:00 Raymond Hettinger <raymond.hettinger at gmail.com>:

>
> > On Dec 16, 2016, at 11:24 AM, Guido van Rossum <guido at python.org> wrote:
> >
> > I am beginning to think that `from __future__ import unicode_literals`
> does more harm than good. I don't recall exactly why we introduced it, but
> with the restoration of u"" literals in Python 3.3 we have a much better
> story for writing straddling code that is unicode-correct.
> >
> > The problem is that the future import does both too much and not enough
> -- it does too much because it changes literals to unicode even in contexts
> where there is no benefit (e.g. the argument to getattr() -- I still hear
> of code that breaks due to this occasionally) and at the same time it
> doesn't do anything for strings that you read from files, receive from the
> network, or even from other files that don't use the future import.
> >
> > I wonder if we can add an official note to the 2.7 docs recommending
> against it? (And maybe even to the 3.x docs if it's mentioned there at all.)
>
> +1  Leaving it in place will likely cause more problems than it solves, so
> I think your suggest is a net win even if there is some bit of disruption.
> Also, as far as I can tell, the adoption rate of Python 3.2 was very low.
> Python 3's story didn't become attractive until later.
>
>
> Raymond
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> jelle.zijlstra%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161216/6c8d6879/attachment.html>

From mcepl at cepl.eu  Fri Dec 16 18:52:13 2016
From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl)
Date: Sat, 17 Dec 2016 00:52:13 +0100
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
Message-ID: <slrno58vhd.8pa.mcepl@mitmanek.ceplovi.cz>

On 2016-12-16, 19:24 GMT, Guido van Rossum wrote:
> I am beginning to think that `from __future__ import unicode_literals` does
> more harm than good. I don't recall exactly why we introduced it, but with
> the restoration of u"" literals in Python 3.3 we have a much better story
> for writing straddling code that is unicode-correct.

???

There has been absolute fanaticism about not changing anything 
in Python 2.* because of supposed stability of API, even in 
situations when I don?t think API was really in danger 
(http://bugs.python.org/issue19494).  And now you would remove 
a feature which zillions of lines of code depend on, or at least 
could depend on?

And yes, I do use it in my current porting efforts of M2Crypto 
to be py2/3k compatible.

I don?t understand.

Mat?j

-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Never, never, never believe any war will be smooth and easy, or
that anyone who embarks on the strange voyage can measure the
tides and hurricanes he will encounter. The statesman who yields
to war fever must realise that once the signal is given, he is no
longer the master of policy but the slave of unforeseeable and
uncontrollable events.
    -- Winston Churchill, 1930


From guido at python.org  Fri Dec 16 18:59:53 2016
From: guido at python.org (Guido van Rossum)
Date: Fri, 16 Dec 2016 15:59:53 -0800
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <slrno58vhd.8pa.mcepl@mitmanek.ceplovi.cz>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
 <slrno58vhd.8pa.mcepl@mitmanek.ceplovi.cz>
Message-ID: <CAP7+vJL12tKPu7-Kn9tebgVDWLXiOHoS-Jta1hMiMb2D7_426w@mail.gmail.com>

On Fri, Dec 16, 2016 at 3:52 PM, Mat?j Cepl <mcepl at cepl.eu> wrote:

> I don?t understand.
>

No need to get all bent out of shape. My proposal is to simply add a note
to the docs recommending against using this. I wouldn't change any code,
not even a silent deprecation warning. (Also, read the rest of the thread
to learn why this is not the best practice for writing Python 2/3
straddling code.)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161216/f633aa88/attachment.html>

From nad at python.org  Sat Dec 17 00:01:00 2016
From: nad at python.org (Ned Deily)
Date: Sat, 17 Dec 2016 00:01:00 -0500
Subject: [Python-Dev] [RELEASE] Python 3.6.0rc2 is now available
Message-ID: <281D809C-E94E-41BB-954D-D092A4CBC03B@python.org>

On behalf of the Python development community and the Python 3.6 release
team, I would like to announce the availability of Python 3.6.0rc2. 3.6.0rc2
is the second release candidate for Python 3.6, the next major release of
Python.

Code for 3.6.0 is now frozen.  3.6.0rc2 is the same code base as the first
release candidate, 3.6.0rc1, with the addition of fixes for a couple of
critical problems and with some documentation additions and updates.
Assuming no further release critical problems are found prior to the 3.6.0
final release date, now planned for 2016-12-23, the 3.6.0 final release
will be the same code base as this 3.6.0rc2.  Maintenance releases for the
3.6 series will follow at regular intervals starting in the first quarter
of 2017.

Among the new major new features in Python 3.6 are:

* PEP 468 - Preserving the order of **kwargs in a function
* PEP 487 - Simpler customization of class creation
* PEP 495 - Local Time Disambiguation
* PEP 498 - Literal String Formatting
* PEP 506 - Adding A Secrets Module To The Standard Library
* PEP 509 - Add a private version to dict
* PEP 515 - Underscores in Numeric Literals
* PEP 519 - Adding a file system path protocol
* PEP 520 - Preserving Class Attribute Definition Order
* PEP 523 - Adding a frame evaluation API to CPython
* PEP 524 - Make os.urandom() blocking on Linux (during system startup)
* PEP 525 - Asynchronous Generators (provisional)
* PEP 526 - Syntax for Variable Annotations (provisional)
* PEP 528 - Change Windows console encoding to UTF-8
* PEP 529 - Change Windows filesystem encoding to UTF-8
* PEP 530 - Asynchronous Comprehensions

Please see "What?s New In Python 3.6" for more information:

https://docs.python.org/3.6/whatsnew/3.6.html

You can find Python 3.6.0rc2 here:

https://www.python.org/downloads/release/python-360rc2/

Note that 3.6.0rc2 is still a preview release and thus its use is not
recommended for production environments.

More information about the release schedule can be found here:

https://www.python.org/dev/peps/pep-0494/

--
  Ned Deily
  nad at python.org -- []


From storchaka at gmail.com  Sat Dec 17 04:06:37 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 11:06:37 +0200
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
Message-ID: <o32v6p$tsh$1@blaine.gmane.org>

On 16.12.16 21:24, Guido van Rossum wrote:
> e.g. the argument to getattr() -- I still hear of code that breaks due
> to this occasionally)

What is the problem with unicode in getattr()? Unicode attribute name is 
converted to str, and since the result is cached, this even don't add 
much overhead.



From christian at python.org  Sat Dec 17 06:44:38 2016
From: christian at python.org (Christian Heimes)
Date: Sat, 17 Dec 2016 12:44:38 +0100
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <o32v6p$tsh$1@blaine.gmane.org>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
 <o32v6p$tsh$1@blaine.gmane.org>
Message-ID: <o338f1$cdc$1@blaine.gmane.org>

On 2016-12-17 10:06, Serhiy Storchaka wrote:
> On 16.12.16 21:24, Guido van Rossum wrote:
>> e.g. the argument to getattr() -- I still hear of code that breaks due
>> to this occasionally)
> 
> What is the problem with unicode in getattr()? Unicode attribute name is
> converted to str, and since the result is cached, this even don't add
> much overhead.

It breaks the str optimization of dicts. Dict with str-only keys are
special-cased in Python 2.

Christian



From storchaka at gmail.com  Sat Dec 17 06:58:00 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 13:58:00 +0200
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <o338f1$cdc$1@blaine.gmane.org>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
 <o32v6p$tsh$1@blaine.gmane.org> <o338f1$cdc$1@blaine.gmane.org>
Message-ID: <o33983$36a$1@blaine.gmane.org>

On 17.12.16 13:44, Christian Heimes wrote:
> On 2016-12-17 10:06, Serhiy Storchaka wrote:
>> On 16.12.16 21:24, Guido van Rossum wrote:
>>> e.g. the argument to getattr() -- I still hear of code that breaks due
>>> to this occasionally)
>>
>> What is the problem with unicode in getattr()? Unicode attribute name is
>> converted to str, and since the result is cached, this even don't add
>> much overhead.
>
> It breaks the str optimization of dicts. Dict with str-only keys are
> special-cased in Python 2.

getattr() converts a unicode to str and passes a str to PyObject_GetAttr().


From ncoghlan at gmail.com  Sat Dec 17 10:59:19 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 18 Dec 2016 01:59:19 +1000
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <o33983$36a$1@blaine.gmane.org>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
 <o32v6p$tsh$1@blaine.gmane.org> <o338f1$cdc$1@blaine.gmane.org>
 <o33983$36a$1@blaine.gmane.org>
Message-ID: <CADiSq7c+ToPqgrQcP96SKa9DB8Ym7Q5y=3q7P8aZkd4dx0QNKA@mail.gmail.com>

On 17 December 2016 at 21:58, Serhiy Storchaka <storchaka at gmail.com> wrote:

> On 17.12.16 13:44, Christian Heimes wrote:
>
>> On 2016-12-17 10:06, Serhiy Storchaka wrote:
>>
>>> On 16.12.16 21:24, Guido van Rossum wrote:
>>>
>>>> e.g. the argument to getattr() -- I still hear of code that breaks due
>>>> to this occasionally)
>>>>
>>>
>>> What is the problem with unicode in getattr()? Unicode attribute name is
>>> converted to str, and since the result is cached, this even don't add
>>> much overhead.
>>>
>>
>> It breaks the str optimization of dicts. Dict with str-only keys are
>> special-cased in Python 2.
>>
>
> getattr() converts a unicode to str and passes a str to PyObject_GetAttr().


getattr() may do the right thing, but directly accessing __dict__ doesn't.

python-future has a good write-up of the benefits and drawbacks, as they
originally recommended it unconditionally when modernising code, and
myself, Armin Ronacher, and a few others convinced them to be a little more
judicious in suggesting it to people:
http://python-future.org/unicode_literals.html

However, that page also points out that whether or not it's likely to help
more than it hurts depends a lot on which version of Python you're starting
from:

- if you're making originally Python 3 only code also work on Python 2, and
hence defining the first ever version of its Python 2 API, then you
probably *do* want to use unicode_literals, and then explicitly mark bytes
literals to get Python 2 working
- if you're modernising Python 2 code and have a lot of existing API users
on Python 2, then you probably *don't* want to use unicode_literals, and
instead explicitly mark your text literals as Unicode to get Python 3
working

In cases like Django where folks successfully adopted the
"unicode_literals" import for modernisation purposes, it was a matter of
aiming to get to that "Python 3 native, with Python 2 also supported"
structure as soon as possible (the fact that Django is structured primarily
as an object oriented framework likely helped with that, as it has a lot of
control over the data types user applications end up encountering).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161218/d35e843c/attachment-0001.html>

From benjamin at python.org  Sat Dec 17 16:44:33 2016
From: benjamin at python.org (Benjamin Peterson)
Date: Sat, 17 Dec 2016 13:44:33 -0800
Subject: [Python-Dev] [RELEASE] Python 2.7.13
Message-ID: <1482011073.1913762.822298361.75CAC690@webmail.messagingengine.com>

It is my pleasure to announce the release of Python 2.7.13, the latest
bugfix release of the venerable Python 2.7 series. This release
incorporates conservative bugfixes as well as improvements to keep
Python 2.7 running on modern systems.

The only change from the 2.7.13 release candidate 2 weeks ago is the
revert of a change that broke backwards compatibility with some rare C
extension patterns. See https://bugs.python.org/issue5322 for more
details.

Source archives and binaries are available at
    https://www.python.org/downloads/release/python-2713/

Please report bugs to our tracker:
    https://bugs.python.org/

2.7.14 will appear mid-2017.

All the best in the new year,
Benjamin Peterson
2.7 release manager

From brett at python.org  Sat Dec 17 15:41:34 2016
From: brett at python.org (Brett Cannon)
Date: Sat, 17 Dec 2016 20:41:34 +0000
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
Message-ID: <CAP1=2W540JMLtqwxxeWpqJtfO03-hUUPQP6PbXixJdvpjzKVZA@mail.gmail.com>

I have updated the porting HOWTO to drop recommending unicode_literals and
also to mention running optional type checkers like mypy and pytype twice
(once under Python 2 and again under Python 3).

On Fri, 16 Dec 2016 at 11:25 Guido van Rossum <guido at python.org> wrote:

> I am beginning to think that `from __future__ import unicode_literals`
> does more harm than good. I don't recall exactly why we introduced it, but
> with the restoration of u"" literals in Python 3.3 we have a much better
> story for writing straddling code that is unicode-correct.
>
> The problem is that the future import does both too much and not enough --
> it does too much because it changes literals to unicode even in contexts
> where there is no benefit (e.g. the argument to getattr() -- I still hear
> of code that breaks due to this occasionally) and at the same time it
> doesn't do anything for strings that you read from files, receive from the
> network, or even from other files that don't use the future import.
>
> I wonder if we can add an official note to the 2.7 docs recommending
> against it? (And maybe even to the 3.x docs if it's mentioned there at all.)
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161217/38ca3de9/attachment.html>

From vadmium+py at gmail.com  Sat Dec 17 18:56:37 2016
From: vadmium+py at gmail.com (Martin Panter)
Date: Sat, 17 Dec 2016 23:56:37 +0000
Subject: [Python-Dev] [Python-checkins] cpython (2.7): Update the
 porting HOWTO
In-Reply-To: <20161217203945.96211.5793.A4C06B56@psf.io>
References: <20161217203945.96211.5793.A4C06B56@psf.io>
Message-ID: <CA+eR4cG0shYv-x10-MPrCUD4hdQf4e91K5BVPRRtOZhLPc4dHg@mail.gmail.com>

On 17 December 2016 at 20:39, brett.cannon <python-checkins at python.org> wrote:
> https://hg.python.org/cpython/rev/287d4290b1b4
> changeset:   105714:287d4290b1b4
> branch:      2.7
> parent:      105677:eb02db65e148
> user:        Brett Cannon <brett at python.org>
> date:        Sat Dec 17 12:38:54 2016 -0800
> summary:
>   Update the porting HOWTO
>
> diff --git a/Doc/howto/pyporting.rst b/Doc/howto/pyporting.rst
> --- a/Doc/howto/pyporting.rst
> +++ b/Doc/howto/pyporting.rst
> . . .
>  Have good test coverage
>  -----------------------
>
> @@ -106,10 +107,11 @@
>  thumb is that if you want to be confident enough in your test suite that any
>  failures that appear after having tools rewrite your code are actual bugs in the
>  tools and not in your code. If you want a number to aim for, try to get over 80%
> -coverage (and don't feel bad if you can't easily get past 90%). If you
> +coverage (and don't feel bad if you can't easily get passed 90%). If you
>  don't already have a tool to measure test coverage then coverage.py_ is
>  recommended.

Hi Brett, why did you make the above change (get past ? get passed)?
To me, ?get past 90%? means achieving over 90%, but ?you can?t get
passed 90%? would mean that 90% cannot be given (passed) to you. The
original made more sense. Another option would be ?get over 90%?,
consistent with the previous sentence.

From storchaka at gmail.com  Sun Dec 18 03:31:50 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sun, 18 Dec 2016 10:31:50 +0200
Subject: [Python-Dev] Constifying C API
Message-ID: <o35hhi$44s$1@blaine.gmane.org>

Originally C API didn't use the const qualifier. Over few last years the 
const qualifier was added to C API if that preserved backward 
compatibility. For example input "char *" parameters were changed to 
"const char *". This makes C API compatible with C++, eliminates C 
compiler warnings, and helps to found possible errors.

Now I have started to make changes that are not absolute compatible, and 
can need modifying third-party code (but unlikely).

* The const qualifier was added to "char *" fields name and doc of some 
structures. They always point to C string literals. 
https://bugs.python.org/issue28761

* The const qualifier was added to private global variable 
_Py_PackageContext. https://bugs.python.org/issue28748

Now I'm going to add the const qualifier to the result of 
PyUnicode_AsUTF8AndSize() and PyUnicode_AsUTF8(). These functions return 
a reference to internal cached UTF8 representations of a string. It 
should never be modified. https://bugs.python.org/issue28769

Later I'm planning following changes:

* Add the const qualifier to the result of functions that return 
references to internal representation of immutable objects, like 
PyBytes_AS_STRING() or PyUnicode_DATA(). While CPython internally can 
modify the content of immutable objets, this is very dangerous, because 
this can invalidates invariants and cached values. Third-party code 
shouldn't do this.

* Add the const qualifier to the format field of Py_buffer. It is a 
reference to C string literal or to the content of bytes object. 
Mutating its content is an error. Only _testbuffer overuses the format 
field of internal Py_buffer object for owning a reference to allocated 
memory. But this is not leaked outside.

What are you think about this?


From ncoghlan at gmail.com  Sun Dec 18 19:54:09 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 19 Dec 2016 10:54:09 +1000
Subject: [Python-Dev] Constifying C API
In-Reply-To: <o35hhi$44s$1@blaine.gmane.org>
References: <o35hhi$44s$1@blaine.gmane.org>
Message-ID: <CADiSq7cjSk_Z_Z_8qVfG+a319scMYZaZ9gEQBWSziyVdQyseuA@mail.gmail.com>

On 18 December 2016 at 18:31, Serhiy Storchaka <storchaka at gmail.com> wrote:

> Later I'm planning following changes:
>
> * Add the const qualifier to the result of functions that return
> references to internal representation of immutable objects, like
> PyBytes_AS_STRING() or PyUnicode_DATA(). While CPython internally can
> modify the content of immutable objets, this is very dangerous, because
> this can invalidates invariants and cached values. Third-party code
> shouldn't do this.
>
> * Add the const qualifier to the format field of Py_buffer. It is a
> reference to C string literal or to the content of bytes object. Mutating
> its content is an error. Only _testbuffer overuses the format field of
> internal Py_buffer object for owning a reference to allocated memory. But
> this is not leaked outside.
>
> What are you think about this?
>

As long as it's on the default branch with appropriate notes in the C
porting section of the 3.7 What's New, turning these kinds of runtime
errors into compilation errors sounds like the right thing to do to me.

One key aspect from my perspective is that code that is updated to
correctly declare the destination storage as a const pointer will still
compile against the old API variants that return a mutable pointer, so any
problems this finds in third party code are likely to be resolved for older
3.x releases as well.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161219/6cd2bf55/attachment.html>

From tseaver at palladion.com  Sun Dec 18 20:52:46 2016
From: tseaver at palladion.com (Tres Seaver)
Date: Sun, 18 Dec 2016 20:52:46 -0500
Subject: [Python-Dev] Constifying C API
In-Reply-To: <CADiSq7cjSk_Z_Z_8qVfG+a319scMYZaZ9gEQBWSziyVdQyseuA@mail.gmail.com>
References: <o35hhi$44s$1@blaine.gmane.org>
 <CADiSq7cjSk_Z_Z_8qVfG+a319scMYZaZ9gEQBWSziyVdQyseuA@mail.gmail.com>
Message-ID: <o37ehc$ubu$1@blaine.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/18/2016 07:54 PM, Nick Coghlan wrote:
> On 18 December 2016 at 18:31, Serhiy Storchaka <storchaka at gmail.com>
> wrote:
> 
>> Later I'm planning following changes:
>> 
>> * Add the const qualifier to the result of functions that return 
>> references to internal representation of immutable objects, like 
>> PyBytes_AS_STRING() or PyUnicode_DATA(). While CPython internally
>> can modify the content of immutable objets, this is very dangerous,
>> because this can invalidates invariants and cached values.
>> Third-party code shouldn't do this.
>> 
>> * Add the const qualifier to the format field of Py_buffer. It is a 
>> reference to C string literal or to the content of bytes object.
>> Mutating its content is an error. Only _testbuffer overuses the
>> format field of internal Py_buffer object for owning a reference to
>> allocated memory. But this is not leaked outside.
>> 
>> What are you think about this?
>> 
> 
> As long as it's on the default branch with appropriate notes in the C 
> porting section of the 3.7 What's New, turning these kinds of runtime 
> errors into compilation errors sounds like the right thing to do to
> me.
> 
> One key aspect from my perspective is that code that is updated to 
> correctly declare the destination storage as a const pointer will
> still compile against the old API variants that return a mutable
> pointer, so any problems this finds in third party code are likely to
> be resolved for older 3.x releases as well.

Agreed.  Anything the compiler ralfs on after adding 'const' (where the
actual target must be immutable) already had the fuse smoldering.  FWIW I
help maintain some *old* C extensions (fifteen+ years and counting), and
am as likely to be affected as anyone.


Tres
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJYVz1oAAoJEPKpaDSJE9HYNc0P/2ZfDQeWmecy/deL4mqvLh42
iZuyyXoYmsEvHWgTL1gCOK3isUAKn5MMDAk79ezGkbmrmerxV0EVCrIsQMaCBuhY
ypWxsPHa1nUpJpTuziHi452ETDq606nDgUXJnNUtR1xqVlFNpNskTYdexkxv4K5W
E+ANwNvE+/YZN7t8KmIcR8pczRGhWJ5X67+etG0KlJ0mDR13RIpUZs7OfTFsXRi1
YHYgI1uKKkphB/KdPxeQfN4G5CgiRK3fJ8sQO2ojJKt3xMqPJcmGG0KIHZi0waXA
Uqh+ukKE1tWDdBPYubv+4nlrtWQye6kX9gUu/gXYXM9C7h3u9B9otYXblNGqZAol
q6+QfnSmOCZkGeaGw+Gwzz+B2yQcz4phuaz1AirtYUA66s0vbLuKi+SNiVei2gzn
M/xd1HpZOxFVk/QkZYHlOW0k2F8o73ecWSONo1xTgi7pdjDrAALhbQ+7Z/dBHn0i
474VoRXcEqVwST87CqbEXyW82GexOppPGqi0jgeAFWJtb0HytuLv21l/h7XgX/TV
lmrxGAh6VGl2FOIQolgSNKaVQHsxh2xDq8lL7hGgXuDcI4fD3d+p6bu3tpN6nXMA
b4k0TAry7PfKASk0MJgU9aZCSFulDR8ghnx+nUte0OrDdd+nqaovtZcT1Y52glU/
FBw00PcU9+MWZ+zlQNfs
=/M++
-----END PGP SIGNATURE-----


From larry at hastings.org  Mon Dec 19 00:26:18 2016
From: larry at hastings.org (Larry Hastings)
Date: Sun, 18 Dec 2016 21:26:18 -0800
Subject: [Python-Dev] Should I delay 3.5.3 and 3.4.6 by two weeks?
Message-ID: <b99f2412-74e8-fc96-3f2a-e0811ea7f58f@hastings.org>



Python 3.6.0 final just slipped by two weeks.  I scheduled 3.5.3 and 
3.4.6 to ship about a month after 3.6.0 did, to "let the dust settle" 
around the release.  I expect a flood of adoption of 3.6, and people 
switching will find bugs, and maybe those bugs are in 3.5 or 3.4.  So it 
just seemed sensible.

3.6 just slipped by two weeks.  So now there's less than two weeks 
between 3.6.0 final shipping and tagging the release canddiates for 
3.5.3 and 3.4.6.  This isn't as much time as I'd like.

If I had total freedom to do as I liked, I'd slip my releases by two 
weeks to match 3.6.  But there might be people planning around 3.5.3 and 
3.4.6--like Guido was waiting for 3.5.3 for something iirc.

So, if you have an opinion, please vote for one of these three options:

  * Don't slip 3.5.3. and 3.4.6.
  * Slip 3.5.3 and 3.4.6 by two weeks to match 3.6.0.
  * Slip 3.5.3 and 3.4.6 by a whole month, to give 3.6.0 the ability to
    slip again without us having to change the release.


Your faithful servant,


//arry/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161218/65a0cd34/attachment.html>

From nad at python.org  Mon Dec 19 01:03:18 2016
From: nad at python.org (Ned Deily)
Date: Mon, 19 Dec 2016 01:03:18 -0500
Subject: [Python-Dev] Should I delay 3.5.3 and 3.4.6 by two weeks?
In-Reply-To: <b99f2412-74e8-fc96-3f2a-e0811ea7f58f@hastings.org>
References: <b99f2412-74e8-fc96-3f2a-e0811ea7f58f@hastings.org>
Message-ID: <59258551-9735-424D-9D31-AE6D4D51DC33@python.org>

On Dec 19, 2016, at 00:26, Larry Hastings <larry at hastings.org> wrote:
> Python 3.6.0 final just slipped by two weeks.

While it should not affect decisions about 3.5.3 and 3.4.6, so there's no confusion: the 3.6.0 release date slipped one week, from 2016-12-16 to 2016-12-23.  Of course, until the release happens, it's possible that it could slip again but it hasn't yet and we are going to do our best to keep it from doing so.

--
  Ned Deily
  nad at python.org -- []


From raymond.hettinger at gmail.com  Mon Dec 19 03:41:33 2016
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 19 Dec 2016 00:41:33 -0800
Subject: [Python-Dev] Should I delay 3.5.3 and 3.4.6 by two weeks?
In-Reply-To: <b99f2412-74e8-fc96-3f2a-e0811ea7f58f@hastings.org>
References: <b99f2412-74e8-fc96-3f2a-e0811ea7f58f@hastings.org>
Message-ID: <D99BE80F-4ABC-4582-A372-2B990F3B44AE@gmail.com>


> On Dec 18, 2016, at 9:26 PM, Larry Hastings <larry at hastings.org> wrote:
> 
> So, if you have an opinion, please vote for one of these three options:
> 	? Don't slip 3.5.3. and 3.4.6.
> 	? Slip 3.5.3 and 3.4.6 by two weeks to match 3.6.0.
> 	? Slip 3.5.3 and 3.4.6 by a whole month, to give 3.6.0 the ability to slip again without us having to change the release.

I vote for not slipping.   2.7.13 is out.  3.6.0 is almost out.  And it would be nice to have the others done as well.  That way, we know the whole source tree is open and can start moving forward without reservations.

Also, I would like the 3.6.0 announcement to not get drowned-out or attenuated by other announcements around older releases (i.e. it would be nice if 3.6.0 was the actual latest release of any version for a while).


Raymond

From victor.stinner at gmail.com  Mon Dec 19 05:29:33 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 19 Dec 2016 11:29:33 +0100
Subject: [Python-Dev] Constifying C API
In-Reply-To: <o35hhi$44s$1@blaine.gmane.org>
References: <o35hhi$44s$1@blaine.gmane.org>
Message-ID: <CAMpsgwacOnF0ro+1uof2JG7uj-jS5eHrcx40WUm7D7vKdr4gqg@mail.gmail.com>

2016-12-18 9:31 GMT+01:00 Serhiy Storchaka <storchaka at gmail.com>:
> Originally C API didn't use the const qualifier. Over few last years the
> const qualifier was added to C API if that preserved backward compatibility.
> For example input "char *" parameters were changed to "const char *". This
> makes C API compatible with C++, eliminates C compiler warnings, and helps
> to found possible errors.

Since the "const" keyword does not impact the stable *ABI*, I think
that it's fine to add use it in more places.

In the worst case, if an extension chose to be compiled with -Werror
(convert warnings into errors), the maintainer will have to fix
conversion warnings in the code. But it's easy to write C code which
works with and without const (old and new Python *API*), using
explicit cast (to const char* for example).

In the common case, it will just be a warning and nobody will notice
it since more and more people use pip which compiles C extensions in
the background and doesn't show GCC output anymore.

I agree that it can help to find real bugs.

Victor

From victor.stinner at gmail.com  Mon Dec 19 07:13:17 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 19 Dec 2016 13:13:17 +0100
Subject: [Python-Dev] Cleanup of abstract.h header
In-Reply-To: <20161216112437.0faaaedc@fsol>
References: <CAMpsgwZnE7pePvB611cCYgaMF0Rk_Bma+FDCOyh9qEJEH6+DXA@mail.gmail.com>
 <20161216112437.0faaaedc@fsol>
Message-ID: <CAMpsgwYQ1HD9cOiew4oeh+JL1__oXOCnNC4i-3C-fs2rGoYuyg@mail.gmail.com>

2016-12-16 11:24 GMT+01:00 Antoine Pitrou <solipsis at pitrou.net>:
> Since you are cleaning up, you could remove the whole "PROPOSAL: A
> Generic Python Object Interface for Python C Modules" introduction,
> which isn't very interesting to read today.

Done: hg.python.org/cpython/rev/3ab0a6692e25

Victor

From tjreedy at udel.edu  Mon Dec 19 09:28:23 2016
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 19 Dec 2016 09:28:23 -0500
Subject: [Python-Dev] Should I delay 3.5.3 and 3.4.6 by two weeks?
In-Reply-To: <b99f2412-74e8-fc96-3f2a-e0811ea7f58f@hastings.org>
References: <b99f2412-74e8-fc96-3f2a-e0811ea7f58f@hastings.org>
Message-ID: <o38qq4$6ta$1@blaine.gmane.org>

On 12/19/2016 12:26 AM, Larry Hastings wrote:
>
>
> Python 3.6.0 final just slipped by two weeks.  I scheduled 3.5.3 and
> 3.4.6 to ship about a month after 3.6.0 did, to "let the dust settle"
> around the release.  I expect a flood of adoption of 3.6, and people
> switching will find bugs, and maybe those bugs are in 3.5 or 3.4.  So it
> just seemed sensible.
>
> 3.6 just slipped by two weeks.  So now there's less than two weeks
> between 3.6.0 final shipping and tagging the release canddiates for
> 3.5.3 and 3.4.6.  This isn't as much time as I'd like.
>
> If I had total freedom to do as I liked, I'd slip my releases by two
> weeks to match 3.6.  But there might be people planning around 3.5.3 and
> 3.4.6--like Guido was waiting for 3.5.3 for something iirc.
>
> So, if you have an opinion, please vote for one of these three options:
>
>   * Don't slip 3.5.3. and 3.4.6.

I am mildly in favor of this.  There are already known bugs in 3.5 that 
will not get fixed, no matter how long you delay the final maintenance 
release.  There are even bugs left in 2.7 after 6 years of fixing.  In 
the meanwhile, it is a mild nuisance to have 3 3.x maintenance branches 
open.

I don't know when Brett will move us to GIT and how that might impact 
the timing.

-- 
Terry Jan Reedy


From brett at python.org  Mon Dec 19 11:50:26 2016
From: brett at python.org (Brett Cannon)
Date: Mon, 19 Dec 2016 16:50:26 +0000
Subject: [Python-Dev] Should I delay 3.5.3 and 3.4.6 by two weeks?
In-Reply-To: <o38qq4$6ta$1@blaine.gmane.org>
References: <b99f2412-74e8-fc96-3f2a-e0811ea7f58f@hastings.org>
 <o38qq4$6ta$1@blaine.gmane.org>
Message-ID: <CAP1=2W7WCX7s9zyO=KMOt_mEauA0H64+8pYt246excG_Q63jsQ@mail.gmail.com>

On Mon, 19 Dec 2016 at 06:29 Terry Reedy <tjreedy at udel.edu> wrote:

> On 12/19/2016 12:26 AM, Larry Hastings wrote:
> >
> >
> > Python 3.6.0 final just slipped by two weeks.  I scheduled 3.5.3 and
> > 3.4.6 to ship about a month after 3.6.0 did, to "let the dust settle"
> > around the release.  I expect a flood of adoption of 3.6, and people
> > switching will find bugs, and maybe those bugs are in 3.5 or 3.4.  So it
> > just seemed sensible.
> >
> > 3.6 just slipped by two weeks.  So now there's less than two weeks
> > between 3.6.0 final shipping and tagging the release canddiates for
> > 3.5.3 and 3.4.6.  This isn't as much time as I'd like.
> >
> > If I had total freedom to do as I liked, I'd slip my releases by two
> > weeks to match 3.6.  But there might be people planning around 3.5.3 and
> > 3.4.6--like Guido was waiting for 3.5.3 for something iirc.
> >
> > So, if you have an opinion, please vote for one of these three options:
> >
> >   * Don't slip 3.5.3. and 3.4.6.
>
> I am mildly in favor of this.  There are already known bugs in 3.5 that
> will not get fixed, no matter how long you delay the final maintenance
> release.  There are even bugs left in 2.7 after 6 years of fixing.  In
> the meanwhile, it is a mild nuisance to have 3 3.x maintenance branches
> open.
>
> I don't know when Brett will move us to GIT and how that might impact
> the timing.
>

Slipping doesn't affect me yet as all the pieces are still not quite in
place. So a shift in release just shifts the blackout period for the week
prior to the 3.5.3 release.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161219/9f6cdd99/attachment.html>

From mcepl at cepl.eu  Mon Dec 19 18:40:01 2016
From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl)
Date: Tue, 20 Dec 2016 00:40:01 +0100
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
 <slrno58vhd.8pa.mcepl@mitmanek.ceplovi.cz>
 <CAP7+vJL12tKPu7-Kn9tebgVDWLXiOHoS-Jta1hMiMb2D7_426w@mail.gmail.com>
Message-ID: <slrno5gruh.pqb.mcepl@mitmanek.ceplovi.cz>

On 2016-12-16, 23:59 GMT, Guido van Rossum wrote:
> No need to get all bent out of shape. My proposal is to simply 
> add a note to the docs recommending against using this.  
> I wouldn't change any code, not even a silent deprecation 
> warning. (Also, read the rest of the thread to learn why this 
> is not the best practice for writing Python 2/3 straddling 
> code.)

Oh, that sounds a way better. Thank you.

Mat?j

-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
If Patrick Henry thought that taxation without representation was
bad, he should see how bad it is with representation.


From chris.barker at noaa.gov  Mon Dec 19 20:50:19 2016
From: chris.barker at noaa.gov (Chris Barker)
Date: Mon, 19 Dec 2016 17:50:19 -0800
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <CAP1=2W540JMLtqwxxeWpqJtfO03-hUUPQP6PbXixJdvpjzKVZA@mail.gmail.com>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
 <CAP1=2W540JMLtqwxxeWpqJtfO03-hUUPQP6PbXixJdvpjzKVZA@mail.gmail.com>
Message-ID: <CALGmxEJD_4sPuOCWqXMiE=953inTKXicf0zDL4X51PFV_hy7sw@mail.gmail.com>

Please don't get rid of unicode+literals -- I don't even think we should
depreciate it as a recommendation or discourage it.

Maybe a note or two added as to where issues may arise would be good.

I've found importing unicode_literals to be an excellent way to write py2/3
code. And I have never found a problem.

I'm also hoping that my py2/3 compatible code will someday be py3 only --
and then I'll be really glad that I don't have all those u" all over the
place.

Also it does "automagically" do the right thing with, for instance passing
a literal to the file handling functions in the os module -- so that's
pretty nice.

The number of times you need to add a b"" is FAR fewer than "text" string
literals. Let's keep it.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161219/dca78081/attachment.html>

From doko at ubuntu.com  Tue Dec 20 05:25:14 2016
From: doko at ubuntu.com (Matthias Klose)
Date: Tue, 20 Dec 2016 11:25:14 +0100
Subject: [Python-Dev] [python-committers] Should I delay 3.5.3 and 3.4.6
 by two weeks?
In-Reply-To: <b99f2412-74e8-fc96-3f2a-e0811ea7f58f@hastings.org>
References: <b99f2412-74e8-fc96-3f2a-e0811ea7f58f@hastings.org>
Message-ID: <9181f663-347b-fefd-ba3f-dc9d17bd9de3@ubuntu.com>

On 19.12.2016 06:26, Larry Hastings wrote:
> 
> 
> Python 3.6.0 final just slipped by two weeks.  I scheduled 3.5.3 and 3.4.6 to
> ship about a month after 3.6.0 did, to "let the dust settle" around the
> release.  I expect a flood of adoption of 3.6, and people switching will find
> bugs, and maybe those bugs are in 3.5 or 3.4.  So it just seemed sensible.
> 
> 3.6 just slipped by two weeks.  So now there's less than two weeks between 3.6.0
> final shipping and tagging the release canddiates for 3.5.3 and 3.4.6.  This
> isn't as much time as I'd like.
> 
> If I had total freedom to do as I liked, I'd slip my releases by two weeks to
> match 3.6.  But there might be people planning around 3.5.3 and 3.4.6--like
> Guido was waiting for 3.5.3 for something iirc.
> 
> So, if you have an opinion, please vote for one of these three options:
> 
>  * Don't slip 3.5.3. and 3.4.6.
>  * Slip 3.5.3 and 3.4.6 by two weeks to match 3.6.0.
>  * Slip 3.5.3 and 3.4.6 by a whole month, to give 3.6.0 the ability to
>    slip again without us having to change the release.

I would appreciate a 3.5.3 release which doesn't slip, or which only slips by a
week, to be available before the Debian freeze.  Neither Debian nor Ubuntu ship
the 3.4 branch anymore, so for 3.4 I'm fine with any solution.

Matthias


From fabiofz at gmail.com  Tue Dec 20 10:50:36 2016
From: fabiofz at gmail.com (Fabio Zadrozny)
Date: Tue, 20 Dec 2016 13:50:36 -0200
Subject: [Python-Dev] Deprecate `from __future__ import
 unicode_literals`?
In-Reply-To: <CALGmxEJD_4sPuOCWqXMiE=953inTKXicf0zDL4X51PFV_hy7sw@mail.gmail.com>
References: <CAP7+vJ+9y8NkF+W+axJNdryXAy7WobeHUr81Hkv90U+QBuwLkg@mail.gmail.com>
 <CAP1=2W540JMLtqwxxeWpqJtfO03-hUUPQP6PbXixJdvpjzKVZA@mail.gmail.com>
 <CALGmxEJD_4sPuOCWqXMiE=953inTKXicf0zDL4X51PFV_hy7sw@mail.gmail.com>
Message-ID: <CANXBEFpQWw9kZMFRFCDCcT5s3+T6CU-YJ7jvS8YN2bt+W_8+SQ@mail.gmail.com>

On Mon, Dec 19, 2016 at 11:50 PM, Chris Barker <chris.barker at noaa.gov>
wrote:

> Please don't get rid of unicode+literals -- I don't even think we should
> depreciate it as a recommendation or discourage it.
>
> Maybe a note or two added as to where issues may arise would be good.
>
> I've found importing unicode_literals to be an excellent way to write
> py2/3 code. And I have never found a problem.
>
> I'm also hoping that my py2/3 compatible code will someday be py3 only --
> and then I'll be really glad that I don't have all those u" all over the
> place.
>
> Also it does "automagically" do the right thing with, for instance passing
> a literal to the file handling functions in the os module -- so that's
> pretty nice.
>
> The number of times you need to add a b"" is FAR fewer than "text" string
> literals. Let's keep it.
>
> -CHB
>
>
Same thing here... also, it helps coding with the same mindset of Python 3,
where everything is unicode by default -- and yes, there are problems if
you use a unicode in an API that accepts bytes on Python 2, but then, you
can also have the same issues on Python 3 -- you need to know and keep
track on the bytes vs unicode everywhere (although they're syntactically
similar to declare, they're not the same thing) and I find that there are
less places where you need to put b'' than u'' (if you code with unicode in
mind in Python 2)...

On the ideal world, Python 2 would actually be improved to accept unicode
on the places where Python 3 accepts unicode (such as subprocess.Popen,
etc) to make it easier in porting applications that actually do the "right"
thing on Python 2 to go to Python 3.

Best Regards,

Fabio?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161220/b2d77cea/attachment.html>

From steve.dower at python.org  Tue Dec 20 20:52:15 2016
From: steve.dower at python.org (Steve Dower)
Date: Tue, 20 Dec 2016 17:52:15 -0800
Subject: [Python-Dev] Issue #23903 - stable API is incomplete
Message-ID: <a8dbaf6b-fc12-da61-843b-2e1dc2273e53@python.org>

For those who aren't aware, the stable API (PEP 384) is broken on 
Windows because the exports from python3.dll have not been kept up to date.

Over at http://bugs.python.org/issue23903 we're trying to address this 
by automatically generating the DLL based on the headers. This has shown 
that many more functions and data items are in the stable ABI than expected.

If it's left entirely to me, I'm planning to add all the public APIs 
into python3.dll, which will commit them to the stable API for good, and 
remove the _private APIs that have been added since we last updated the DLL.

However, if you've added an API recently that you didn't mean to be in 
the stable API, here is your chance to remove it. The full list of APIs 
that have never been available on Windows in the stable ABI but are in 
the headers are below. If it should not be considered long-term stable, 
then it needs "#ifndef Py_LIMITED_API" around it.

Note that anything NOT on this list has already been released, and so it 
cannot be removed from the stable API at this time. I want to resolve 
this for 3.5.3 (that is, release all of these as stable and then it 
cannot be undone), which is coming up very soon, so if any of the public 
APIs should NOT be stable, please fix them, and if any of the private 
APIs SHOULD be stable, they'll probably need version-specific guards 
(see moduleobject.h).

Cheers,
Steve

Full list of APIs to be added to python3.dll:

PyAST_FromNode
PyAST_FromNodeObject
PyAST_Validate
PyCmpWrapper_Type
PyCodec_NameReplaceErrors
PyErr_GetExcInfo
PyErr_ResourceWarning
PyErr_SetExcFromWindowsErr
PyErr_SetExcFromWindowsErrWithFilename
PyErr_SetExcFromWindowsErrWithFilenameObject
PyErr_SetExcFromWindowsErrWithFilenameObjects
PyErr_SetExcInfo
PyErr_SetExcWithArgsKwargs
PyErr_SetFromErrnoWithFilenameObjects
PyErr_SetFromWindowsErr
PyErr_SetFromWindowsErrWithFilename
PyErr_SetImportError
PyErr_SetImportErrorSubclass
PyErr_SyntaxLocationEx
PyExc_BlockingIOError
PyExc_BrokenPipeError
PyExc_ChildProcessError
PyExc_ConnectionAbortedError
PyExc_ConnectionError
PyExc_ConnectionRefusedError
PyExc_ConnectionResetError
PyExc_FileExistsError
PyExc_FileNotFoundError
PyExc_InterruptedError
PyExc_IsADirectoryError
PyExc_ModuleNotFoundError
PyExc_NotADirectoryError
PyExc_PermissionError
PyExc_ProcessLookupError
PyExc_RecursionError
PyExc_ResourceWarning
PyExc_StopAsyncIteration
PyExc_TimeoutError
PyExc_WindowsError
PyImport_AddModuleObject
PyImport_ExecCodeModuleObject
PyImport_ImportFrozenModuleObject
PyImport_ImportModuleLevelObject
PyMarshal_ReadObjectFromString
PyMarshal_WriteLongToFile
PyMarshal_WriteObjectToFile
PyMarshal_WriteObjectToString
PyMem_Calloc
PyMember_GetOne
PyMember_SetOne
PyMemoryView_FromMemory
PyModuleDef_Init
PyModuleDef_Type
PyModule_AddFunctions
PyModule_ExecDef
PyModule_FromDefAndSpec2
PyModule_GetNameObject
PyModule_NewObject
PyModule_SetDocString
PyNode_AddChild
PyNode_Free
PyNode_ListTree
PyNode_New
PyNumber_InPlaceMatrixMultiply
PyNumber_MatrixMultiply
PyOS_CheckStack
PyOS_FSPath
PyObject_Calloc
PyObject_GenericSetDict
PyParser_SimpleParseStringFlagsFilename
PySys_AddXOption
PySys_GetXOptions
PyThread_GetInfo
PyThread_ReInitTLS
PyThread_acquire_lock
PyThread_acquire_lock_timed
PyThread_allocate_lock
PyThread_create_key
PyThread_delete_key
PyThread_delete_key_value
PyThread_exit_thread
PyThread_free_lock
PyThread_get_key_value
PyThread_get_stacksize
PyThread_get_thread_ident
PyThread_init_thread
PyThread_release_lock
PyThread_set_key_value
PyThread_set_stacksize
PyThread_start_new_thread
PyUnicode_AsMBCSString
PyUnicode_AsUCS4
PyUnicode_AsUCS4Copy
PyUnicode_AsWideCharString
PyUnicode_DecodeCodePageStateful
PyUnicode_DecodeLocale
PyUnicode_DecodeLocaleAndSize
PyUnicode_DecodeMBCS
PyUnicode_DecodeMBCSStateful
PyUnicode_EncodeCodePage
PyUnicode_EncodeLocale
PyUnicode_FindChar
PyUnicode_GetLength
PyUnicode_ReadChar
PyUnicode_Substring
PyUnicode_WriteChar
Py_DecodeLocale
Py_EncodeLocale
Py_FileSystemDefaultEncodeErrors
Py_SetPath
Py_hexdigits
_PyBytes_DecodeEscape
_PyDebug_PrintTotalRefs
_PyThreadState_Current
_PyTrash_thread_deposit_object
_PyTrash_thread_destroy_chain
_PyUnicode_DecodeUnicodeEscape
_Py_AddToAllObjects
_Py_ForgetReference
_Py_GetRefTotal
_Py_HashSecret_Initialized
_Py_NegativeRefcount
_Py_NewReference
_Py_PrintReferenceAddresses
_Py_PrintReferences
_Py_RefTotal

From steve.dower at python.org  Tue Dec 20 21:33:26 2016
From: steve.dower at python.org (Steve Dower)
Date: Tue, 20 Dec 2016 18:33:26 -0800
Subject: [Python-Dev] Issue #23903 - stable API is incomplete
In-Reply-To: <a8dbaf6b-fc12-da61-843b-2e1dc2273e53@python.org>
References: <a8dbaf6b-fc12-da61-843b-2e1dc2273e53@python.org>
Message-ID: <E1cJWjC-0001Rn-PC@se2-syd.hostedmail.net.au>

I should also point out that when 3.6.0 releases, all of these will already be in the stable API for other platforms. I'm not going to take a stance on whether we can break it there between 3.6.0 and 3.6.1, but it may already be too late to remove any.

Top-posted from my Windows Phone

-----Original Message-----
From: "Steve Dower" <steve.dower at python.org>
Sent: ?12/?20/?2016 17:56
To: "Python Dev" <python-dev at python.org>
Subject: [Python-Dev] Issue #23903 - stable API is incomplete

For those who aren't aware, the stable API (PEP 384) is broken on 
Windows because the exports from python3.dll have not been kept up to date.

Over at http://bugs.python.org/issue23903 we're trying to address this 
by automatically generating the DLL based on the headers. This has shown 
that many more functions and data items are in the stable ABI than expected.

If it's left entirely to me, I'm planning to add all the public APIs 
into python3.dll, which will commit them to the stable API for good, and 
remove the _private APIs that have been added since we last updated the DLL.

However, if you've added an API recently that you didn't mean to be in 
the stable API, here is your chance to remove it. The full list of APIs 
that have never been available on Windows in the stable ABI but are in 
the headers are below. If it should not be considered long-term stable, 
then it needs "#ifndef Py_LIMITED_API" around it.

Note that anything NOT on this list has already been released, and so it 
cannot be removed from the stable API at this time. I want to resolve 
this for 3.5.3 (that is, release all of these as stable and then it 
cannot be undone), which is coming up very soon, so if any of the public 
APIs should NOT be stable, please fix them, and if any of the private 
APIs SHOULD be stable, they'll probably need version-specific guards 
(see moduleobject.h).

Cheers,
Steve

Full list of APIs to be added to python3.dll:

PyAST_FromNode
PyAST_FromNodeObject
PyAST_Validate
PyCmpWrapper_Type
PyCodec_NameReplaceErrors
PyErr_GetExcInfo
PyErr_ResourceWarning
PyErr_SetExcFromWindowsErr
PyErr_SetExcFromWindowsErrWithFilename
PyErr_SetExcFromWindowsErrWithFilenameObject
PyErr_SetExcFromWindowsErrWithFilenameObjects
PyErr_SetExcInfo
PyErr_SetExcWithArgsKwargs
PyErr_SetFromErrnoWithFilenameObjects
PyErr_SetFromWindowsErr
PyErr_SetFromWindowsErrWithFilename
PyErr_SetImportError
PyErr_SetImportErrorSubclass
PyErr_SyntaxLocationEx
PyExc_BlockingIOError
PyExc_BrokenPipeError
PyExc_ChildProcessError
PyExc_ConnectionAbortedError
PyExc_ConnectionError
PyExc_ConnectionRefusedError
PyExc_ConnectionResetError
PyExc_FileExistsError
PyExc_FileNotFoundError
PyExc_InterruptedError
PyExc_IsADirectoryError
PyExc_ModuleNotFoundError
PyExc_NotADirectoryError
PyExc_PermissionError
PyExc_ProcessLookupError
PyExc_RecursionError
PyExc_ResourceWarning
PyExc_StopAsyncIteration
PyExc_TimeoutError
PyExc_WindowsError
PyImport_AddModuleObject
PyImport_ExecCodeModuleObject
PyImport_ImportFrozenModuleObject
PyImport_ImportModuleLevelObject
PyMarshal_ReadObjectFromString
PyMarshal_WriteLongToFile
PyMarshal_WriteObjectToFile
PyMarshal_WriteObjectToString
PyMem_Calloc
PyMember_GetOne
PyMember_SetOne
PyMemoryView_FromMemory
PyModuleDef_Init
PyModuleDef_Type
PyModule_AddFunctions
PyModule_ExecDef
PyModule_FromDefAndSpec2
PyModule_GetNameObject
PyModule_NewObject
PyModule_SetDocString
PyNode_AddChild
PyNode_Free
PyNode_ListTree
PyNode_New
PyNumber_InPlaceMatrixMultiply
PyNumber_MatrixMultiply
PyOS_CheckStack
PyOS_FSPath
PyObject_Calloc
PyObject_GenericSetDict
PyParser_SimpleParseStringFlagsFilename
PySys_AddXOption
PySys_GetXOptions
PyThread_GetInfo
PyThread_ReInitTLS
PyThread_acquire_lock
PyThread_acquire_lock_timed
PyThread_allocate_lock
PyThread_create_key
PyThread_delete_key
PyThread_delete_key_value
PyThread_exit_thread
PyThread_free_lock
PyThread_get_key_value
PyThread_get_stacksize
PyThread_get_thread_ident
PyThread_init_thread
PyThread_release_lock
PyThread_set_key_value
PyThread_set_stacksize
PyThread_start_new_thread
PyUnicode_AsMBCSString
PyUnicode_AsUCS4
PyUnicode_AsUCS4Copy
PyUnicode_AsWideCharString
PyUnicode_DecodeCodePageStateful
PyUnicode_DecodeLocale
PyUnicode_DecodeLocaleAndSize
PyUnicode_DecodeMBCS
PyUnicode_DecodeMBCSStateful
PyUnicode_EncodeCodePage
PyUnicode_EncodeLocale
PyUnicode_FindChar
PyUnicode_GetLength
PyUnicode_ReadChar
PyUnicode_Substring
PyUnicode_WriteChar
Py_DecodeLocale
Py_EncodeLocale
Py_FileSystemDefaultEncodeErrors
Py_SetPath
Py_hexdigits
_PyBytes_DecodeEscape
_PyDebug_PrintTotalRefs
_PyThreadState_Current
_PyTrash_thread_deposit_object
_PyTrash_thread_destroy_chain
_PyUnicode_DecodeUnicodeEscape
_Py_AddToAllObjects
_Py_ForgetReference
_Py_GetRefTotal
_Py_HashSecret_Initialized
_Py_NegativeRefcount
_Py_NewReference
_Py_PrintReferenceAddresses
_Py_PrintReferences
_Py_RefTotal
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161220/db6595c0/attachment.html>

From victor.stinner at gmail.com  Wed Dec 21 04:50:09 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Wed, 21 Dec 2016 10:50:09 +0100
Subject: [Python-Dev] Issue #23903 - stable API is incomplete
In-Reply-To: <a8dbaf6b-fc12-da61-843b-2e1dc2273e53@python.org>
References: <a8dbaf6b-fc12-da61-843b-2e1dc2273e53@python.org>
Message-ID: <CAMpsgwZXKrFj1KyjjnOtu85GWqz4RSR=Nn89OEL5DZT52nEV6Q@mail.gmail.com>

2016-12-21 2:52 GMT+01:00 Steve Dower <steve.dower at python.org>:
> _PyBytes_DecodeEscape
> _PyDebug_PrintTotalRefs
> _PyThreadState_Current
> _PyTrash_thread_deposit_object
> _PyTrash_thread_destroy_chain
> _PyUnicode_DecodeUnicodeEscape
> _Py_AddToAllObjects
> _Py_ForgetReference
> _Py_GetRefTotal
> _Py_HashSecret_Initialized
> _Py_NegativeRefcount
> _Py_NewReference
> _Py_PrintReferenceAddresses
> _Py_PrintReferences
> _Py_RefTotal

These functions are private. Would it be possible to not export them?

Victor

From storchaka at gmail.com  Wed Dec 21 08:06:44 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 15:06:44 +0200
Subject: [Python-Dev] Issue #23903 - stable API is incomplete
In-Reply-To: <CAMpsgwZXKrFj1KyjjnOtu85GWqz4RSR=Nn89OEL5DZT52nEV6Q@mail.gmail.com>
References: <a8dbaf6b-fc12-da61-843b-2e1dc2273e53@python.org>
 <CAMpsgwZXKrFj1KyjjnOtu85GWqz4RSR=Nn89OEL5DZT52nEV6Q@mail.gmail.com>
Message-ID: <o3dup0$pg$1@blaine.gmane.org>

On 21.12.16 11:50, Victor Stinner wrote:
> 2016-12-21 2:52 GMT+01:00 Steve Dower <steve.dower at python.org>:
>> _PyBytes_DecodeEscape
>> _PyDebug_PrintTotalRefs
>> _PyThreadState_Current
>> _PyTrash_thread_deposit_object
>> _PyTrash_thread_destroy_chain
>> _PyUnicode_DecodeUnicodeEscape
>> _Py_AddToAllObjects
>> _Py_ForgetReference
>> _Py_GetRefTotal
>> _Py_HashSecret_Initialized
>> _Py_NegativeRefcount
>> _Py_NewReference
>> _Py_PrintReferenceAddresses
>> _Py_PrintReferences
>> _Py_RefTotal
>
> These functions are private. Would it be possible to not export them?

Private functions used in public macros (like _Py_NewReference) should 
be exported.



From victor.stinner at gmail.com  Wed Dec 21 09:22:26 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Wed, 21 Dec 2016 15:22:26 +0100
Subject: [Python-Dev] Issue #23903 - stable API is incomplete
In-Reply-To: <o3dup0$pg$1@blaine.gmane.org>
References: <a8dbaf6b-fc12-da61-843b-2e1dc2273e53@python.org>
 <CAMpsgwZXKrFj1KyjjnOtu85GWqz4RSR=Nn89OEL5DZT52nEV6Q@mail.gmail.com>
 <o3dup0$pg$1@blaine.gmane.org>
Message-ID: <CAMpsgwbd7rrxa-tX63D0aE-dEk_PSmDSXjWTMamC328qYZZ1Mw@mail.gmail.com>

2016-12-21 14:06 GMT+01:00 Serhiy Storchaka <storchaka at gmail.com>:
>> These functions are private. Would it be possible to not export them?
>
> Private functions used in public macros (like _Py_NewReference) should be
> exported.

Ah, _Py_NewReference is used in the PyObject_INIT(op, typeobj) *macro*, right.

IMO it's an issue with our public API: for the stable ABI, we should
replace such macro with a function which hides implementation details.

Example from pystate.h:

#ifdef Py_BUILD_CORE
PyAPI_DATA(_Py_atomic_address) _PyThreadState_Current;
#  define PyThreadState_GET() \
             ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
#else
#  define PyThreadState_GET() PyThreadState_Get()
#endif


Ok, now why should _Py_PrintReferences() function be exported? This
private function is only called from Py_FinalizeEx(). It is not used
in a macro.

Victor

From storchaka at gmail.com  Wed Dec 21 09:51:28 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 16:51:28 +0200
Subject: [Python-Dev] PySlice_GetIndicesEx annd stable ABI: bikeshedding
Message-ID: <o3e4td$f6k$1@blaine.gmane.org>

Three months ago we discussed about an issue with PySlice_GetIndicesEx().
(https://mail.python.org/pipermail/python-dev/2016-August/145901.html)

The problem was that PySlice_GetIndicesEx() takes the size of the 
sequence, but the size of the sequence can be changed when call custom 
__index__() methods inside PySlice_GetIndicesEx().

The solution is to split PySlice_GetIndicesEx() into two functions: one 
function convert Python objects to C integers by calling __index__() 
methods, other function takes the size of the sequence and adjusts 
indices, it is atomic from Python view.

The code

     if (PySlice_GetIndicesEx(item, length,
             &start, &stop, &step, &slicelength) < 0)
         return -1;

should be replaced with

     if (foo(item, &start, &stop, &step) < 0)
         return -1;
     slicelength = bar(&start, &stop, step, length);

PySlice_GetIndicesEx() can be converted to a macro calling these two 
functions. It would be enough just recompile an extension to make it 
invulnerable to the original bug.

But there is a problem. New functions should be added to stable ABI. 
This means that we should design names and signatures of these functions 
even if don't make them a part of public API.

Let's start bikeshedding. What are your ideas about names and the order 
of arguments of two following functions?

1. Takes a slice object, returns it's start, stop and step as Py_ssize_t 
values. Can fail.

2. Takes slice's start, stop, step, and the length of the sequence (all 
are Py_ssize_t), returns adjusted start, stop, and the length of sliced 
subsequence (as Py_ssize_t). Always success.


From steve.dower at python.org  Wed Dec 21 10:41:17 2016
From: steve.dower at python.org (Steve Dower)
Date: Wed, 21 Dec 2016 07:41:17 -0800
Subject: [Python-Dev] Issue #23903 - stable API is incomplete
In-Reply-To: <CAMpsgwbd7rrxa-tX63D0aE-dEk_PSmDSXjWTMamC328qYZZ1Mw@mail.gmail.com>
References: <a8dbaf6b-fc12-da61-843b-2e1dc2273e53@python.org>
 <CAMpsgwZXKrFj1KyjjnOtu85GWqz4RSR=Nn89OEL5DZT52nEV6Q@mail.gmail.com>
 <o3dup0$pg$1@blaine.gmane.org>
 <CAMpsgwbd7rrxa-tX63D0aE-dEk_PSmDSXjWTMamC328qYZZ1Mw@mail.gmail.com>
Message-ID: <E1cJj1i-0007ci-3A@se2-syd.hostedmail.net.au>

"Ok, now why should _Py_PrintReferences() function be exported?"

It probably shouldn't, but it needs an #ifndef Py_LIMITED_API check so it is excluded from the headers (my list was automatically generated).

And ideally, private functions that are deliberately exported would have comments, or if they're new, a version check on Py_LIMITED_API.

Top-posted from my Windows Phone

-----Original Message-----
From: "Victor Stinner" <victor.stinner at gmail.com>
Sent: ?12/?21/?2016 6:25
To: "Serhiy Storchaka" <storchaka at gmail.com>
Cc: "Python Dev" <python-dev at python.org>
Subject: Re: [Python-Dev] Issue #23903 - stable API is incomplete

2016-12-21 14:06 GMT+01:00 Serhiy Storchaka <storchaka at gmail.com>:
>> These functions are private. Would it be possible to not export them?
>
> Private functions used in public macros (like _Py_NewReference) should be
> exported.

Ah, _Py_NewReference is used in the PyObject_INIT(op, typeobj) *macro*, right.

IMO it's an issue with our public API: for the stable ABI, we should
replace such macro with a function which hides implementation details.

Example from pystate.h:

#ifdef Py_BUILD_CORE
PyAPI_DATA(_Py_atomic_address) _PyThreadState_Current;
#  define PyThreadState_GET() \
             ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
#else
#  define PyThreadState_GET() PyThreadState_Get()
#endif


Ok, now why should _Py_PrintReferences() function be exported? This
private function is only called from Py_FinalizeEx(). It is not used
in a macro.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161221/f68507ce/attachment.html>

From storchaka at gmail.com  Wed Dec 21 10:47:45 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 17:47:45 +0200
Subject: [Python-Dev] Issue #23903 - stable API is incomplete
In-Reply-To: <E1cJj1i-0007ci-3A@se2-syd.hostedmail.net.au>
References: <a8dbaf6b-fc12-da61-843b-2e1dc2273e53@python.org>
 <CAMpsgwZXKrFj1KyjjnOtu85GWqz4RSR=Nn89OEL5DZT52nEV6Q@mail.gmail.com>
 <o3dup0$pg$1@blaine.gmane.org>
 <CAMpsgwbd7rrxa-tX63D0aE-dEk_PSmDSXjWTMamC328qYZZ1Mw@mail.gmail.com>
 <E1cJj1i-0007ci-3A@se2-syd.hostedmail.net.au>
Message-ID: <o3e86s$8hl$1@blaine.gmane.org>

On 21.12.16 17:41, Steve Dower wrote:
> "Ok, now why should _Py_PrintReferences() function be exported?"
>
> It probably shouldn't, but it needs an #ifndef Py_LIMITED_API check so
> it is excluded from the headers (my list was automatically generated).
>
> And ideally, private functions that are deliberately exported would have
> comments, or if they're new, a version check on Py_LIMITED_API.

Seconded.



From njs at pobox.com  Wed Dec 21 11:21:20 2016
From: njs at pobox.com (Nathaniel Smith)
Date: Wed, 21 Dec 2016 08:21:20 -0800
Subject: [Python-Dev] Issue #23903 - stable API is incomplete
In-Reply-To: <E1cJj1i-0007ci-3A@se2-syd.hostedmail.net.au>
References: <a8dbaf6b-fc12-da61-843b-2e1dc2273e53@python.org>
 <CAMpsgwZXKrFj1KyjjnOtu85GWqz4RSR=Nn89OEL5DZT52nEV6Q@mail.gmail.com>
 <o3dup0$pg$1@blaine.gmane.org>
 <CAMpsgwbd7rrxa-tX63D0aE-dEk_PSmDSXjWTMamC328qYZZ1Mw@mail.gmail.com>
 <E1cJj1i-0007ci-3A@se2-syd.hostedmail.net.au>
Message-ID: <CAPJVwBmj3kmMWtvkebta63qLNsEg7_J=FwRwtxdC6bO5XaUWaw@mail.gmail.com>

On Dec 21, 2016 7:43 AM, "Steve Dower" <steve.dower at python.org> wrote:

"Ok, now why should _Py_PrintReferences() function be exported?"

It probably shouldn't, but it needs an #ifndef Py_LIMITED_API check so it
is excluded from the headers (my list was automatically generated).


It sounds like the opt-out approach isn't working very well, and maybe an
opt-in approach should be considered instead? I recognize that the way C
headers work makes this difficult, but it seems like something needs to
change.

Or maybe the test suite should error out if any unexpected symbols appear
in the stable ABI?

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161221/bddae72e/attachment.html>

From victor.stinner at gmail.com  Wed Dec 21 11:39:08 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Wed, 21 Dec 2016 17:39:08 +0100
Subject: [Python-Dev] Issue #23903 - stable API is incomplete
In-Reply-To: <CAPJVwBmj3kmMWtvkebta63qLNsEg7_J=FwRwtxdC6bO5XaUWaw@mail.gmail.com>
References: <a8dbaf6b-fc12-da61-843b-2e1dc2273e53@python.org>
 <CAMpsgwZXKrFj1KyjjnOtu85GWqz4RSR=Nn89OEL5DZT52nEV6Q@mail.gmail.com>
 <o3dup0$pg$1@blaine.gmane.org>
 <CAMpsgwbd7rrxa-tX63D0aE-dEk_PSmDSXjWTMamC328qYZZ1Mw@mail.gmail.com>
 <E1cJj1i-0007ci-3A@se2-syd.hostedmail.net.au>
 <CAPJVwBmj3kmMWtvkebta63qLNsEg7_J=FwRwtxdC6bO5XaUWaw@mail.gmail.com>
Message-ID: <CAMpsgwaGrzA9+6chNfTv03hGPzgQYyfx=FUtLPVX3iMYsJZseA@mail.gmail.com>

2016-12-21 17:21 GMT+01:00 Nathaniel Smith <njs at pobox.com>:
> It sounds like the opt-out approach isn't working very well, and maybe an
> opt-in approach should be considered instead? I recognize that the way C
> headers work makes this difficult, but it seems like something needs to
> change.

I proposed something different:
"Python 3.7: remove all private C functions from the Python C API?"
https://mail.python.org/pipermail/python-dev/2016-September/146386.html

Create subdirectories in Include/ to define private functions in
different files.

Victor

From steve.dower at python.org  Wed Dec 21 12:11:13 2016
From: steve.dower at python.org (Steve Dower)
Date: Wed, 21 Dec 2016 09:11:13 -0800
Subject: [Python-Dev] Issue #23903 - stable API is incomplete
In-Reply-To: <CAPJVwBmj3kmMWtvkebta63qLNsEg7_J=FwRwtxdC6bO5XaUWaw@mail.gmail.com>
References: <a8dbaf6b-fc12-da61-843b-2e1dc2273e53@python.org>
 <CAMpsgwZXKrFj1KyjjnOtu85GWqz4RSR=Nn89OEL5DZT52nEV6Q@mail.gmail.com>
 <o3dup0$pg$1@blaine.gmane.org>
 <CAMpsgwbd7rrxa-tX63D0aE-dEk_PSmDSXjWTMamC328qYZZ1Mw@mail.gmail.com>
 <E1cJj1i-0007ci-3A@se2-syd.hostedmail.net.au>
 <CAPJVwBmj3kmMWtvkebta63qLNsEg7_J=FwRwtxdC6bO5XaUWaw@mail.gmail.com>
Message-ID: <E1cJkQk-0003S2-As@se2-syd.hostedmail.net.au>

"maybe the test suite should error out if any unexpected symbols appear in the stable ABI?"

This or on build (personally I prefer this sort of validation at build time, but I know others would prefer to defer it).

We have a script now that can extract all the right functions, though I think it'll only work in the source tree as it relies on clinic. But that should make it fairly straightforward to spit out a list and compare it to a checked in list.

At the same time, we have a problem in the current release, which is the functions I listed earlier. I would really like to fix that without blocking on getting the right long-term fix (since the immediate fix only affects one file in the Windows distribution, though it has implications for supportability).

Top-posted from my Windows Phone

-----Original Message-----
From: "Nathaniel Smith" <njs at pobox.com>
Sent: ?12/?21/?2016 8:22
To: "Steve Dower" <steve.dower at python.org>
Cc: "Serhiy Storchaka" <storchaka at gmail.com>; "Victor Stinner" <victor.stinner at gmail.com>; "Python Dev" <python-dev at python.org>
Subject: Re: [Python-Dev] Issue #23903 - stable API is incomplete

On Dec 21, 2016 7:43 AM, "Steve Dower" <steve.dower at python.org> wrote:

"Ok, now why should _Py_PrintReferences() function be exported?"


It probably shouldn't, but it needs an #ifndef Py_LIMITED_API check so it is excluded from the headers (my list was automatically generated).



It sounds like the opt-out approach isn't working very well, and maybe an opt-in approach should be considered instead? I recognize that the way C headers work makes this difficult, but it seems like something needs to change. 


Or maybe the test suite should error out if any unexpected symbols appear in the stable ABI?


-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161221/49fe2ff9/attachment.html>

From steve.dower at python.org  Wed Dec 21 12:14:47 2016
From: steve.dower at python.org (Steve Dower)
Date: Wed, 21 Dec 2016 09:14:47 -0800
Subject: [Python-Dev] Issue #23903 - stable API is incomplete
In-Reply-To: <CAMpsgwaGrzA9+6chNfTv03hGPzgQYyfx=FUtLPVX3iMYsJZseA@mail.gmail.com>
References: <a8dbaf6b-fc12-da61-843b-2e1dc2273e53@python.org>
 <CAMpsgwZXKrFj1KyjjnOtu85GWqz4RSR=Nn89OEL5DZT52nEV6Q@mail.gmail.com>
 <o3dup0$pg$1@blaine.gmane.org>
 <CAMpsgwbd7rrxa-tX63D0aE-dEk_PSmDSXjWTMamC328qYZZ1Mw@mail.gmail.com>
 <E1cJj1i-0007ci-3A@se2-syd.hostedmail.net.au>
 <CAPJVwBmj3kmMWtvkebta63qLNsEg7_J=FwRwtxdC6bO5XaUWaw@mail.gmail.com>
 <CAMpsgwaGrzA9+6chNfTv03hGPzgQYyfx=FUtLPVX3iMYsJZseA@mail.gmail.com>
Message-ID: <E1cJkUB-0004CY-TL@se2-syd.hostedmail.net.au>

There's a difference between "private", "stable for 3.x" and "stable for all 3" though. It's the third category that's getting too many functions added without due consideration.

Top-posted from my Windows Phone

-----Original Message-----
From: "Victor Stinner" <victor.stinner at gmail.com>
Sent: ?12/?21/?2016 8:40
To: "Nathaniel Smith" <njs at pobox.com>
Cc: "Steve Dower" <steve.dower at python.org>; "Serhiy Storchaka" <storchaka at gmail.com>; "Python Dev" <python-dev at python.org>
Subject: Re: [Python-Dev] Issue #23903 - stable API is incomplete

2016-12-21 17:21 GMT+01:00 Nathaniel Smith <njs at pobox.com>:
> It sounds like the opt-out approach isn't working very well, and maybe an
> opt-in approach should be considered instead? I recognize that the way C
> headers work makes this difficult, but it seems like something needs to
> change.

I proposed something different:
"Python 3.7: remove all private C functions from the Python C API?"
https://mail.python.org/pipermail/python-dev/2016-September/146386.html

Create subdirectories in Include/ to define private functions in
different files.

Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161221/3c32a568/attachment.html>

From brett at python.org  Wed Dec 21 12:34:14 2016
From: brett at python.org (Brett Cannon)
Date: Wed, 21 Dec 2016 17:34:14 +0000
Subject: [Python-Dev] PySlice_GetIndicesEx annd stable ABI: bikeshedding
In-Reply-To: <o3e4td$f6k$1@blaine.gmane.org>
References: <o3e4td$f6k$1@blaine.gmane.org>
Message-ID: <CAP1=2W57uZDMj10EzOvN9N9+kJz7tmykuYAFodPWM1+TXSi6EA@mail.gmail.com>

On Wed, 21 Dec 2016 at 06:52 Serhiy Storchaka <storchaka at gmail.com> wrote:

> [SNIP]
> Let's start bikeshedding. What are your ideas about names and the order
> of arguments of two following functions?
>
> 1. Takes a slice object, returns it's start, stop and step as Py_ssize_t
> values. Can fail.
>

start, stop, step


>
> 2. Takes slice's start, stop, step, and the length of the sequence (all
> are Py_ssize_t), returns adjusted start, stop, and the length of sliced
> subsequence (as Py_ssize_t). Always success.
>

length, start, stop, step

No specific ideas on names.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161221/74b3da0e/attachment.html>

From armin.rigo at gmail.com  Thu Dec 22 05:16:24 2016
From: armin.rigo at gmail.com (Armin Rigo)
Date: Thu, 22 Dec 2016 11:16:24 +0100
Subject: [Python-Dev] PySlice_GetIndicesEx annd stable ABI: bikeshedding
In-Reply-To: <o3e4td$f6k$1@blaine.gmane.org>
References: <o3e4td$f6k$1@blaine.gmane.org>
Message-ID: <CAMSv6X32MDHEKM21g+HP1dFB8kEutHQpHSUos_=1MpYm6a3w4A@mail.gmail.com>

Hi Serhiy,

On 21 December 2016 at 15:51, Serhiy Storchaka <storchaka at gmail.com> wrote:
> The code
>
>     if (PySlice_GetIndicesEx(item, length,
>             &start, &stop, &step, &slicelength) < 0)
>         return -1;
>
> should be replaced with
>
>     if (foo(item, &start, &stop, &step) < 0)
>         return -1;
>     slicelength = bar(&start, &stop, step, length);

As far as I can tell, as written, this change would not fix anything.
Shouldn't it be along the following lines instead?

    if (foo(item, &start, &stop, &step) < 0)
        return -1;
    length = PyList_GET_SIZE(mylist);   /* <= after foo() */
    slicelength = bar(&start, &stop, &step, length);


A bient?t,

Armin.

From storchaka at gmail.com  Thu Dec 22 05:34:39 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 22 Dec 2016 12:34:39 +0200
Subject: [Python-Dev] PySlice_GetIndicesEx annd stable ABI: bikeshedding
In-Reply-To: <CAMSv6X32MDHEKM21g+HP1dFB8kEutHQpHSUos_=1MpYm6a3w4A@mail.gmail.com>
References: <o3e4td$f6k$1@blaine.gmane.org>
 <CAMSv6X32MDHEKM21g+HP1dFB8kEutHQpHSUos_=1MpYm6a3w4A@mail.gmail.com>
Message-ID: <o3ga7q$6gl$1@blaine.gmane.org>

On 22.12.16 12:16, Armin Rigo wrote:
> On 21 December 2016 at 15:51, Serhiy Storchaka <storchaka at gmail.com> wrote:
>> The code
>>
>>     if (PySlice_GetIndicesEx(item, length,
>>             &start, &stop, &step, &slicelength) < 0)
>>         return -1;
>>
>> should be replaced with
>>
>>     if (foo(item, &start, &stop, &step) < 0)
>>         return -1;
>>     slicelength = bar(&start, &stop, step, length);
>
> As far as I can tell, as written, this change would not fix anything.
> Shouldn't it be along the following lines instead?
>
>     if (foo(item, &start, &stop, &step) < 0)
>         return -1;
>     length = PyList_GET_SIZE(mylist);   /* <= after foo() */
>     slicelength = bar(&start, &stop, &step, length);

Yes, the point is that length is not a constant, but a result of an 
expression and should be evaluated after calling foo().

step is not changed by bar() and can be passed by value to it.


From larry at hastings.org  Thu Dec 22 12:33:16 2016
From: larry at hastings.org (Larry Hastings)
Date: Thu, 22 Dec 2016 09:33:16 -0800
Subject: [Python-Dev] [python-committers] Should I delay 3.5.3 and 3.4.6
 by two weeks?
In-Reply-To: <9181f663-347b-fefd-ba3f-dc9d17bd9de3@ubuntu.com>
References: <b99f2412-74e8-fc96-3f2a-e0811ea7f58f@hastings.org>
 <9181f663-347b-fefd-ba3f-dc9d17bd9de3@ubuntu.com>
Message-ID: <9ed1f97c-8ffe-8908-4b36-c1bd2c778b75@hastings.org>



100% of votes cast were for "don't slip", so we won't slip.


Retreat!  Full steam behind!


//arry/

On 12/20/2016 02:25 AM, Matthias Klose wrote:
> On 19.12.2016 06:26, Larry Hastings wrote:
>> Python 3.6.0 final just slipped by two weeks. I scheduled 3.5.3 and 
>> 3.4.6 to ship about a month after 3.6.0 did, to "let the dust settle" 
>> around the release. I expect a flood of adoption of 3.6, and people 
>> switching will find bugs, and maybe those bugs are in 3.5 or 3.4. So 
>> it just seemed sensible. 3.6 just slipped by two weeks. So now 
>> there's less than two weeks between 3.6.0 final shipping and tagging 
>> the release canddiates for 3.5.3 and 3.4.6. This isn't as much time 
>> as I'd like. If I had total freedom to do as I liked, I'd slip my 
>> releases by two weeks to match 3.6. But there might be people 
>> planning around 3.5.3 and 3.4.6--like Guido was waiting for 3.5.3 for 
>> something iirc. So, if you have an opinion, please vote for one of 
>> these three options: * Don't slip 3.5.3. and 3.4.6. * Slip 3.5.3 and 
>> 3.4.6 by two weeks to match 3.6.0. * Slip 3.5.3 and 3.4.6 by a whole 
>> month, to give 3.6.0 the ability to slip again without us having to 
>> change the release. 
> I would appreciate a 3.5.3 release which doesn't slip, or which only 
> slips by a week, to be available before the Debian freeze. Neither 
> Debian nor Ubuntu ship the 3.4 branch anymore, so for 3.4 I'm fine 
> with any solution. Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161222/70f834be/attachment.html>

From vano at mail.mipt.ru  Fri Dec 16 07:23:54 2016
From: vano at mail.mipt.ru (Ivan Pozdeev)
Date: Fri, 16 Dec 2016 15:23:54 +0300
Subject: [Python-Dev] Asking for feedback about fixing `ftplib' (issue25458)
Message-ID: <63d5be01-3dfe-f3c1-8277-1d8f8f5cfc0f@mail.mipt.ru>

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

From vano at mail.mipt.ru  Mon Dec 19 06:01:04 2016
From: vano at mail.mipt.ru (Ivan Pozdeev)
Date: Mon, 19 Dec 2016 14:01:04 +0300
Subject: [Python-Dev] Asking for feedback about fixing `ftplib' (issue25458)
Message-ID: <1e6df075-21ad-686f-6e79-999f6b9ad495@mail.mipt.ru>

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

From manish.ciem at gmail.com  Thu Dec 22 12:42:19 2016
From: manish.ciem at gmail.com (Manish Singh)
Date: Thu, 22 Dec 2016 23:12:19 +0530
Subject: [Python-Dev] Python related issue
Message-ID: <CAOwixn522UJ9Wqm9gQj=fV5_W8+9m6BiyCkNv6=DY12FVVEprQ@mail.gmail.com>

Hi All,

Please see below issue. Please reply on bug
http://bugs.python.org/issue28968


[ Issue ]
I have used xml rpc library with transport as http. My client and server
are running on same host.

Some xml rpc requests fail with connection reset by peer error number. I
have used xmlrpclib.ServerProxy() to call remote method on xml rpc server
running on an ephemeral port.

This issue has happen many times.

log snippet,

  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1237, in request
    errcode, errmsg, headers = h.getreply()
  File "/usr/lib64/python2.6/httplib.py", line 1064, in getreply
    response = self._conn.getresponse()
  File "/usr/lib64/python2.6/httplib.py", line 990, in getresponse
    response.begin()
  File "/usr/lib64/python2.6/httplib.py", line 391, in begin
    version, status, reason = self._read_status()
  File "/usr/lib64/python2.6/httplib.py", line 349, in _read_status
    line = self.fp.readline()
  File "/usr/lib64/python2.6/socket.py", line 433, in readline
    data = recv(1)
error: [Errno 104] Connection reset by peer

[ Test Environment ]
RHEL 6 with linux kernel 2.6.32-504.16.2.el6.
Python 2.6.6
glibc-2.12-1.149.7


[ Possible Reasons for it ]

1) The machine is connected to the network, and the network is not
responsive.
2) The other side of the connection is not running normally.
3) There are not enough system resources available. Free up system
resources if they are running low.

Possibility for 1 and 2 are not applicable as it is loop back
communication(Client and Server running on same machine).
For Possibility 3, I have already checked system resource and there are
enough resources(80% RAM used, 20% cpu usage, around 10 GB RAM free).

I checked for other reasons and i found that this issue may be related with
GIL,
Please refer this link,
http://stackoverflow.com/questions/383738/104-connection-reset-by-peer-socket-error-or-when-does-closing-a-socket-resu

1> Can you please let me know, is it really a issue realted with GIL?
2> If yes, How to resolve this issue?
3> If no, what other reason may exists for such failure. [Note: Those rpc
requests fail which return python's dictionary data to client]

-- 
Er. Manish Singh
Engineer at NEC Technologies India Limited
Computer Science & Engineering
M.Tech ( MNNIT CS Allahabad )
B. Tech ( Calcutta Institute Of Engg. & Mgmt., Kolkata )
< email : manish.ciem at gmail.com >
< contact no. -  9899886538, 9651540577 >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161222/15491170/attachment.html>

From nad at python.org  Fri Dec 23 05:34:48 2016
From: nad at python.org (Ned Deily)
Date: Fri, 23 Dec 2016 05:34:48 -0500
Subject: [Python-Dev] [RELEASE] Python 3.6.0 is released!
Message-ID: <1C5335CD-4028-4F1C-A5EC-6A4DA615552E@python.org>

On behalf of the Python development community and the Python 3.6 release
team, I am pleased to announce the availability of Python 3.6.0.  Python
3.6.0 is the newest major release of the Python language, and it contains
many new features and optimizations.  See the "What?s New In Python 3.6"
document for more information:

    https://docs.python.org/3.6/whatsnew/3.6.html

You can download Python 3.6.0 here:

    https://www.python.org/downloads/release/python-360/

Also, most third-party distributors of Python should be making 3.6.0
packages available soon.

Maintenance releases for the 3.6 series will follow at regular intervals
starting in the first quarter of 2017.

We hope you enjoy Python 3.6.0!

P.S. As a volunteer-staffed open source project, we could not bring
Python releases to you without the enormous contributions of many,
many people.  Thank you to all who have contributed and reviewed code
and documentation changes, documented and investigated bugs, tested
Python and third-party packages, and provided and supported the
infrastructure needed to support Python development and testing.
Please consider supporting the work of the Python Software Foundation.
More at:

    https://www.python.org/psf-landing/

--
  Ned Deily
  nad at python.org -- []


From brett at python.org  Fri Dec 23 11:10:18 2016
From: brett at python.org (Brett Cannon)
Date: Fri, 23 Dec 2016 16:10:18 +0000
Subject: [Python-Dev] Python related issue
In-Reply-To: <CAOwixn522UJ9Wqm9gQj=fV5_W8+9m6BiyCkNv6=DY12FVVEprQ@mail.gmail.com>
References: <CAOwixn522UJ9Wqm9gQj=fV5_W8+9m6BiyCkNv6=DY12FVVEprQ@mail.gmail.com>
Message-ID: <CAP1=2W40cQHvQoPy3prU5TyWTt8a1DtSDrQzhANpYhF8JYWhDQ@mail.gmail.com>

In the bug it was suggested you post to python-list for help. Have you done
that? (this is python-dev, not python-list).

On Thu, 22 Dec 2016 at 14:39 Manish Singh <manish.ciem at gmail.com> wrote:

> Hi All,
>
> Please see below issue. Please reply on bug
> http://bugs.python.org/issue28968
>
>
> [ Issue ]
> I have used xml rpc library with transport as http. My client and server
> are running on same host.
>
> Some xml rpc requests fail with connection reset by peer error number. I
> have used xmlrpclib.ServerProxy() to call remote method on xml rpc server
> running on an ephemeral port.
>
> This issue has happen many times.
>
> log snippet,
>
>   File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
>     verbose=self.__verbose
>   File "/usr/lib64/python2.6/xmlrpclib.py", line 1237, in request
>     errcode, errmsg, headers = h.getreply()
>   File "/usr/lib64/python2.6/httplib.py", line 1064, in getreply
>     response = self._conn.getresponse()
>   File "/usr/lib64/python2.6/httplib.py", line 990, in getresponse
>     response.begin()
>   File "/usr/lib64/python2.6/httplib.py", line 391, in begin
>     version, status, reason = self._read_status()
>   File "/usr/lib64/python2.6/httplib.py", line 349, in _read_status
>     line = self.fp.readline()
>   File "/usr/lib64/python2.6/socket.py", line 433, in readline
>     data = recv(1)
> error: [Errno 104] Connection reset by peer
>
> [ Test Environment ]
> RHEL 6 with linux kernel 2.6.32-504.16.2.el6.
> Python 2.6.6
> glibc-2.12-1.149.7
>
>
> [ Possible Reasons for it ]
>
> 1) The machine is connected to the network, and the network is not
> responsive.
> 2) The other side of the connection is not running normally.
> 3) There are not enough system resources available. Free up system
> resources if they are running low.
>
> Possibility for 1 and 2 are not applicable as it is loop back
> communication(Client and Server running on same machine).
> For Possibility 3, I have already checked system resource and there are
> enough resources(80% RAM used, 20% cpu usage, around 10 GB RAM free).
>
> I checked for other reasons and i found that this issue may be related
> with GIL,
> Please refer this link,
>
> http://stackoverflow.com/questions/383738/104-connection-reset-by-peer-socket-error-or-when-does-closing-a-socket-resu
>
> 1> Can you please let me know, is it really a issue realted with GIL?
> 2> If yes, How to resolve this issue?
> 3> If no, what other reason may exists for such failure. [Note: Those rpc
> requests fail which return python's dictionary data to client]
>
> --
> Er. Manish Singh
> Engineer at NEC Technologies India Limited
> Computer Science & Engineering
> M.Tech ( MNNIT CS Allahabad )
> B. Tech ( Calcutta Institute Of Engg. & Mgmt., Kolkata )
> < email : manish.ciem at gmail.com >
> < contact no. -  9899886538 <(989)%20988-6538>, 9651540577 >
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161223/9a28cdff/attachment.html>

From status at bugs.python.org  Fri Dec 23 12:09:10 2016
From: status at bugs.python.org (Python tracker)
Date: Fri, 23 Dec 2016 18:09:10 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20161223170910.3A09C5657A@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2016-12-16 - 2016-12-23)
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    5652 (+13)
  closed 35159 (+52)
  total  40811 (+65)

Open issues with patches: 2439 


Issues opened (42)
==================

#28994: Misc fixes and cleanups in error handling C code
http://bugs.python.org/issue28994  opened by serhiy.storchaka

#28995: pathlib.WindowsPath.resolve() test expects short path
http://bugs.python.org/issue28995  opened by steve.dower

#28997: test_readline.test_nonascii fails on Android
http://bugs.python.org/issue28997  opened by xdegaye

#28998: Unifying Long Integers and Integers in 2.7
http://bugs.python.org/issue28998  opened by serhiy.storchaka

#28999: Use Py_RETURN_NONE and like
http://bugs.python.org/issue28999  opened by serhiy.storchaka

#29001: logging.handlers.RotatingFileHandler rotation broken under gun
http://bugs.python.org/issue29001  opened by Bruce Edge

#29002: typing.AnyStr doc is unclear about python2 unicode support
http://bugs.python.org/issue29002  opened by aj

#29003: sqlite3: can't run VACUUM on Python 3.6
http://bugs.python.org/issue29003  opened by Ma Lin

#29004: binascii.crc_hqx() implements CRC-CCITT
http://bugs.python.org/issue29004  opened by martin.panter

#29006: 2.7.13 _sqlite more prone to "database table is locked"
http://bugs.python.org/issue29006  opened by arigo

#29010: Incorrect description about scope related with inheritance
http://bugs.python.org/issue29010  opened by woo yoo

#29011: No entry Deque in typing.py
http://bugs.python.org/issue29011  opened by rhettinger

#29012: __bases__ is a tuple (possibly empty or a singleton)
http://bugs.python.org/issue29012  opened by Jim Fasarakis-Hilliard

#29013: zipfile: inconsistent doc for ZIP64 file size
http://bugs.python.org/issue29013  opened by mndavidoff

#29014: Python 3.5.2 installer doesn't register IDLE .py extensions on
http://bugs.python.org/issue29014  opened by frostyelsa

#29017: Docs: PySide is provided by 'The Qt Company' and not by 'Nokia
http://bugs.python.org/issue29017  opened by Ettore Atalan

#29020: collapse_rfc2231_value has inconsistent unquoting
http://bugs.python.org/issue29020  opened by bpoaugust

#29021: Custom functions in sqlite receive None on invalid UTF-8
http://bugs.python.org/issue29021  opened by Ingo Ruhnke

#29023: Results of random.seed() call with integer argument should be 
http://bugs.python.org/issue29023  opened by Jakub.Mateusz.Kowalski

#29024: Add Kivy entry to Graphic User Interface FAQ
http://bugs.python.org/issue29024  opened by inclement

#29025: random.seed() relation to hash() function and its determinism 
http://bugs.python.org/issue29025  opened by Jakub.Mateusz.Kowalski

#29026: time.time() documentation should mention UTC timezone
http://bugs.python.org/issue29026  opened by haypo

#29028: Use-After-Free in PyString_FromStringAndSize() of stringobject
http://bugs.python.org/issue29028  opened by dyjakan

#29029: Faster positional arguments parsing in PyArg_ParseTupleAndKeyw
http://bugs.python.org/issue29029  opened by serhiy.storchaka

#29030: argparse: choices override metavar
http://bugs.python.org/issue29030  opened by cykerway

#29033: Windows Python installer rolls back when run under SYSTEM acco
http://bugs.python.org/issue29033  opened by Mr B Jones

#29034: Fix memory leak in path_converter
http://bugs.python.org/issue29034  opened by xiang.zhang

#29035: regrtest: simplify regex to match test names for the --fromfil
http://bugs.python.org/issue29035  opened by haypo

#29036: logging module: Add `full_module_name` to LogRecord details
http://bugs.python.org/issue29036  opened by cool-RR

#29037: Python 2.7.13 prints version header and exits immediately on W
http://bugs.python.org/issue29037  opened by abkhd

#29040: building Android with android-ndk-r14
http://bugs.python.org/issue29040  opened by xdegaye

#29041: Reference leaks on Windows
http://bugs.python.org/issue29041  opened by zach.ware

#29042: os.path.exists should not throw "Embedded NUL character" excep
http://bugs.python.org/issue29042  opened by Dolda2000

#29045: Outdated C api doc about Windows error
http://bugs.python.org/issue29045  opened by xiang.zhang

#29047: Where are the test results stored?
http://bugs.python.org/issue29047  opened by patriki

#29048: Coverage influence tests, make some of them fail
http://bugs.python.org/issue29048  opened by patriki

#29049: Lazy GC tracking frame
http://bugs.python.org/issue29049  opened by inada.naoki

#29050: xml.etree.ElementTree in Python 3.6 is incompatible with defus
http://bugs.python.org/issue29050  opened by adamwill

#29051: Improve error reporting involving f-strings (PEP 498)
http://bugs.python.org/issue29051  opened by Chi Hsuan Yen

#29053: Implement >From_ decoding on input from mbox
http://bugs.python.org/issue29053  opened by bpoaugust

#29054: pty.py: pty.spawn hangs after client disconnect over nc (netca
http://bugs.python.org/issue29054  opened by Cornelius Diekmann

#29055: random.choice on empty sequence should hide previous exception
http://bugs.python.org/issue29055  opened by then0rTh



Most recent 15 issues with no replies (15)
==========================================

#29054: pty.py: pty.spawn hangs after client disconnect over nc (netca
http://bugs.python.org/issue29054

#29041: Reference leaks on Windows
http://bugs.python.org/issue29041

#29037: Python 2.7.13 prints version header and exits immediately on W
http://bugs.python.org/issue29037

#29036: logging module: Add `full_module_name` to LogRecord details
http://bugs.python.org/issue29036

#29033: Windows Python installer rolls back when run under SYSTEM acco
http://bugs.python.org/issue29033

#29029: Faster positional arguments parsing in PyArg_ParseTupleAndKeyw
http://bugs.python.org/issue29029

#29028: Use-After-Free in PyString_FromStringAndSize() of stringobject
http://bugs.python.org/issue29028

#29024: Add Kivy entry to Graphic User Interface FAQ
http://bugs.python.org/issue29024

#29023: Results of random.seed() call with integer argument should be 
http://bugs.python.org/issue29023

#29021: Custom functions in sqlite receive None on invalid UTF-8
http://bugs.python.org/issue29021

#29020: collapse_rfc2231_value has inconsistent unquoting
http://bugs.python.org/issue29020

#29017: Docs: PySide is provided by 'The Qt Company' and not by 'Nokia
http://bugs.python.org/issue29017

#29013: zipfile: inconsistent doc for ZIP64 file size
http://bugs.python.org/issue29013

#29003: sqlite3: can't run VACUUM on Python 3.6
http://bugs.python.org/issue29003

#29001: logging.handlers.RotatingFileHandler rotation broken under gun
http://bugs.python.org/issue29001



Most recent 15 issues waiting for review (15)
=============================================

#29055: random.choice on empty sequence should hide previous exception
http://bugs.python.org/issue29055

#29054: pty.py: pty.spawn hangs after client disconnect over nc (netca
http://bugs.python.org/issue29054

#29049: Lazy GC tracking frame
http://bugs.python.org/issue29049

#29048: Coverage influence tests, make some of them fail
http://bugs.python.org/issue29048

#29035: regrtest: simplify regex to match test names for the --fromfil
http://bugs.python.org/issue29035

#29034: Fix memory leak in path_converter
http://bugs.python.org/issue29034

#29029: Faster positional arguments parsing in PyArg_ParseTupleAndKeyw
http://bugs.python.org/issue29029

#29026: time.time() documentation should mention UTC timezone
http://bugs.python.org/issue29026

#29024: Add Kivy entry to Graphic User Interface FAQ
http://bugs.python.org/issue29024

#29012: __bases__ is a tuple (possibly empty or a singleton)
http://bugs.python.org/issue29012

#29011: No entry Deque in typing.py
http://bugs.python.org/issue29011

#29004: binascii.crc_hqx() implements CRC-CCITT
http://bugs.python.org/issue29004

#28999: Use Py_RETURN_NONE and like
http://bugs.python.org/issue28999

#28998: Unifying Long Integers and Integers in 2.7
http://bugs.python.org/issue28998

#28997: test_readline.test_nonascii fails on Android
http://bugs.python.org/issue28997



Top 10 most discussed issues (10)
=================================

#29014: Python 3.5.2 installer doesn't register IDLE .py extensions on
http://bugs.python.org/issue29014  31 msgs

#28971: nntplib is broken when responses are longer than _MAXLINE
http://bugs.python.org/issue28971  13 msgs

#28945: get_boundary (and get_filename) invokes unquote twice
http://bugs.python.org/issue28945  12 msgs

#28879: smtplib send_message should add Date header if it is missing, 
http://bugs.python.org/issue28879  11 msgs

#29010: Incorrect description about scope related with inheritance
http://bugs.python.org/issue29010  11 msgs

#29050: xml.etree.ElementTree in Python 3.6 is incompatible with defus
http://bugs.python.org/issue29050   9 msgs

#29034: Fix memory leak in path_converter
http://bugs.python.org/issue29034   8 msgs

#28180: sys.getfilesystemencoding() should default to utf-8
http://bugs.python.org/issue28180   7 msgs

#28968: xml rpc server fails with connection reset by peer error no 10
http://bugs.python.org/issue28968   7 msgs

#27584: New addition of vSockets to the python socket module
http://bugs.python.org/issue27584   6 msgs



Issues closed (49)
==================

#14061: Misc fixes and cleanups in archiving code in shutil and test_s
http://bugs.python.org/issue14061  closed by serhiy.storchaka

#18896: Remove namedtuple 255 arguments restriction
http://bugs.python.org/issue18896  closed by serhiy.storchaka

#19542: WeakValueDictionary bug in setdefault()&pop()
http://bugs.python.org/issue19542  closed by pitrou

#20191: resource.prlimit(int, int, str) crashs
http://bugs.python.org/issue20191  closed by serhiy.storchaka

#24383: consider implementing __await__ on concurrent.futures.Future
http://bugs.python.org/issue24383  closed by yselivanov

#25677: Syntax error caret confused by indentation
http://bugs.python.org/issue25677  closed by martin.panter

#26342: Faster bit ops for single-digit positive longs
http://bugs.python.org/issue26342  closed by yselivanov

#26928: _bootlocale imports locale at startup on Android, causing test
http://bugs.python.org/issue26928  closed by xdegaye

#27574: Faster parsing keyword arguments
http://bugs.python.org/issue27574  closed by serhiy.storchaka

#28147: Unbounded memory growth resizing split-table dicts
http://bugs.python.org/issue28147  closed by inada.naoki

#28383: __hash__ documentation recommends naive XOR to combine but thi
http://bugs.python.org/issue28383  closed by haypo

#28407: Improve coverage of email.utils.make_msgid()
http://bugs.python.org/issue28407  closed by r.david.murray

#28512: PyErr_SyntaxLocationEx() and PyErr_SyntaxLocationObject() alwa
http://bugs.python.org/issue28512  closed by serhiy.storchaka

#28538: _socket module cross-compilation error on android-24
http://bugs.python.org/issue28538  closed by xdegaye

#28596: on Android _bootlocale on startup relies on too many library m
http://bugs.python.org/issue28596  closed by xdegaye

#28762: lockf() is available now on Android API level 24, but the F_LO
http://bugs.python.org/issue28762  closed by xdegaye

#28822: Fix indices handling in PyUnicode_FindChar
http://bugs.python.org/issue28822  closed by xiang.zhang

#28871: Destructor of ElementTree.Element is recursive
http://bugs.python.org/issue28871  closed by serhiy.storchaka

#28923: Nonexisting encoding specified in Tix.py
http://bugs.python.org/issue28923  closed by terry.reedy

#28927: bytes.fromhex should ignore all whitespace
http://bugs.python.org/issue28927  closed by serhiy.storchaka

#28932: Fail compile Python 3.6.0rc1 on OpenBSD 6.0
http://bugs.python.org/issue28932  closed by python-dev

#28950: regrtest: -j0 fails the check -j is not allowed together with 
http://bugs.python.org/issue28950  closed by xiang.zhang

#28957: undefined symbol: PyUnicodeUCS2_FromUnicode when executing any
http://bugs.python.org/issue28957  closed by berker.peksag

#28986: Docs should say set.update takes iterable
http://bugs.python.org/issue28986  closed by rhettinger

#28987: Remove typo in whats new entry on Descriptor Protocol Enhancem
http://bugs.python.org/issue28987  closed by martin.panter

#28990: asyncio SSL hangs if connection is closed before handshake com
http://bugs.python.org/issue28990  closed by ned.deily

#28991: Fix obscure lru_cache reentrancy bug
http://bugs.python.org/issue28991  closed by rhettinger

#28992: Use bytes.fromhex()
http://bugs.python.org/issue28992  closed by serhiy.storchaka

#28993: math.ceil() python 2.7
http://bugs.python.org/issue28993  closed by zach.ware

#28996: wcscoll is broken on Android and test_locale fails
http://bugs.python.org/issue28996  closed by xdegaye

#29000: Not matched behavior within printf style bytes formatting
http://bugs.python.org/issue29000  closed by serhiy.storchaka

#29005: Possibly incorrect description about method objects
http://bugs.python.org/issue29005  closed by r.david.murray

#29007: Virus detected when attempting to download  numpy-1.11.3-cp35-
http://bugs.python.org/issue29007  closed by berker.peksag

#29008: Can't do dict comp from previously defined dict in the outermo
http://bugs.python.org/issue29008  closed by xiang.zhang

#29009: Outdated part in the doc of PyUnicode_RichCompare
http://bugs.python.org/issue29009  closed by xiang.zhang

#29015: re slashes
http://bugs.python.org/issue29015  closed by serhiy.storchaka

#29016: negative numbers raised to power zero should be 1, not -1
http://bugs.python.org/issue29016  closed by tim.peters

#29018: Misinformation when showing how slices work in The Tutorial
http://bugs.python.org/issue29018  closed by steven.daprano

#29019: dict.fromkeys overallocates when given a sparse dict
http://bugs.python.org/issue29019  closed by inada.naoki

#29022: Aritmetic error
http://bugs.python.org/issue29022  closed by berker.peksag

#29027: 3.5.2 compile error from ssl related.
http://bugs.python.org/issue29027  closed by christian.heimes

#29031: 'from module import *' and __all__
http://bugs.python.org/issue29031  closed by eryksun

#29032: How does the __self__ attribute of method become a class rathe
http://bugs.python.org/issue29032  closed by woo yoo

#29038: Duplicate entry for SSLContext.get_ca_certs() in ssl
http://bugs.python.org/issue29038  closed by xiang.zhang

#29039: Segmentation fault when using PyUnicode_FromString
http://bugs.python.org/issue29039  closed by xiang.zhang

#29043: dict view string representations are misleading
http://bugs.python.org/issue29043  closed by rhettinger

#29044: Use after free in string '%c' formater
http://bugs.python.org/issue29044  closed by xiang.zhang

#29046: Coverage related documentation missing
http://bugs.python.org/issue29046  closed by patriki

#29052: Detect Windows platform 32bit/64bit automatically
http://bugs.python.org/issue29052  closed by berker.peksag

From njs at pobox.com  Sat Dec 24 18:48:33 2016
From: njs at pobox.com (Nathaniel Smith)
Date: Sat, 24 Dec 2016 15:48:33 -0800
Subject: [Python-Dev] --with-fpectl changes the CPython ABI
Message-ID: <CAPJVwB=nUk7YaZTqk8gJcK5RymoPbcJqpZC8oBBFX=1Xdr9cfA@mail.gmail.com>

Hi all,

Well, we finally got that ucs2/ucs4 stuff all sorted out (yay), but I
just learned that there's another CPython build flag that also changes
the ABI: --with-fpectl

Specifically, it seems that if you build CPython with --with-fpectl,
and then use that CPython to build an extension module, and that
extension module uses PyFPE_{START,END}_PROTECT (like e.g. Cython
modules do), and you then try to import that extension module on a
CPython that *wasn't* built with --with-fpectl, then it will crash.
This bug report has more gory details:
    https://github.com/numpy/numpy/issues/8415

The reverse is OK -- extensions built in a no-fpectl CPython can be
imported by both no-fpectl and yes-fpectl CPythons.

So one consequence is easy -- we need to make a note in the manylinux1
definition saying that you have to use a no-fpectl CPython build to
make manylinux1 wheels, because that's the only way to guarantee
compatibility. I just submitted a PR for this:
  https://github.com/python/peps/pull/166
(Fortunately the manylinux1 docker images are already set up this way,
so in practice I think everyone is already doing this.)

But... in general this is kind of an unfortunate issue, and it's not
restricted to Linux. Should we do something? Some options:

Add another ABI flag -- e.g. cp35dmf vs. cp35dm? Though AFAICT the
offending macros are actually part of the allegedly stable ABI (!!),
so I guess this isn't really a solution. (I'm not 100% confident about
how to tell whether something is part of the stable ABI, but: Python.h
unconditionally imports pyfpe.h, and pyfpe.h doesn't have any
Py_LIMITED_API checks.)

Drop support for fpectl entirely in 3.7 on the grounds that it's not
worth the trouble? (The docs have said "don't use this" at the top
forever[1], and after clicking through every hit on github code search
for language = Python and string "turnon_sigfpe" [2], I found exactly
4 non-documentation usages [3], all of which are already broken in
no-fpectl builds.) We obviously can't do this in a point release
though, because there are lots of extant extension modules referencing
these symbols.

Or maybe make it so that even no-fpectl builds still export the
necessary symbols so that yes-fpectl extensions don't crash on import?
(This has the advantage that it can be done in a point release...)

Thoughts?

-n

[1] https://docs.python.org/2/library/fpectl.html
[2] https://github.com/search?l=Python&p=1&q=turnon_sigfpe&type=Code&utf8=%E2%9C%93
[3]
  https://github.com/podhrmic/JSBSim/blob/36de9ac63c959cef5d7b2c56fb49c1a57fd46369/tests/CheckScripts.py#L28
  https://github.com/tmbdev/iuprlab/blob/239918b5ec0f8deecbc7c2ec1283a837d11a7b5a/boostedmlp.py#L161
  https://github.com/wcs211/BEM-3D-Python/blob/874aaeffc3dac5f698f875478c3accf2b5a14daf/FSI_bem3d.py#L25
  https://github.com/neobonzi/SoundPlagiarism/blob/7cff7f0145217bffb3a3cebd59a946feee23aff6/processor.py#L31

-- 
Nathaniel J. Smith -- https://vorpus.org

From g.rodola at gmail.com  Sun Dec 25 09:21:10 2016
From: g.rodola at gmail.com (Giampaolo Rodola')
Date: Sun, 25 Dec 2016 15:21:10 +0100
Subject: [Python-Dev] Asking for feedback about fixing `ftplib'
 (issue25458)
In-Reply-To: <1e6df075-21ad-686f-6e79-999f6b9ad495@mail.mipt.ru>
References: <1e6df075-21ad-686f-6e79-999f6b9ad495@mail.mipt.ru>
Message-ID: <CAFYqXL_pyyOiB6nc0V_mk-QzwbDXeVUgCnB1FKAOFFVjSFv7wA@mail.gmail.com>

>From what I understand the problem should be fixed in urllib so that it
always closes the FTP connection. I understand this is what happens in
recent 3.x versions but not on 2.7.
As for ftplib, I don't like the solution of using a `transfer_in_progress`
flag in all commands. I see that as a cheap way to work around the fact
that the user may forget to call voidresp() and close the socket after
nt/transfercmd().
It probably makes sense to just update nt/transfercmd() doc instead and
make that clear.


On Mon, Dec 19, 2016 at 12:01 PM, Ivan Pozdeev via Python-Dev <
python-dev at python.org> wrote:

> 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
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/g.rodola%
> 40gmail.com
>



-- 
Giampaolo - http://grodola.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161225/b90fb1cd/attachment.html>

From ncoghlan at gmail.com  Sun Dec 25 20:55:04 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 26 Dec 2016 11:55:04 +1000
Subject: [Python-Dev] --with-fpectl changes the CPython ABI
In-Reply-To: <CAPJVwB=nUk7YaZTqk8gJcK5RymoPbcJqpZC8oBBFX=1Xdr9cfA@mail.gmail.com>
References: <CAPJVwB=nUk7YaZTqk8gJcK5RymoPbcJqpZC8oBBFX=1Xdr9cfA@mail.gmail.com>
Message-ID: <CADiSq7f0NPouBWaCkfLnyQrDWYMq+_23gZDRaXE2ggcWG2AxJQ@mail.gmail.com>

On 25 December 2016 at 09:48, Nathaniel Smith <njs at pobox.com> wrote:

> Or maybe make it so that even no-fpectl builds still export the
> necessary symbols so that yes-fpectl extensions don't crash on import?
> (This has the advantage that it can be done in a point release...)
>

This seems like a sensible thing to do in 3.6, 3.5 and 2.7 regardless of
what happens in 3.7.

For 3.7, I don't understand the trade-offs well enough to have a strong
opinion, but dropping the feature entirely does seem reasonable - folks
that want fine-grained floating point exception control these days are
likely to be much better served by the decimal module, or one of the third
party computing libraries (numpy, gmpy, sympy, etc).

There was a thread back in 2012 [1] regarding the possibility of instead
updating floats to offer flexibility similar to that offered by those other
modules, but I think our discussions of the expected semantics of a decimal
literal show that that would be a bad idea - context dependent behaviour in
numeric literals creates all sorts of problems at the level of compiler and
interpreter design.

Cheers,
Nick.

[1] https://mail.python.org/pipermail/python-ideas/2012-October/016768.html

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161226/f50fb1f8/attachment.html>

From v+python at g.nevcal.com  Mon Dec 26 04:25:56 2016
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Mon, 26 Dec 2016 01:25:56 -0800
Subject: [Python-Dev] Merry Christmas to me, and Python users everywhere
Message-ID: <f849e16b-76da-1164-b675-5f21a33a5614@g.nevcal.com>

I didn't see an announcement that 3.6.0 had actually been released, but 
I have been longing for the ability to actually write UTF-8 strings to 
the console without using "ascii" or "json.dumps" to avoid the cp437 
codec, and be able to write characters from other the whole Unicode 
repertoire. I was sitting here wishing I could better read some such 
output...

The schedule was 23 December 2016. I decided to see if it had been released.

It seems to be there on Python.org!

I installed it today, which is, as far as I am concerned, still 
Christmas until I go to bed, which will be soon, and it is really still 
Christmas in Hawaii as I type this.  So Merry Christmas to me, and to 
Python users everywhere.

And I changed one of my many programs that want to print UTF-8 to the 
console, and it worked. I am happy.

Many, many thanks to Steve Dower, who actually pushed the PEPs into the 
release, as well as all the other people that have been involved in 
incremental reports, workarounds, and ideas throughout the course of 
Issue1602.

And congratulations to everyone on a successful release.

Glenn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161226/e8828fd9/attachment.html>

From storchaka at gmail.com  Mon Dec 26 12:15:54 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Mon, 26 Dec 2016 19:15:54 +0200
Subject: [Python-Dev] PySlice_GetIndicesEx annd stable ABI: bikeshedding
In-Reply-To: <CAP1=2W57uZDMj10EzOvN9N9+kJz7tmykuYAFodPWM1+TXSi6EA@mail.gmail.com>
References: <o3e4td$f6k$1@blaine.gmane.org>
 <CAP1=2W57uZDMj10EzOvN9N9+kJz7tmykuYAFodPWM1+TXSi6EA@mail.gmail.com>
Message-ID: <o3rj85$4ph$1@blaine.gmane.org>

On 21.12.16 19:34, Brett Cannon wrote:
> On Wed, 21 Dec 2016 at 06:52 Serhiy Storchaka <storchaka at gmail.com
> <mailto:storchaka at gmail.com>> wrote:
>
>     [SNIP]
>     Let's start bikeshedding. What are your ideas about names and the order
>     of arguments of two following functions?
>
>     1. Takes a slice object, returns it's start, stop and step as Py_ssize_t
>     values. Can fail.
>
>
> start, stop, step
>
>
>
>     2. Takes slice's start, stop, step, and the length of the sequence (all
>     are Py_ssize_t), returns adjusted start, stop, and the length of sliced
>     subsequence (as Py_ssize_t). Always success.
>
>
> length, start, stop, step
>
> No specific ideas on names.

Thank you for your response Brett.



From v+python at g.nevcal.com  Mon Dec 26 23:46:28 2016
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Mon, 26 Dec 2016 20:46:28 -0800
Subject: [Python-Dev] Merry Christmas to me, and Python users everywhere
In-Reply-To: <f849e16b-76da-1164-b675-5f21a33a5614@g.nevcal.com>
References: <f849e16b-76da-1164-b675-5f21a33a5614@g.nevcal.com>
Message-ID: <c75e355b-84b3-4e06-18c8-26120974487e@g.nevcal.com>

On 12/26/2016 1:25 AM, Glenn Linderman wrote:
> I didn't see an announcement that 3.6.0 had actually been released

Off list, Burkhard Meier helped me figure out why I hadn't seen the 
announcement:

It was sent as one email cross-posted to multiple groups. I am 
subscribed to 3 of those groups: python-announce, python-list, 
python-dev with this same email address. My mail filter rules would have 
seen the many To: address, and filtered /all/ copies I received to the 
python-list mailbox, because my filter rules looked for python-list 
before python-dev.  I've just changed that to give priority to 
python-dev before the others. (just one of the evil side-effects of 
cross-posting!)

But, as far as I can tell, I only received one message, and that went to 
the wrong folder first... the one where python-list should go.  In 
reviewing my filters, I was reminded that python-announce and python-dev 
go to the same folder, which I read regularly. The python-list folder I 
can't keep up with, I read it occasionally, and search it when I have 
questions -- using it as a locally stored resource of helpful tips, and 
that is where the announcement went, because of the order of my filter 
rules, and the cross-posted announcement.

So either Google (my email host) noticed that I got 3 of the same 
message, and suppressed two of them, or the python-dev mail server that 
hosts the mailing lists merged the expanded destinations with duplicate 
suppression. I'm inclined to think the former is more likely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161226/6b725714/attachment.html>

From ethan at stoneleaf.us  Tue Dec 27 11:09:04 2016
From: ethan at stoneleaf.us (Ethan Furman)
Date: Tue, 27 Dec 2016 08:09:04 -0800
Subject: [Python-Dev] Merry Christmas to me, and Python users everywhere
In-Reply-To: <c75e355b-84b3-4e06-18c8-26120974487e@g.nevcal.com>
References: <f849e16b-76da-1164-b675-5f21a33a5614@g.nevcal.com>
 <c75e355b-84b3-4e06-18c8-26120974487e@g.nevcal.com>
Message-ID: <58629220.10205@stoneleaf.us>

On 12/26/2016 08:46 PM, Glenn Linderman wrote:

> So either Google (my email host) noticed that I got 3 of the same message,
>  and suppressed two of them, or the python-dev mail server that hosts the
>  mailing lists merged the expanded destinations with duplicate suppression.
>  I'm inclined to think the former is more likely.

I am also subscribed to those mailing lists, I do not use gmail, and I got all three.

--
~Ethan~

From storchaka at gmail.com  Tue Dec 27 14:04:22 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 21:04:22 +0200
Subject: [Python-Dev] Document C API that is not part of the limited API
Message-ID: <o3udvh$cbr$1@blaine.gmane.org>

 From the documentation:

https://docs.python.org/3/c-api/stable.html

     In the C API documentation, API elements that are not part of the 
limited API are marked as "Not part of the limited API."

But they don't.

I prepared a sample patch that adds the notes to Unicode Objects and 
Codecs C API (http://bugs.python.org/issue29086). I'm going to add them 
to all C API.

What are your though about formatting the note? Should it be before the 
description, after the description, but before the "deprecated" 
directive (as in the patch), or after the first paragraph of the 
description? Should it be on the separate line or be appended at the end 
of the previous paragraph, or starts the first paragraph (if before the 
description)? May be introduce a special directive for it?



From ronaldoussoren at mac.com  Tue Dec 27 14:14:26 2016
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 27 Dec 2016 20:14:26 +0100
Subject: [Python-Dev] Document C API that is not part of the limited API
In-Reply-To: <o3udvh$cbr$1@blaine.gmane.org>
References: <o3udvh$cbr$1@blaine.gmane.org>
Message-ID: <5F9E3B2F-BAB4-49FC-ABEA-9BD52BE7C5DB@mac.com>


> On 27 Dec 2016, at 20:04, Serhiy Storchaka <storchaka at gmail.com> wrote:
> 
> From the documentation:
> 
> https://docs.python.org/3/c-api/stable.html
> 
>    In the C API documentation, API elements that are not part of the limited API are marked as "Not part of the limited API."
> 
> But they don't.
> 
> I prepared a sample patch that adds the notes to Unicode Objects and Codecs C API (http://bugs.python.org/issue29086). I'm going to add them to all C API.
> 
> What are your though about formatting the note? Should it be before the description, after the description, but before the "deprecated" directive (as in the patch), or after the first paragraph of the description? Should it be on the separate line or be appended at the end of the previous paragraph, or starts the first paragraph (if before the description)? May be introduce a special directive for it?

A directive would make it easier to ensure that the text about the stable API is consistent.  I?d also consider adding that directive to all API?s that *are* part of the stable API instead of the other way around (that would also require changes to ?/stable.html). That would have two advantages: firstly it makes it easier to document from which version an API is part of the stable ABI, and secondly forgetting the annotation would imply that an API is not part of the stable ABI instead of accidentally claiming to increase the stable ABI.

Ronald


From v+python at g.nevcal.com  Tue Dec 27 16:34:04 2016
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Tue, 27 Dec 2016 13:34:04 -0800
Subject: [Python-Dev] Merry Christmas to me, and Python users everywhere
In-Reply-To: <58629220.10205@stoneleaf.us>
References: <f849e16b-76da-1164-b675-5f21a33a5614@g.nevcal.com>
 <c75e355b-84b3-4e06-18c8-26120974487e@g.nevcal.com>
 <58629220.10205@stoneleaf.us>
Message-ID: <b33573b1-4765-1fce-02fc-323099f6ff0e@g.nevcal.com>

On 12/27/2016 8:09 AM, Ethan Furman wrote:
> On 12/26/2016 08:46 PM, Glenn Linderman wrote:
>
>> So either Google (my email host) noticed that I got 3 of the same 
>> message,
>>  and suppressed two of them, or the python-dev mail server that hosts 
>> the
>>  mailing lists merged the expanded destinations with duplicate 
>> suppression.
>>  I'm inclined to think the former is more likely.
>
> I am also subscribed to those mailing lists, I do not use gmail, and I 
> got all three.

Thanks for this extra information, Ethan. That points at Gmail pretty 
conclusively as the source of the reduction in number of messages. Since 
it has long been known that Gmail suppresses CC or BCC to self, it is 
likely that suppressing duplicate messages from cross-posted mailing 
lists is also done... likely achieved due to matching Message-Id values.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161227/031cbb61/attachment.html>

From glenn at nevcal.com  Wed Dec 28 00:17:32 2016
From: glenn at nevcal.com (Glenn Linderman)
Date: Tue, 27 Dec 2016 21:17:32 -0800
Subject: [Python-Dev] PEP 514 and pywin32
Message-ID: <233e092a-902f-cf74-66b0-a8665fc3edc4@nevcal.com>

So today I tried to install pywin32 on my new Python 3.6.0 and got the 
following error:

---------------------------
Cannot install
---------------------------
Python version 3.6-32 required, which was not found in the registry.
---------------------------
OK
---------------------------

Seems like pywin32, although built for 3.6, doesn't understand or 
conform to the PEP 514? So the installer doesn't work? I suspect maybe 
the code would still work, if it would install. I also noted that pip 
cannot find a compatible pywin32, and PyPI only reports compatibility 
through Python 3.3.

1. Where should this be reported? SourceForge?
2. Anyone know a workaround?

-- 
Glenn
------------------------------------------------------------------------
Experience is that marvelous thing that enables you to recognize a
mistake when you make it again. -- Franklin Jones
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161227/f9284ef7/attachment.html>

From burkhardameier at gmail.com  Wed Dec 28 04:40:07 2016
From: burkhardameier at gmail.com (Burkhard Meier)
Date: Wed, 28 Dec 2016 01:40:07 -0800
Subject: [Python-Dev] PEP 514 and pywin32
In-Reply-To: <233e092a-902f-cf74-66b0-a8665fc3edc4@nevcal.com>
References: <233e092a-902f-cf74-66b0-a8665fc3edc4@nevcal.com>
Message-ID: <CACKxkAwi_hzzn11aTPx_=UBqsF627VwjHbz0GO4iKNvF+QnSyg@mail.gmail.com>

Try the 'gohlke' download site. Whenever getting stuck in some of the
newest Python 3.x versions, that side usually has installers that work. It
did work for me just now, using Python 3.6.0 64-bit on Windows 10 64-bit OS.

[image: Inline image 1]

Burkhard

On Tue, Dec 27, 2016 at 9:17 PM, Glenn Linderman <glenn at nevcal.com> wrote:

> So today I tried to install pywin32 on my new Python 3.6.0 and got the
> following error:
>
> ---------------------------
> Cannot install
> ---------------------------
> Python version 3.6-32 required, which was not found in the registry.
> ---------------------------
> OK
> ---------------------------
>
> Seems like pywin32, although built for 3.6, doesn't understand or conform
> to the PEP 514? So the installer doesn't work? I suspect maybe the code
> would still work, if it would install. I also noted that pip cannot find a
> compatible pywin32, and PyPI only reports compatibility through Python 3.3.
>
> 1. Where should this be reported? SourceForge?
> 2. Anyone know a workaround?
>
> --
> Glenn
> ------------------------------
> Experience is that marvelous thing that enables you to recognize a
> mistake when you make it again. -- Franklin Jones
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> burkhardameier%40gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161228/bbb9780a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 82227 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161228/bbb9780a/attachment-0001.png>

From vano at mail.mipt.ru  Wed Dec 28 09:57:12 2016
From: vano at mail.mipt.ru (Ivan Pozdeev)
Date: Wed, 28 Dec 2016 17:57:12 +0300
Subject: [Python-Dev] Asking for feedback about fixing `ftplib'
 (issue25458)
In-Reply-To: <CAFYqXL_pyyOiB6nc0V_mk-QzwbDXeVUgCnB1FKAOFFVjSFv7wA@mail.gmail.com>
References: <1e6df075-21ad-686f-6e79-999f6b9ad495@mail.mipt.ru>
 <CAFYqXL_pyyOiB6nc0V_mk-QzwbDXeVUgCnB1FKAOFFVjSFv7wA@mail.gmail.com>
Message-ID: <58b387e9-4120-8a23-a213-09127f044892@mail.mipt.ru>

Re: [Python-Dev] Asking for feedback about fixing `ftplib' (issue25458) 
On 25.12.2016 17:21, Giampaolo Rodola' wrote:
> From what I understand the problem should be fixed in urllib so that 
> it always closes the FTP connection. I understand this is what happens 
> in recent 3.x versions but not on 2.7.
urllib in 2.7 should indeed be fixed to close FTP connections rather 
than leave them dangling, no question about that.
(ftpcache probably has to go in all branches as a result since it's now 
useless - but that's another issue entirely)

The question is, in both 2.x and 3.x, urllib currently doesn't close the 
control connection gracefully. It just closes the socket immediately 
after reading all data on the data connection - without issuing QUIT or 
even reading the end-of-transfer response.
By doing this, it gets away with not calling voidresp().
(RFC 939 specifies that the server should execute the equivalent of ABOR 
and QUIT upon unexpected close of control connection.)
> As for ftplib, I don't like the solution of using a 
> `transfer_in_progress` flag in all commands. I see that as a cheap way 
> to work around the fact that the user may forget to call voidresp() 
> and close the socket after nt/transfercmd(). It probably makes sense 
> to just update nt/transfercmd() doc instead and make that clear.
I tried to fix urllib so that it's guaranteed to call voidresp(), and 
failed. Too complicated, effectively reimplementing a sizable part of 
FTP client logic is required, perhaps even monkey-patching ftplib to be 
able to set flags in the right places. That's why I thought that just 
requiring the user to call it themselves and calling it a day would be 
asking too much from users and the easy way out - ftplib currently dumps 
too much work on its users that it ought to do itself instead.

The fact that in FTP, one cannot send another command before the 
previous one is complete (or rather, one can, but the server won't 
respond to it until then) means that FTP is inherently stateful. So, 
ftplib, to be a usable library, needs to either encapsulate this 
statefulness, or provide building blocks with all the stock logic parts 
so that only truly application-specific logic has to be added to make a 
robust solution.

With simple commands (|voidcmd|) and self-contained transfer commands 
(retrlines/retrbinary), ftplib does incapsulate statefulness, by 
handling them atomically. But with transfercmd(), it returns control to 
the user halfway through.
At this point, if ftplib doesn't itself keep track that the control 
connection is currently in invalid state for the next command, the user 
is forced to do that themselves instead. And guess what - urllib has to 
use ftplib through a wrapper class that does exactly that. That's 
definitely a "stock logic part" 'cuz it's an integral part of FTP rather 
than something specific to user logic.

The other "stock logic part" currently missing is error handling during 
transfer. If the error's cause is local (like a local exception that 
results in closing the data socket prematurely, or the user closing it 
by hand, or an ABOR they sent midway), the error code from the 
end-of-transfer response should be ignored, otherwise, it shouldn't.
Nothing currently provides this logic. ftplib.retr*() never ignore the 
code - because they never abort the transfer - but they don't handle 
exceptions, either, so they wouldn't read the response if one is raised 
on data socket read or in the callback. urllib used to handle the 
response in an overridden socket close handler, and it was forced to 
always ignore the code because it's impossible to check from there if 
there was an exception or if the data socket was closed prematurely.
--
Other than making ftplib keep track of the session's internal state 
while the user has control and providing the custom error handling logic 
to them, another solution is to never release control to the user 
midway, i.e. ban transfercmd() entirely and only provide self-contained 
retr*()/dir()/whatever, but let the callback signal them to abort the 
transfer. That way, the state would be kept implicitly - in the 
execution pointer.


> -- 
> Giampaolo - http://grodola.blogspot.com
>

-- 
Regards,
Ivan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161228/318b7763/attachment.html>

From steve.dower at python.org  Wed Dec 28 12:09:42 2016
From: steve.dower at python.org (Steve Dower)
Date: Wed, 28 Dec 2016 09:09:42 -0800
Subject: [Python-Dev] PEP 514 and pywin32
In-Reply-To: <CACKxkAwi_hzzn11aTPx_=UBqsF627VwjHbz0GO4iKNvF+QnSyg@mail.gmail.com>
References: <233e092a-902f-cf74-66b0-a8665fc3edc4@nevcal.com>
 <CACKxkAwi_hzzn11aTPx_=UBqsF627VwjHbz0GO4iKNvF+QnSyg@mail.gmail.com>
Message-ID: <E1cMHk7-0005Xf-ET@se2-syd.hostedmail.net.au>

It's likely that they're using the broken version of bdist_wininst for their installer (I thought Mark reported the issue and had a workaround though...). It's already fixed, but hasn't been released yet.

Another workaround is to use "wheel convert" on the exe and then install the wheel. You miss out on their post-install steps, but most people don't need those anyway.

Cheers,
Steve

Top-posted from my Windows Phone

-----Original Message-----
From: "Burkhard Meier" <burkhardameier at gmail.com>
Sent: ?12/?28/?2016 1:43
To: "Glenn Linderman" <glenn at nevcal.com>
Cc: "Python Dev" <python-dev at python.org>
Subject: Re: [Python-Dev] PEP 514 and pywin32

Try the 'gohlke' download site. Whenever getting stuck in some of the newest Python 3.x versions, that side usually has installers that work. It did work for me just now, using Python 3.6.0 64-bit on Windows 10 64-bit OS.






Burkhard


On Tue, Dec 27, 2016 at 9:17 PM, Glenn Linderman <glenn at nevcal.com> wrote:

So today I tried to install pywin32 on my new Python 3.6.0 and got the following error:

---------------------------
Cannot install
---------------------------
Python version 3.6-32 required, which was not found in the registry.
---------------------------
OK   
---------------------------

Seems like pywin32, although built for 3.6, doesn't understand or conform to the PEP 514? So the installer doesn't work? I suspect maybe the code would still work, if it would install. I also noted that pip cannot find a compatible pywin32, and PyPI only reports compatibility through Python 3.3.

1. Where should this be reported? SourceForge?
2. Anyone know a workaround?


-- 
Glenn 


Experience is that marvelous thing that enables you to recognize a
mistake when you make it again. -- Franklin Jones 

_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/burkhardameier%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161228/dc930c31/attachment.html>

From barry at python.org  Tue Dec 27 12:58:48 2016
From: barry at python.org (Barry Warsaw)
Date: Tue, 27 Dec 2016 12:58:48 -0500
Subject: [Python-Dev] Merry Christmas to me, and Python users everywhere
In-Reply-To: <b33573b1-4765-1fce-02fc-323099f6ff0e@g.nevcal.com>
References: <f849e16b-76da-1164-b675-5f21a33a5614@g.nevcal.com>
 <c75e355b-84b3-4e06-18c8-26120974487e@g.nevcal.com>
 <58629220.10205@stoneleaf.us>
 <b33573b1-4765-1fce-02fc-323099f6ff0e@g.nevcal.com>
Message-ID: <20161227125848.72ce0aba.barry@wooz.org>

On Dec 27, 2016, at 01:34 PM, Glenn Linderman wrote:

>Thanks for this extra information, Ethan. That points at Gmail pretty
>conclusively as the source of the reduction in number of messages. Since it
>has long been known that Gmail suppresses CC or BCC to self, it is likely
>that suppressing duplicate messages from cross-posted mailing lists is also
>done... likely achieved due to matching Message-Id values.

https://wiki.list.org/x/4030680

Cheers,
-Barry

From g.rodola at gmail.com  Wed Dec 28 13:02:49 2016
From: g.rodola at gmail.com (Giampaolo Rodola')
Date: Wed, 28 Dec 2016 19:02:49 +0100
Subject: [Python-Dev] Asking for feedback about fixing `ftplib'
 (issue25458)
In-Reply-To: <58b387e9-4120-8a23-a213-09127f044892@mail.mipt.ru>
References: <1e6df075-21ad-686f-6e79-999f6b9ad495@mail.mipt.ru>
 <CAFYqXL_pyyOiB6nc0V_mk-QzwbDXeVUgCnB1FKAOFFVjSFv7wA@mail.gmail.com>
 <58b387e9-4120-8a23-a213-09127f044892@mail.mipt.ru>
Message-ID: <CAFYqXL9V5TZtXDFELVMUFSj3wU5eW0Zvqn69wu3LUN3fQMZFpQ@mail.gmail.com>

On Wed, Dec 28, 2016 at 3:57 PM, Ivan Pozdeev <vano at mail.mipt.ru> wrote:

> On 25.12.2016 17:21, Giampaolo Rodola' wrote:
>
> From what I understand the problem should be fixed in urllib so that it
> always closes the FTP connection. I understand this is what happens in
> recent 3.x versions but not on 2.7.
>
> urllib in 2.7 should indeed be fixed to close FTP connections rather than
> leave them dangling, no question about that.
>

To me it looks like this is the only issue (currently tracked in
http://bugs.python.org/issue28931).


> I tried to fix urllib so that it's guaranteed to call voidresp(), and
> failed. Too complicated, effectively reimplementing a sizable part of FTP
> client logic is required, perhaps even monkey-patching ftplib to be able to
> set flags in the right places.
>

Why did you fail? Why urllib can't close() -> voidresp() the FTP session
once it's done with it?


> With simple commands (voidcmd) and self-contained transfer commands
> (retrlines/retrbinary), ftplib does incapsulate statefulness, by handling
> them atomically. But with transfercmd(), it returns control to the user
> halfway through.
>

That's by design. ftplib's transfercmd() just works like that: it's a low
level method returning a "data" socket and it's just up to you to cleanly
close the session (close() -> voidresp()) once you're done with it. Most of
the times you don't even want to use transfercmd() in the first place, as
you just use stor* and retr* methods.


> At this point, if ftplib doesn't itself keep track that the control
> connection is currently in invalid state for the next command, the user is
> forced to do that themselves instead.
>

Hence why I suggested a docfix.


> And guess what - urllib has to use ftplib through a wrapper class that
> does exactly that. That's definitely a "stock logic part" 'cuz it's an
> integral part of FTP rather than something specific to user logic.
>

That wrapper should just cleanly close the session.


> The other "stock logic part" currently missing is error handling during
> transfer. If the error's cause is local (like a local exception that
> results in closing the data socket prematurely, or the user closing it by
> hand, or an ABOR they sent midway), the error code from the end-of-transfer
> response should be ignored, otherwise, it shouldn't.
>

Absolutely not. Base ftplib should NOT take any deliberate decision such as
ignoring an error.
I can even come up with use cases: use ftplib to test FTP servers so that
they *do* reply with an error code in certain conditions. Here's a couple
examples in pyftpdlib:

https://github.com/giampaolo/pyftpdlib/blob/17bebe3714752b01e43ab60d2771308f4594bd99/pyftpdlib/test/test_functional.py#L1354-L1369

https://github.com/giampaolo/pyftpdlib/blob/17bebe3714752b01e43ab60d2771308f4594bd99/pyftpdlib/test/test_functional.py#L1973-L1980


> Other than making ftplib keep track of the session's internal state while
> the user has control and providing the custom error handling logic to them,
> another solution is to never release control to the user midway, i.e. ban
> transfercmd() entirely and only provide self-contained
> retr*()/dir()/whatever, but let the callback signal them to abort the
> transfer. That way, the state would be kept implicitly - in the execution
> pointer.
>

Banning transfercmd() means renaming it to _transfercmd() which is a no-no
for backward compatibility. Also, as I've shown above, transfercmd() does
have a use case which relies on it behaving like that (return control
midway).


-- 
Giampaolo - http://grodola.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161228/ee564c2e/attachment.html>

From brett at python.org  Wed Dec 28 14:45:19 2016
From: brett at python.org (Brett Cannon)
Date: Wed, 28 Dec 2016 19:45:19 +0000
Subject: [Python-Dev] Document C API that is not part of the limited API
In-Reply-To: <5F9E3B2F-BAB4-49FC-ABEA-9BD52BE7C5DB@mac.com>
References: <o3udvh$cbr$1@blaine.gmane.org>
 <5F9E3B2F-BAB4-49FC-ABEA-9BD52BE7C5DB@mac.com>
Message-ID: <CAP1=2W6fS3RryZSDEb2CzDiqXn=uNQxktRpQpZ0GXuRAnL4qAQ@mail.gmail.com>

On Tue, 27 Dec 2016 at 12:15 Ronald Oussoren <ronaldoussoren at mac.com> wrote:

>
> > On 27 Dec 2016, at 20:04, Serhiy Storchaka <storchaka at gmail.com> wrote:
> >
> > From the documentation:
> >
> > https://docs.python.org/3/c-api/stable.html
> >
> >    In the C API documentation, API elements that are not part of the
> limited API are marked as "Not part of the limited API."
> >
> > But they don't.
> >
> > I prepared a sample patch that adds the notes to Unicode Objects and
> Codecs C API (http://bugs.python.org/issue29086). I'm going to add them
> to all C API.
> >
> > What are your though about formatting the note? Should it be before the
> description, after the description, but before the "deprecated" directive
> (as in the patch), or after the first paragraph of the description? Should
> it be on the separate line or be appended at the end of the previous
> paragraph, or starts the first paragraph (if before the description)? May
> be introduce a special directive for it?
>
> A directive would make it easier to ensure that the text about the stable
> API is consistent.  I?d also consider adding that directive to all API?s
> that *are* part of the stable API instead of the other way around (that
> would also require changes to ?/stable.html). That would have two
> advantages: firstly it makes it easier to document from which version an
> API is part of the stable ABI, and secondly forgetting the annotation would
> imply that an API is not part of the stable ABI instead of accidentally
> claiming to increase the stable ABI.
>

I like Ronald's suggestion of both using a directive and making it for the
stable ABI since it should be an opt-in thing for the API to be stable
instead of opt-out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161228/74957190/attachment.html>

From steve.dower at python.org  Wed Dec 28 15:41:05 2016
From: steve.dower at python.org (Steve Dower)
Date: Wed, 28 Dec 2016 12:41:05 -0800
Subject: [Python-Dev] Document C API that is not part of the limited API
In-Reply-To: <CAP1=2W6fS3RryZSDEb2CzDiqXn=uNQxktRpQpZ0GXuRAnL4qAQ@mail.gmail.com>
References: <o3udvh$cbr$1@blaine.gmane.org>
 <5F9E3B2F-BAB4-49FC-ABEA-9BD52BE7C5DB@mac.com>
 <CAP1=2W6fS3RryZSDEb2CzDiqXn=uNQxktRpQpZ0GXuRAnL4qAQ@mail.gmail.com>
Message-ID: <c3ad63a7-65dc-66d7-c759-0e6c02fd4521@python.org>

On 28Dec2016 1145, Brett Cannon wrote:
> On Tue, 27 Dec 2016 at 12:15 Ronald Oussoren <ronaldoussoren at mac.com
> <mailto:ronaldoussoren at mac.com>> wrote:
>     A directive would make it easier to ensure that the text about the
>     stable API is consistent.  I?d also consider adding that directive
>     to all API?s that *are* part of the stable API instead of the other
>     way around (that would also require changes to ?/stable.html). That
>     would have two advantages: firstly it makes it easier to document
>     from which version an API is part of the stable ABI, and secondly
>     forgetting the annotation would imply that an API is not part of the
>     stable ABI instead of accidentally claiming to increase the stable ABI.
>
>
> I like Ronald's suggestion of both using a directive and making it for
> the stable ABI since it should be an opt-in thing for the API to be
> stable instead of opt-out.

The directive is a good idea, but I'm a little concerned about the 
stable API being opt-out in the headers and opt-in in the documentation.

Perhaps we should also figure out the preprocessor gymnastics we need to 
make it opt-in in the headers too? Though once we get the build 
validation to detect when the stable API changes accidentally it'll be 
less of an issue.

Cheers,
Steve

From v+python at g.nevcal.com  Wed Dec 28 17:30:34 2016
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Wed, 28 Dec 2016 14:30:34 -0800
Subject: [Python-Dev] PEP 514 and pywin32
In-Reply-To: <E1cMHk7-0005Xf-ET@se2-syd.hostedmail.net.au>
References: <233e092a-902f-cf74-66b0-a8665fc3edc4@nevcal.com>
 <CACKxkAwi_hzzn11aTPx_=UBqsF627VwjHbz0GO4iKNvF+QnSyg@mail.gmail.com>
 <E1cMHk7-0005Xf-ET@se2-syd.hostedmail.net.au>
Message-ID: <769297e1-49e8-77aa-2f53-573e7b26c342@g.nevcal.com>

Apparently the gohlke site had done the wheel convert, as they had a wheel.
The post-install steps were needed to make things work for me, and were 
documented at the gohlke site.

Thanks to both of you for your help.

On 12/28/2016 9:09 AM, Steve Dower wrote:
> It's likely that they're using the broken version of bdist_wininst for 
> their installer (I thought Mark reported the issue and had a 
> workaround though...). It's already fixed, but hasn't been released yet.
>
> Another workaround is to use "wheel convert" on the exe and then 
> install the wheel. You miss out on their post-install steps, but most 
> people don't need those anyway.
>
> Cheers,
> Steve
>
> Top-posted from my Windows Phone
> ------------------------------------------------------------------------
> From: Burkhard Meier <mailto:burkhardameier at gmail.com>
> Sent: ?12/?28/?2016 1:43
> To: Glenn Linderman <mailto:glenn at nevcal.com>
> Cc: Python Dev <mailto:python-dev at python.org>
> Subject: Re: [Python-Dev] PEP 514 and pywin32
>
> Try the 'gohlke' download site. Whenever getting stuck in some of the 
> newest Python 3.x versions, that side usually has installers that 
> work. It did work for me just now, using Python 3.6.0 64-bit on 
> Windows 10 64-bit OS.
>
> Inline image 1
>
> Burkhard
>
> On Tue, Dec 27, 2016 at 9:17 PM, Glenn Linderman <glenn at nevcal.com 
> <mailto:glenn at nevcal.com>> wrote:
>
>     So today I tried to install pywin32 on my new Python 3.6.0 and got
>     the following error:
>
>     ---------------------------
>     Cannot install
>     ---------------------------
>     Python version 3.6-32 required, which was not found in the registry.
>     ---------------------------
>     OK
>     ---------------------------
>
>     Seems like pywin32, although built for 3.6, doesn't understand or
>     conform to the PEP 514? So the installer doesn't work? I suspect
>     maybe the code would still work, if it would install. I also noted
>     that pip cannot find a compatible pywin32, and PyPI only reports
>     compatibility through Python 3.3.
>
>     1. Where should this be reported? SourceForge?
>     2. Anyone know a workaround?
>
>     -- 
>     Glenn
>     ------------------------------------------------------------------------
>     Experience is that marvelous thing that enables you to recognize a
>     mistake when you make it again. -- Franklin Jones
>
>     _______________________________________________
>     Python-Dev mailing list
>     Python-Dev at python.org <mailto:Python-Dev at python.org>
>     https://mail.python.org/mailman/listinfo/python-dev
>     <https://mail.python.org/mailman/listinfo/python-dev>
>     Unsubscribe:
>     https://mail.python.org/mailman/options/python-dev/burkhardameier%40gmail.com
>     <https://mail.python.org/mailman/options/python-dev/burkhardameier%40gmail.com>
>
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/v%2Bpython%40g.nevcal.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161228/a9d5cb8f/attachment-0001.html>

From vano at mail.mipt.ru  Wed Dec 28 21:12:14 2016
From: vano at mail.mipt.ru (Ivan Pozdeev)
Date: Thu, 29 Dec 2016 05:12:14 +0300
Subject: [Python-Dev] Asking for feedback about fixing `ftplib'
 (issue25458)
In-Reply-To: <CAFYqXL9V5TZtXDFELVMUFSj3wU5eW0Zvqn69wu3LUN3fQMZFpQ@mail.gmail.com>
References: <1e6df075-21ad-686f-6e79-999f6b9ad495@mail.mipt.ru>
 <CAFYqXL_pyyOiB6nc0V_mk-QzwbDXeVUgCnB1FKAOFFVjSFv7wA@mail.gmail.com>
 <58b387e9-4120-8a23-a213-09127f044892@mail.mipt.ru>
 <CAFYqXL9V5TZtXDFELVMUFSj3wU5eW0Zvqn69wu3LUN3fQMZFpQ@mail.gmail.com>
Message-ID: <00c28954-e8c0-3749-303f-f00ed96e984c@mail.mipt.ru>

Re: [Python-Dev] Asking for feedback about fixing `ftplib' (issue25458) 
On 28.12.2016 21:02, Giampaolo Rodola' wrote:
>
>
> On Wed, Dec 28, 2016 at 3:57 PM, Ivan Pozdeev <vano at mail.mipt.ru 
> <mailto:vano at mail.mipt.ru>> wrote:
>
>     On 25.12.2016 17:21, Giampaolo Rodola' wrote:
>>     From what I understand the problem should be fixed in urllib so
>>     that it always closes the FTP connection. I understand this is
>>     what happens in recent 3.x versions but not on 2.7.
>     urllib in 2.7 should indeed be fixed to close FTP connections
>     rather than leave them dangling, no question about that.
>
>
> To me it looks like this is the only issue (currently tracked in 
> http://bugs.python.org/issue28931).
So, closing the control connection ungracefully and without checking the 
response is a non-issue? The right way to do it?
>
>     I tried to fix urllib so that it's guaranteed to call voidresp(),
>     and failed. Too complicated, effectively reimplementing a sizable
>     part of FTP client logic is required, perhaps even monkey-patching
>     ftplib to be able to set flags in the right places.
>
>
> Why did you fail? Why urllib can't close() -> voidresp() the FTP 
> session once it's done with it?
A simple voidresp() in a socket close handler doesn't work here. That's 
why I failed.
* Sometimes, the error needs to be ignored, and sometimes, it doesn't. 
With the current architecture, I cannot check which is the case.
* Error checking can't be done in a close handler. Close handlers 
(including this one) are called in finally blocks, raising an exception 
here would disrupt further cleanup actions, leaving objects in an 
undefined state, and mask the current exception if there's any.

What is more important, the entire urllib.ftpwrapper rubs me the wrong way.
urllib's use case is pretty standard. All it does is the basic FTP 
premise of log in, retrieve, log out. So, logically speaking, it 
shouldn't have to implement loads upon loads of custom logic on top of 
ftplib if ftplib is to be called a production-ready library. Any logic 
it has to implement shall be strictly application-specific.

Since it has to, there can only be two possible conclusions: either it 
uses it not in the way intended, or ftplib is an incomplete library and 
is missing some critical parts that are required for practical use.


I won't comment on anything further on that boils down to these two points.
As long as I fail to bring them across, any further discussion is moot.
>
>     With simple commands (|voidcmd|) and self-contained transfer
>     commands (retrlines/retrbinary), ftplib does incapsulate
>     statefulness, by handling them atomically. But with transfercmd(),
>     it returns control to the user halfway through.
>
>
> That's by design. ftplib's transfercmd() just works like that: it's a 
> low level method returning a "data" socket and it's just up to you to 
> cleanly close the session (close() -> voidresp()) once you're done 
> with it. Most of the times you don't even want to use transfercmd() in 
> the first place, as you just use stor* and retr* methods.
>
>     At this point, if ftplib doesn't itself keep track that the
>     control connection is currently in invalid state for the next
>     command, the user is forced to do that themselves instead.
>
>
> Hence why I suggested a docfix.
>
>     And guess what - urllib has to use ftplib through a wrapper class
>     that does exactly that. That's definitely a "stock logic part"
>     'cuz it's an integral part of FTP rather than something specific
>     to user logic.
>
>
> That wrapper should just cleanly close the session.
>
>     The other "stock logic part" currently missing is error handling
>     during transfer. If the error's cause is local (like a local
>     exception that results in closing the data socket prematurely, or
>     the user closing it by hand, or an ABOR they sent midway), the
>     error code from the end-of-transfer response should be ignored,
>     otherwise, it shouldn't.
>
>
> Absolutely not. Base ftplib should NOT take any deliberate decision 
> such as ignoring an error.
> I can even come up with use cases: use ftplib to test FTP servers so 
> that they *do* reply with an error code in certain conditions. Here's 
> a couple examples in pyftpdlib:
>
> https://github.com/giampaolo/pyftpdlib/blob/17bebe3714752b01e43ab60d2771308f4594bd99/pyftpdlib/test/test_functional.py#L1354-L1369
>
> https://github.com/giampaolo/pyftpdlib/blob/17bebe3714752b01e43ab60d2771308f4594bd99/pyftpdlib/test/test_functional.py#L1973-L1980
>
If you claim that testing a server is an intended use case for ftplib 
(rather than meddling in its internals at your own risk), you need to 
document all the other low-level functions that you use (like putcmd) 
for your claim to stand. The currently published interface doesn't offer 
a sufficiently fine-grained control for that use case. Its 
line-of-support is "elementary compounds", none of which leaves the 
control connection in an invalid state.
>
>     Other than making ftplib keep track of the session's internal
>     state while the user has control and providing the custom error
>     handling logic to them, another solution is to never release
>     control to the user midway, i.e. ban transfercmd() entirely and
>     only provide self-contained retr*()/dir()/whatever, but let the
>     callback signal them to abort the transfer. That way, the state
>     would be kept implicitly - in the execution pointer.
>
>
> Banning transfercmd() means renaming it to _transfercmd() which is a 
> no-no for backward compatibility. Also, as I've shown 
> above, transfercmd() does have a use case which relies on it behaving 
> like that (return control midway).
Whyever would a rename be required? More than a few ftplib.FTP's members 
are undocumented outright and they don't start with an underscore.
Anyway, I only mentioned this as one of the possible lines of action.
>
> -- 
> Giampaolo - http://grodola.blogspot.com
>

-- 
Regards,
Ivan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161229/3389551d/attachment.html>

From andrey.khachaturov at anychart.com  Thu Dec 29 05:02:46 2016
From: andrey.khachaturov at anychart.com (Andrey Khachaturov)
Date: Thu, 29 Dec 2016 15:02:46 +0500
Subject: [Python-Dev] Just added AnyChart JS Charts integration templates
 for easier dataviz with Python and MySQL
Message-ID: <CANibKOHhK2XHME1X_o9i+a5XoY6Zf8Rb+7rm-7rAdDiiFR=BDw@mail.gmail.com>

We at AnyChart JS Charts <http://www.anychart.com> have just released a
series of 20+ integration templates to help web developers add interactive
charts, maps, stock and financial graphs, Gantt charts, and dashboards to
web apps much easier, no matter what your technology stack is.

In particular, now there are two templates for Python in our Technical
Integration <http://www.anychart.com/integrations/> collection, all
distributed under the Apache 2.0 license and forkable on GitHub:

   - *Python*, *Flask* and *MySQL* (GitHub
   <https://github.com/anychart-integrations/python-flask-mysql-template>);
   - *Python*, *Django* and *MySQL* (GitHub
   <https://github.com/anychart-integrations/python-django-mysql-template>).

Check that out, and ask your questions if any. Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161229/711c6262/attachment.html>

From ncoghlan at gmail.com  Fri Dec 30 09:33:19 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 31 Dec 2016 00:33:19 +1000
Subject: [Python-Dev] Document C API that is not part of the limited API
In-Reply-To: <c3ad63a7-65dc-66d7-c759-0e6c02fd4521@python.org>
References: <o3udvh$cbr$1@blaine.gmane.org>
 <5F9E3B2F-BAB4-49FC-ABEA-9BD52BE7C5DB@mac.com>
 <CAP1=2W6fS3RryZSDEb2CzDiqXn=uNQxktRpQpZ0GXuRAnL4qAQ@mail.gmail.com>
 <c3ad63a7-65dc-66d7-c759-0e6c02fd4521@python.org>
Message-ID: <CADiSq7cSacVzYbZM+cB8zMxdaAt+dXDssmA3JiX+H=iAu6iYTQ@mail.gmail.com>

On 29 December 2016 at 06:41, Steve Dower <steve.dower at python.org> wrote:

> On 28Dec2016 1145, Brett Cannon wrote:
>
>> On Tue, 27 Dec 2016 at 12:15 Ronald Oussoren <ronaldoussoren at mac.com
>> <mailto:ronaldoussoren at mac.com>> wrote:
>>     A directive would make it easier to ensure that the text about the
>>     stable API is consistent.  I?d also consider adding that directive
>>     to all API?s that *are* part of the stable API instead of the other
>>     way around (that would also require changes to ?/stable.html). That
>>     would have two advantages: firstly it makes it easier to document
>>     from which version an API is part of the stable ABI, and secondly
>>     forgetting the annotation would imply that an API is not part of the
>>     stable ABI instead of accidentally claiming to increase the stable
>> ABI.
>>
>>
>> I like Ronald's suggestion of both using a directive and making it for
>> the stable ABI since it should be an opt-in thing for the API to be
>> stable instead of opt-out.
>>
>
> The directive is a good idea, but I'm a little concerned about the stable
> API being opt-out in the headers and opt-in in the documentation.
>
> Perhaps we should also figure out the preprocessor gymnastics we need to
> make it opt-in in the headers too? Though once we get the build validation
> to detect when the stable API changes accidentally it'll be less of an
> issue.
>

Making it opt-in in the documentation could make the build validation
easier: check the list from the *docs* against the actual symbols being
exported by the headers.

That would have a few benefits:

- if you accidentally add a new function to the stable ABI, you get a test
failure
- if you deliberately add a new function to the stable ABI, but forget to
document it as such, you get a test failure
- if the stable ABI version added directive in the docs doesn't match the
stable ABI version used in the headers, you get a test failure

(That suggests the tests would need to check the headers with all stable
ABI versions from 3.2 up to the current release and ensure they match the
current C API documentation)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161231/e59099b1/attachment.html>

From status at bugs.python.org  Fri Dec 30 12:09:08 2016
From: status at bugs.python.org (Python tracker)
Date: Fri, 30 Dec 2016 18:09:08 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20161230170908.CCFA156921@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2016-12-23 - 2016-12-30)
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    5663 (+11)
  closed 35208 (+49)
  total  40871 (+60)

Open issues with patches: 2449 


Issues opened (32)
==================

#28871: Destructor of ElementTree.Element is recursive
http://bugs.python.org/issue28871  reopened by haypo

#29057: Compiler failure on Mac OS X - sys/random.h
http://bugs.python.org/issue29057  opened by Pam.McANulty

#29058: Mark new limited C API
http://bugs.python.org/issue29058  opened by serhiy.storchaka

#29059: Windows: Python not using ANSI compatible console
http://bugs.python.org/issue29059  opened by joseph.hackman

#29062: hashlib documentation link error
http://bugs.python.org/issue29062  opened by frankmillman

#29063: Fixed timemodule compile warnings.
http://bugs.python.org/issue29063  opened by Decorater

#29067: Source archive: wrong directory attributes
http://bugs.python.org/issue29067  opened by amig

#29070: Integration tests for pty.spawn on Linux and all other platfor
http://bugs.python.org/issue29070  opened by Cornelius Diekmann

#29075: Remove Windows Vista support
http://bugs.python.org/issue29075  opened by steve.dower

#29076: Python 3.6 installer doesn't update "python3" shell command
http://bugs.python.org/issue29076  opened by elias

#29077: build failure when enabling dtrace on FreeBSD
http://bugs.python.org/issue29077  opened by swills

#29081: time.strptime() return wrong result
http://bugs.python.org/issue29081  opened by hywl51

#29082: In 2.7.13, _ctypes.LoadLibrary no longer accepts Unicode objec
http://bugs.python.org/issue29082  opened by Chi Hsuan Yen

#29083: Readd PyArg_VaParse to the stable API
http://bugs.python.org/issue29083  opened by serhiy.storchaka

#29084: C API of OrderedDict
http://bugs.python.org/issue29084  opened by serhiy.storchaka

#29086: Document C API that is not part of the limited API
http://bugs.python.org/issue29086  opened by serhiy.storchaka

#29090: python34.dll crash
http://bugs.python.org/issue29090  opened by MikeH

#29092: Sync os.stat's doc and doc string
http://bugs.python.org/issue29092  opened by xiang.zhang

#29093: Windows launcher breaks history in Git Bash
http://bugs.python.org/issue29093  opened by evan_

#29094: Regression in zipfile writing in 2.7.13
http://bugs.python.org/issue29094  opened by Peter Ebden

#29096: Signal Handlers reliably cause UnboundLocalErrors
http://bugs.python.org/issue29096  opened by Ted Meyer

#29097: datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python
http://bugs.python.org/issue29097  opened by pekka.klarck

#29098: document minimum sqlite version
http://bugs.python.org/issue29098  opened by carlwgeorge

#29099: sqlite3 timestamp converter cannot handle timezone
http://bugs.python.org/issue29099  opened by bozo.kopic

#29100: Core dump / OverflowError for datetime.fromtimestamp with over
http://bugs.python.org/issue29100  opened by Jordon Phillips

#29102: Add an id field to PyInterpreterState.
http://bugs.python.org/issue29102  opened by eric.snow

#29104: Left bracket remains in format string result when '\' preceeds
http://bugs.python.org/issue29104  opened by Jim Fasarakis-Hilliard

#29105: code or doc improvement for logging.handlers.RotatingFileHandl
http://bugs.python.org/issue29105  opened by redstone-cold

#29107: traceback module incorrectly formats args-less syntax errors
http://bugs.python.org/issue29107  opened by Naftali.Harris

#29108: Python 3.6.0 multiprocessing map_async callback
http://bugs.python.org/issue29108  opened by Jose Miguel Colella

#29110: [patch] Fix file object leak in `aifc.open` when given invalid
http://bugs.python.org/issue29110  opened by azhang

#29113: modulefinder no longer finds all required modules for Python i
http://bugs.python.org/issue29113  opened by adamwill



Most recent 15 issues with no replies (15)
==========================================

#29113: modulefinder no longer finds all required modules for Python i
http://bugs.python.org/issue29113

#29110: [patch] Fix file object leak in `aifc.open` when given invalid
http://bugs.python.org/issue29110

#29107: traceback module incorrectly formats args-less syntax errors
http://bugs.python.org/issue29107

#29105: code or doc improvement for logging.handlers.RotatingFileHandl
http://bugs.python.org/issue29105

#29100: Core dump / OverflowError for datetime.fromtimestamp with over
http://bugs.python.org/issue29100

#29098: document minimum sqlite version
http://bugs.python.org/issue29098

#29094: Regression in zipfile writing in 2.7.13
http://bugs.python.org/issue29094

#29092: Sync os.stat's doc and doc string
http://bugs.python.org/issue29092

#29086: Document C API that is not part of the limited API
http://bugs.python.org/issue29086

#29083: Readd PyArg_VaParse to the stable API
http://bugs.python.org/issue29083

#29081: time.strptime() return wrong result
http://bugs.python.org/issue29081

#29075: Remove Windows Vista support
http://bugs.python.org/issue29075

#29070: Integration tests for pty.spawn on Linux and all other platfor
http://bugs.python.org/issue29070

#29067: Source archive: wrong directory attributes
http://bugs.python.org/issue29067

#29063: Fixed timemodule compile warnings.
http://bugs.python.org/issue29063



Most recent 15 issues waiting for review (15)
=============================================

#29110: [patch] Fix file object leak in `aifc.open` when given invalid
http://bugs.python.org/issue29110

#29104: Left bracket remains in format string result when '\' preceeds
http://bugs.python.org/issue29104

#29102: Add an id field to PyInterpreterState.
http://bugs.python.org/issue29102

#29099: sqlite3 timestamp converter cannot handle timezone
http://bugs.python.org/issue29099

#29097: datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python
http://bugs.python.org/issue29097

#29092: Sync os.stat's doc and doc string
http://bugs.python.org/issue29092

#29086: Document C API that is not part of the limited API
http://bugs.python.org/issue29086

#29082: In 2.7.13, _ctypes.LoadLibrary no longer accepts Unicode objec
http://bugs.python.org/issue29082

#29070: Integration tests for pty.spawn on Linux and all other platfor
http://bugs.python.org/issue29070

#29063: Fixed timemodule compile warnings.
http://bugs.python.org/issue29063

#29062: hashlib documentation link error
http://bugs.python.org/issue29062

#29059: Windows: Python not using ANSI compatible console
http://bugs.python.org/issue29059

#29058: Mark new limited C API
http://bugs.python.org/issue29058

#29057: Compiler failure on Mac OS X - sys/random.h
http://bugs.python.org/issue29057

#29054: pty.py: pty.spawn hangs after client disconnect over nc (netca
http://bugs.python.org/issue29054



Top 10 most discussed issues (10)
=================================

#23903: Generate PC/python3.def by scraping headers
http://bugs.python.org/issue23903  15 msgs

#29048: Coverage influence tests, make some of them fail
http://bugs.python.org/issue29048  14 msgs

#29062: hashlib documentation link error
http://bugs.python.org/issue29062  13 msgs

#29102: Add an id field to PyInterpreterState.
http://bugs.python.org/issue29102  13 msgs

#29058: Mark new limited C API
http://bugs.python.org/issue29058  10 msgs

#29057: Compiler failure on Mac OS X - sys/random.h
http://bugs.python.org/issue29057   9 msgs

#29104: Left bracket remains in format string result when '\' preceeds
http://bugs.python.org/issue29104   9 msgs

#29097: datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python
http://bugs.python.org/issue29097   8 msgs

#29099: sqlite3 timestamp converter cannot handle timezone
http://bugs.python.org/issue29099   8 msgs

#26382: List object memory allocator
http://bugs.python.org/issue26382   7 msgs



Issues closed (49)
==================

#9770: curses.ascii.isblank() function is broken. It confuses backspa
http://bugs.python.org/issue9770  closed by serhiy.storchaka

#13051: Infinite recursion in curses.textpad.Textbox
http://bugs.python.org/issue13051  closed by serhiy.storchaka

#14483: inspect.getsource fails to read a file of only comments
http://bugs.python.org/issue14483  closed by r.david.murray

#25778: winreg.EnumValue does not truncate strings correctly
http://bugs.python.org/issue25778  closed by steve.dower

#26758: Unnecessary format string handling for no argument slot wrappe
http://bugs.python.org/issue26758  closed by inada.naoki

#28427: WeakValueDictionary next bug (with multithreading)
http://bugs.python.org/issue28427  closed by pitrou

#28446: pyvenv generates malformed hashbangs for scripts
http://bugs.python.org/issue28446  closed by vinay.sajip

#28675: about PEP 528 / PEP 529
http://bugs.python.org/issue28675  closed by steve.dower

#28902: 3.6.0rc1 installer fails to install / uninstall.
http://bugs.python.org/issue28902  closed by steve.dower

#28954: Incorrect EBNF rule of keywords_arguments
http://bugs.python.org/issue28954  closed by martin.panter

#28960: Small typo in Thread.join docs
http://bugs.python.org/issue28960  closed by martin.panter

#28998: Unifying Long Integers and Integers in 2.7
http://bugs.python.org/issue28998  closed by serhiy.storchaka

#29003: sqlite3: can't run VACUUM on Python 3.6
http://bugs.python.org/issue29003  closed by berker.peksag

#29004: binascii.crc_hqx() implements CRC-CCITT
http://bugs.python.org/issue29004  closed by martin.panter

#29025: random.seed() relation to hash() function and its determinism 
http://bugs.python.org/issue29025  closed by rhettinger

#29037: Python 2.7.13 prints version header and exits immediately on W
http://bugs.python.org/issue29037  closed by steve.dower

#29047: Where are the test results stored?
http://bugs.python.org/issue29047  closed by patriki

#29049: Lazy GC tracking frame
http://bugs.python.org/issue29049  closed by inada.naoki

#29055: random.choice on empty sequence should hide previous exception
http://bugs.python.org/issue29055  closed by rhettinger

#29056: logging.Formatter doesn't respect more than one formatExceptio
http://bugs.python.org/issue29056  closed by vinay.sajip

#29060: Changing the installation location still adds AppData filepath
http://bugs.python.org/issue29060  closed by steve.dower

#29061: secrets.randbelow(-1) hangs
http://bugs.python.org/issue29061  closed by rhettinger

#29064: Package numpy can't be used normally
http://bugs.python.org/issue29064  closed by xiang.zhang

#29065: SSL module problem on Python 3.6.0 and macOS Sierra
http://bugs.python.org/issue29065  closed by ned.deily

#29066: PIP doesn't honor --trusted-host or --cert options
http://bugs.python.org/issue29066  closed by ned.deily

#29068: Fix example code for PyErr_Fetch
http://bugs.python.org/issue29068  closed by serhiy.storchaka

#29069: Default PyPI URL in docs is not what is really in code
http://bugs.python.org/issue29069  closed by berker.peksag

#29071: IDLE doesn't highlight f-strings properly
http://bugs.python.org/issue29071  closed by terry.reedy

#29072: the message of help(os.environ.setdefault) have some error
http://bugs.python.org/issue29072  closed by r.david.murray

#29073: bytearray.__mod__() truncates on first \x00
http://bugs.python.org/issue29073  closed by serhiy.storchaka

#29074: repr doesn't give full result for this re math result
http://bugs.python.org/issue29074  closed by mrabarnett

#29078: Example in Section 8.1.5 time Objects is broken
http://bugs.python.org/issue29078  closed by xiang.zhang

#29079: pathlib.resolve() causes infinite loop on Windows
http://bugs.python.org/issue29079  closed by steve.dower

#29080: unnecessary hg required for build version 3.6 on Windows
http://bugs.python.org/issue29080  closed by steve.dower

#29085: Python 3.6 on Windows doesn't seed Random() well enough
http://bugs.python.org/issue29085  closed by python-dev

#29087: UCS4 support functions are not implemented
http://bugs.python.org/issue29087  closed by serhiy.storchaka

#29088: Inconsistent use of underscore in names that start with "is"
http://bugs.python.org/issue29088  closed by r.david.murray

#29089: dictionary keys described incorrectly in tutorial
http://bugs.python.org/issue29089  closed by rhettinger

#29091: Python 3.5+ socket.socketpair fallback incorrectly implemented
http://bugs.python.org/issue29091  closed by benjamin.peterson

#29095: Compiling Python 3.6 from source on MacOS X Sierra
http://bugs.python.org/issue29095  closed by ned.deily

#29101: Nested lambdas in setattr() lose context in Python 2.7
http://bugs.python.org/issue29101  closed by benjamin.peterson

#29103: Make enum.py pep8 compliant
http://bugs.python.org/issue29103  closed by rhettinger

#29106: get-pip.py fails with Python 3.6 embed Windows
http://bugs.python.org/issue29106  closed by ammar2

#29109: Small doc improvements for tracemalloc
http://bugs.python.org/issue29109  closed by haypo

#29111: Strange signature for memoryview constructor
http://bugs.python.org/issue29111  closed by skrah

#29112: questionable wording in sequences documentation
http://bugs.python.org/issue29112  closed by xiang.zhang

#29114: __class__ not exists in the method which bounded by types.Meth
http://bugs.python.org/issue29114  closed by ncoghlan

#29115: distutils.core.setup does not let people set 'bugtrack_url'.
http://bugs.python.org/issue29115  closed by berker.peksag

#1446619: extended slice behavior inconsistent with docs
http://bugs.python.org/issue1446619  closed by martin.panter

From ronaldoussoren at mac.com  Sat Dec 31 05:35:56 2016
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sat, 31 Dec 2016 11:35:56 +0100
Subject: [Python-Dev] Document C API that is not part of the limited API
In-Reply-To: <CADiSq7cSacVzYbZM+cB8zMxdaAt+dXDssmA3JiX+H=iAu6iYTQ@mail.gmail.com>
References: <o3udvh$cbr$1@blaine.gmane.org>
 <5F9E3B2F-BAB4-49FC-ABEA-9BD52BE7C5DB@mac.com>
 <CAP1=2W6fS3RryZSDEb2CzDiqXn=uNQxktRpQpZ0GXuRAnL4qAQ@mail.gmail.com>
 <c3ad63a7-65dc-66d7-c759-0e6c02fd4521@python.org>
 <CADiSq7cSacVzYbZM+cB8zMxdaAt+dXDssmA3JiX+H=iAu6iYTQ@mail.gmail.com>
Message-ID: <E2AF6268-E3DC-41BF-97AA-5C4CCC5788AF@mac.com>


> On 30 Dec 2016, at 15:33, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 29 December 2016 at 06:41, Steve Dower <steve.dower at python.org <mailto:steve.dower at python.org>> wrote:
> On 28Dec2016 1145, Brett Cannon wrote:
> On Tue, 27 Dec 2016 at 12:15 Ronald Oussoren <ronaldoussoren at mac.com <mailto:ronaldoussoren at mac.com>
> <mailto:ronaldoussoren at mac.com <mailto:ronaldoussoren at mac.com>>> wrote:
>     A directive would make it easier to ensure that the text about the
>     stable API is consistent.  I?d also consider adding that directive
>     to all API?s that *are* part of the stable API instead of the other
>     way around (that would also require changes to ?/stable.html). That
>     would have two advantages: firstly it makes it easier to document
>     from which version an API is part of the stable ABI, and secondly
>     forgetting the annotation would imply that an API is not part of the
>     stable ABI instead of accidentally claiming to increase the stable ABI.
> 
> 
> I like Ronald's suggestion of both using a directive and making it for
> the stable ABI since it should be an opt-in thing for the API to be
> stable instead of opt-out.
> 
> The directive is a good idea, but I'm a little concerned about the stable API being opt-out in the headers and opt-in in the documentation.
> 
> Perhaps we should also figure out the preprocessor gymnastics we need to make it opt-in in the headers too? Though once we get the build validation to detect when the stable API changes accidentally it'll be less of an issue.
> 
> Making it opt-in in the documentation could make the build validation easier: check the list from the *docs* against the actual symbols being exported by the headers.
> 
> That would have a few benefits:
> 
> - if you accidentally add a new function to the stable ABI, you get a test failure
> - if you deliberately add a new function to the stable ABI, but forget to document it as such, you get a test failure
> - if the stable ABI version added directive in the docs doesn't match the stable ABI version used in the headers, you get a test failure
> 
> (That suggests the tests would need to check the headers with all stable ABI versions from 3.2 up to the current release and ensure they match the current C API documentation)

This is probably a lot easier than trying to coax the headers into defining symbols as not part of the stable API by default (?opt-in?), especially when trying to do so in a portable way.  With GCC and clang it seems to be possible to use function attributes to force compile time errors when using functions not in the limited API, but that wouldn?t work for other declarations (struct definitions, ?) and still is error prone.

Ronald


> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org <mailto:Python-Dev at python.org>
> https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com <https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161231/9c1201c5/attachment.html>

From larry at hastings.org  Sat Dec 31 11:09:48 2016
From: larry at hastings.org (Larry Hastings)
Date: Sat, 31 Dec 2016 08:09:48 -0800
Subject: [Python-Dev] Reminder: 3.5.3 rc1 and 3.4.6 rc1 tagged tomorrow
Message-ID: <36c3119f-74d4-85f1-d8b2-71207488cea6@hastings.org>



Just a reminder: I'll be tagging 3.5.3 rc1 and 3.4.6 rc1 tomorrow, Jan 1 
2017, sometime between 24 and 36 hours from now.  Please work quickly if 
there's anything you need to get in to either of those releases.  I'm 
hoping that, for once, there are literally no code changes between rc1 
and final.


Best wishes for a happy new year,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20161231/54f643a6/attachment.html>