Mailman 3 February 2016 - python-committers

Idea: listing commercial prioritisation options as a new section in the developer guide?
by Nick Coghlan 03 May '16

03 May '16

Hi folks, A question I occasionally get asked by organisations that use Python commercially but don't currently employ any core developers themselves is "How can we prioritise getting particular issues fixed/reviewed/merged?". A related problem we have in the PSF is knowing which core developers are available for freelance & consulting work when organisations approach us regarding larger projects. At the moment, those kinds of referrals are reliant on Board members' personal knowledge of who amongst the core development team is open to that style of employment and making direct introductions, which is neither transparent nor fair. As such, what do folks think of the idea of a new, *opt-in* section in the developer guide, similar to the current experts index, but allowing core developers to indicate the ways in which we're willing to provide paid support. I'd see four likely sections in such a document: * Freelance consultants: folks that are available for contract opportunities at the individual level * Consulting companies: folks that are available for contract opportunities, but work for larger consulting organisations rather than contracting directly * Commercial redistributors: folks that work for commercial Python redistributors and are willing and able to both help in getting customer issues resolved and in acting as a point of escalation for their colleagues * Direct employment: folks that work directly for organisations that use Python extensively, and hence are able to act as a point of escalation for their colleagues The latter three categories would be further broken out by employer, while the first would just be a list of names and professional contact details. Regards, Nick. P.S. Disclosure: I do have my own interests in mind here, both personally and professionally. At a personal level, I'm a strong believer in "If you want me to care about your opinion on how I spend my time, pay me", so it makes sense to me to make it easy for more commercially-minded core developers to say "Pay me or my employer if you'd like to influence my time allocation". Professionally, it's definitely in my interests for both Python core developers and commercial Python redistributors to be recognised as a group for their expertise and overall influence on the technology sector. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

5 8

Making the PSF CoC apply to core developers
by Brett Cannon 06 Mar '16

06 Mar '16

I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC ( https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented. Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.

22 63

This mailing list is now under the PSF CoC
by Brett Cannon 26 Feb '16

26 Feb '16

I have updated the list's info page as well as the footer for this mailing list to denote this fact.

1 0

New Authenticode certificate
by Steve Dower 22 Feb '16

22 Feb '16

(I forget exactly who to contact about the certificate, so I'm going slightly more broad.) The PSF's certificate we use to sign binaries and the installer for Windows is a SHA-1 certificate, which has been deprecated as of the start of the year: http://aka.ms/sha1 Already Windows may warn about the certificate on our current and past releases, but because the signature is timestamped prior to 01Jan2016 it will not be blocked. However, our next releases will be blocked (with a bypass available) unless we update the certificate to SHA-2. Some sources have suggested that CAs will provide a SHA-2 certificate for free on request. Supporting Windows Vista and Windows Server 2008 appears to be complicated, according to the link I gave above. I want to test the effect of only signing with SHA-2 on those platforms and make a recommendation based on that, rather than trying to guess what will happen (those OSs did not block downloaded files as aggressively as Windows 7+). Happy to take this off list once I know who handles this certificate. Cheers, Steve

4 12

Anyone up for a core dev panel discussion at EuroPython 2016 ?
by M.-A. Lemburg 21 Feb '16

21 Feb '16

Hello all, at this year's EuroPython we'll have a new officially supported feature, the panel discussion, and we (I'm one of the organizers) thought it would be big fun to have a panel of core developers talk about the merits of computed gotos, micro benchmarks, adding fast-paths for integer, free lists, and all those nifty things that core devs do in their spare time ;-) No, seriously, this is great stuff normal Python users never get to see and that's really a shame. So my question to you: will some of you attend EuroPython this year and would you be willing to talk on a panel ? Quick details: * EuroPython 2016 * Location: Bilbao, Basque Country, Spain * Dates: July 17-24 * CFP just opened: https://ep2016.europython.eu/en/call-for-proposals/ (and will close again in just two weeks) * Everything else, just a click away: https://ep2016.europython.eu/ * For reference, last year: https://ep2015.europython.eu/ Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 19 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/ ________________________________________________________________________ 2016-02-19: Released eGenix PyRun 2.1.2 ... http://egenix.com/go88 ::: 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/

5 7

Deprecation Policy PEP
by Ezio Melotti 06 Feb '16

06 Feb '16

Hi, in the past I suggested to document our deprecation policy on a PEP. Since the issue came up again on a few issues on the tracker and on #python-dev, I adapted the content of my previous email and wrote a PEP. Attached you can find the full text, including references to the previous discussions on python-dev and related issues. Best Regards, Ezio Melotti --------- PEP: XXX Title: Deprecation Policy Version: $Revision$ Last-Modified: $Date$ Author: Ezio Melotti <ezio.melotti(a)gmail.com> Status: Draft Type: Process Content-Type: text/x-rst Created: 29-Jan-2016 Post-History: Abstract ======== The goal of this PEP is to document when and how to deprecate APIs in the Python language and in the standard library. Rationale ========= Python doesn't currently have a documented policy regarding deprecations. This leads to repeated discussions and inconsistencies in how we handle and document deprecations [#]_ [#]_ [#]_ [#]_ [#]_ [#]_ [#]_. What and when to deprecate ========================== * An API can be deprecated if a better alternative exists, if the implementation is incorrect or obsolete, or if the name or module has been changed. If possible, an alternative should be provided. * If the API is public, it must go through the deprecation process. If the API is private or provisional, it might. * The number of releases before an API is removed is decided on a case-by-case basis depending on widely used the API is, in which Python versions the alternative is available, which Python versions are currently supported by different operating systems, distros, and projects, and how easy it is to replace the API. * In general it's better to be conservative, and if the API is deprecated in ``3.X``, it shouldn't be removed before ``3.X+2``. This should also take into account which Python versions are currently . Porting from 2.x to 3.x ----------------------- Some APIs that are available in Python 2.7 might get deprecated in Python 3, and people that upgrade directly from 2.7 to 3.X might not see any warnings. In order to make porting code to 3.X easier: * nothing that is available and not deprecated in 2.7 should be removed from Python 3 as long as 2.7 is officially supported; * deprecation warnings can be backported to 2.7 and enabled using the ``-3`` flag; Deprecation Warnings ==================== Python offers two kinds of deprecation warnings: * ``PendingDeprecationWarning`` * ``DeprecationWarning`` Initially, only ``PendingDeprecationWarning``\ s were silenced by default. Starting from Python 2.7, ``DeprecationWarning``\ s are also silenced by default [#]_ [#]_. Since this distinction is no longer true: * ``PendingDeprecationWarning`` should not be used * ``DeprecationWarning`` will be used for all deprecations ``PendingDeprecationWarning`` won't be removed, and 3rd-party projects are allowed to use it as they see fit. Deprecation Progression ======================= In the past, the following deprecation progression has been used: 1. in release ``3.X`` a ``PendingDeprecationWarning`` is added 2. in release ``3.X+1`` it becomes a ``DeprecationWarning`` 3. in release ``3.X+2`` the API is removed The warning were occasionally left for more than one release, either intentionally or because no one remembered to update them. Since ``PendingDeprecationWarning`` should no longer be used, this can be simplified to: 1. in release ``3.X`` a ``DeprecationWarning`` is added 2. in release ``3.X+N`` the API is removed ``N`` can be ``>=1``, should be decided beforehand, and should be documented explicitly. Deprecation Process =================== These are the steps required to deprecate and remove an API: 1. propose to deprecate an API on a tracker issue or on python-dev and decide in which version it will be removed. 2. attach to the issue a patch to deprecate the API that: * adds a ``DeprecationWarning`` to the code * adds the deprecation to the documentation * adds a test to verify that the warning is raised * possibly updates code/examples that uses the deprecated API 3. after review, apply the patch to the current in-development branch and close the issue. 4. attach to a separate issue a patch to remove the API that: * removes the API and the warning * removes the tests for the API and for the deprecation * removes the API documentation 5. once the designated branch is available, apply the patch and close the issue. Deprecation Messages ==================== When a deprecated API is used, a ``DeprecationWarning`` should be raised. The message should mention that the API is deprecated, and if possible it should indicate when it will be removed and what should be used instead. These messages are intended for developers, and are therefore hidden by default to prevent end-users to see them. These messages should be enabled by default in places where only developers will see them, such as tests [#]_ and in the interactive interpreter [#]_. Documenting the deprecations ============================ * All deprecations should be documented in the docs, using the ``deprecated-removed`` directive. * If an alternative is available, it should be mentioned, possibly including examples. * Each "what's new" document should include either a section or a link to a separate document [#]_ listing all the new deprecations, the APIs that have been removed and possibly the planned removals for the upcoming releases. This could be generated automatically with Sphinx. * Simply removing the documentation for deprecated APIs is not acceptable, since people that see the API used in the code won't know if they can still use the API or not. Deprecation warnings rendering ------------------------------ On one hand deprecation warnings should be clearly visible, on the other hand we want to avoid riddling the docs with red boxes [#]_. In order to find a balance between the two: * Individual functions/methods/attributes should have a label next to the name to indicate the deprecation, and a more verbose description underneath. The label will be red, the description doesn't have to [#]_. * Modules and classes can use a red warning box. If the documentation spans more than a single screen of text, additional warning labels can be added to the individual functions/methods. * Links to deprecated objects should be marked differently. This will require some tweak to the ``deprecated-removed`` directive, in order to produce different CSS classes for modules/classes, functions/methods/attributes, and links. Updating deprecated code ======================== As mentioned above, the error messages and documentation should provide an alternative whenever possible. When the alternative is not straightforward, more complex examples or a new section can added to the documentation to explain how to convert the code. Another option is to write scripts that can automatically update Python code to use the new alternative. This requires: 1. writing a 3to3 tool similar to (and possibly based on) 2to3; 2. documenting clearly its API and providing several examples; 3. providing fixers for deprecated APIs that can be used to automatically update deprecated code; This can be done as a GSoC project, and if done correctly, it will provide an easy way for people to upgrade their codebases. See also ======== * :pep:`387` -- Backwards Compatibility Policy * :pep:`4` -- Deprecation of Standard Modules References ========== .. [#] Deprecation Policy (https://mail.python.org/pipermail/python-dev/2011-October/114199.html) .. [#] Deprecation Policy (https://mail.python.org/pipermail/python-dev/2014-January/132069.html) .. [#] deprecated in 3.2/3.3, should be removed in 3.5 or ??? (https://bugs.python.org/issue13248) .. [#] DeprecationWarning for PEP 479 (generator_stop) (http://bugs.python.org/issue26136) .. [#] Deprecate threading.Thread.isDaemon etc (http://bugs.python.org/issue24203) .. [#] Remove the Deprecated API in trace module (http://bugs.python.org/issue26069) .. [#] Resurrect inspect.getargspec() in 3.6 (http://bugs.python.org/issue25486) .. [#] What's New in Python 2.7 -- Changes to the Handling of Deprecation Warnings (https://docs.python.org/3/whatsnew/2.7.html) .. [#] Silence DeprecationWarning by default (https://bugs.python.org/issue7319) .. [#] Enable warnings by default in unittest (https://bugs.python.org/issue10535) .. [#] DeprecationWarnings should be visible by default in the interactive REPL (https://bugs.python.org/issue24294) .. [#] Django has a "Django Deprecation Timeline" page (https://docs.djangoproject.com/en/dev/internals/deprecation/) .. [#] Consistent documentation practices for security concerns and considerations (https://bugs.python.org/issue13515) .. [#] Put "deprecated" warnings first (http://bugs.python.org/issue25467) Copyright ========= This document has been placed in the public domain.

11 26

python-committers February 2016