Re: [Python-Dev] [RELEASE] Python 2.7.16

[Miro Hrončok]

On 04. 03. 19 4:30, Benjamin Peterson wrote:

Hello all,
I'm pleased to announce the immediate availability of Python 2.7.16 for 
download at https://www.python.org/downloads/release/python-2716/.

The only change since the release candidate was a fix for the IDLE icon on 
macOS. See https://bugs.python.org/issue32129. Refer to the changelog for a 
full list of changes: 
https://raw.githubusercontent.com/python/cpython/v2.7.16/Misc/NEWS.d/2.7.16rc1.rst



https://www.python.org/downloads/release/python-2716/ links changelog to 
https://raw.githubusercontent.com/python/cpython/v2.7.16/Misc/NEWS.d/2.7.16.rst 
but that only has 1 change (I suppose against rc1).


Is there a better link, or should I read those two combined?

https://raw.githubusercontent.com/python/cpython/v2.7.16/Misc/NEWS.d/2.7.16rc1.rst
https://raw.githubusercontent.com/python/cpython/v2.7.16/Misc/NEWS.d/2.7.16.rst

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[Victor Stinner]

Hi,

Le mar. 5 mars 2019 à 02:53, Brett Cannon  a écrit :
> The steering council has implemented a new idea called sponsors to the PEP 
> process (...). The thinking is that to help make sure PEPs from non-core 
> developers receive appropriate guidance through the PEP process (...)

Hum, this isn't fully new, some PEPs already got a "PEP champion" (old
name), no?

A recent example is PEP 572 who has been "championed" by Guido van
Rossum, then by Tim Peters. In this specific case, they became
co-authors :-)

> ... eventually becoming a co-author or BDFL-delegate later

Nitpick: since Python has no more BDFL, maybe the expression should
becocme "PEP-delegate"? ;-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[Calvin Spealman]

> because if a single core dev won't sign on to help then what chance does
the PEP have of being accepted?

If this is the justification, then I feel like it is a barrier that could
be disassembled, rather than one people need to be granted permission to
climb over.

I am named on one PEP with two others (PEP 3135) and none of us were core
developers, I think? I don't want that barrier added to newcomers, and I
don't disagree there is a pre-existing barrier, but I can't help but feel
this is not the best solution to it.

I'm worried this creates a gatekeeping perception that will scare away
contributors.

On Mon, Mar 4, 2019 at 8:53 PM Brett Cannon  wrote:

> The steering council has implemented a new idea called sponsors to the PEP
> process (added in
> https://github.com/python/peps/commit/c58d32c33bd06eb386d3f33963a1434510528f68).
> The thinking is that to help make sure PEPs from non-core developers
> receive appropriate guidance through the PEP process, a core developer
> needs to sign on to be a sponsor of the PEP. Being a sponsor does *not*
> preclude the core dev from eventually becoming a co-author or BDFL-delegate
> later on (but obviously not both), but the expectation is the sponsor is
> supportive of the idea (because if a single core dev won't sign on to help
> then what chance does the PEP have of being accepted?).
>
> If this doesn't turn out well we can obviously revert this, but hopefully
> this will make things smoother for those who are new to the PEP process.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/cspealma%40redhat.com
>


-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

cspea...@redhat.com  M: +1.336.210.5107

TRIED. TESTED. TRUSTED. 
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[Jeroen Demeyer]

On 2019-03-05 14:05, Calvin Spealman wrote:

I'm worried this creates a gatekeeping perception that will scare away
contributors.


+1

I also expressed this worry at https://github.com/python/peps/pull/903

You could keep the positive part of the sponsoring idea (somebody acting 
as mentor) but drop the negative part (make it a hard requirement to 
find a sponsor supporting the proposal before the proposal can even 
become a draft PEP).

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[James Edwards]

I have to say, this is sort of surprising for what seems like the first
official action of the steering committee.  Are there really *that many *PEPs
that a team that is now, what, 5x the size of the BFDL model is worried
that they'll be able to keep up?  As a long-time lurker, this hardly seems
to be the case.  Despite the seemingly-well-intentioned rationale, this
seems like an ominous sign.

On Tue, Mar 5, 2019 at 8:33 AM Jeroen Demeyer  wrote:

> On 2019-03-05 14:05, Calvin Spealman wrote:
> > I'm worried this creates a gatekeeping perception that will scare away
> > contributors.
>
> +1
>
> I also expressed this worry at https://github.com/python/peps/pull/903
>
> You could keep the positive part of the sponsoring idea (somebody acting
> as mentor) but drop the negative part (make it a hard requirement to
> find a sponsor supporting the proposal before the proposal can even
> become a draft PEP).
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/jheiv%40jheiv.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2019-02-08 - 2019-02-15)
Python tracker at https://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:
  open7009 (+11)
  closed 40747 (+51)
  total  47756 (+62)

Open issues with patches: 2814 


Issues opened (42)
==

#25737: array is not a Sequence
https://bugs.python.org/issue25737  reopened by josh.r

#35944: Python 3.7 install error
https://bugs.python.org/issue35944  opened by lasonjack

#35945: Cannot distinguish between subtask cancellation and running ta
https://bugs.python.org/issue35945  opened by jnwatson

#35946: Ambiguous documentation for assert_called_with()
https://bugs.python.org/issue35946  opened by chimaerase

#35947: Update libffi_msvc to current version of libffi
https://bugs.python.org/issue35947  opened by Paul Monson

#35949: Move PyThreadState into Include/internal/pycore_pystate.h
https://bugs.python.org/issue35949  opened by eric.snow

#35950: io.BufferedReader.writabe is False, but io.BufferedReader.trun
https://bugs.python.org/issue35950  opened by steverpalmer

#35951: os.renames() creates directories if original name doesn't exis
https://bugs.python.org/issue35951  opened by chris.jerdonek

#35952: test.pythoninfo prints a stack trace and exits with 1 when the
https://bugs.python.org/issue35952  opened by xdegaye

#35953: crosscompilation fails with clang on android
https://bugs.python.org/issue35953  opened by muhzi

#35954: Incoherent type conversion in configparser
https://bugs.python.org/issue35954  opened by Adeokkuw

#35955: difflib reports incorrect location of mismatch
https://bugs.python.org/issue35955  opened by jaraco

#35956: Sort documentation could be improved for complex sorting
https://bugs.python.org/issue35956  opened by FabriceSalvaire

#35957: Indentation explanation is unclear
https://bugs.python.org/issue35957  opened by Jérôme LAURENS

#35959: math.prod(range(10)) caues segfault
https://bugs.python.org/issue35959  opened by xtreak

#35962: Slight error in words in [ 2.4.1. String and Bytes literals ]
https://bugs.python.org/issue35962  opened by Magnien Sebastien

#35964: shutil.make_archive (xxx, tar, root_dir) is adding './' entry 
https://bugs.python.org/issue35964  opened by HFM

#35967: Better platform.processor support
https://bugs.python.org/issue35967  opened by jaraco

#35969: Interpreter crashes with "can't initialize init_sys_streams" w
https://bugs.python.org/issue35969  opened by p-ganssle

#35970: no help flag in base64 util
https://bugs.python.org/issue35970  opened by rkuska

#35971: Documentation should warn about code injection from current wo
https://bugs.python.org/issue35971  opened by Gabriel Corona

#35974: os.DirEntry.inode() returns invalid value within Docker contai
https://bugs.python.org/issue35974  opened by decaz

#35975: Put back the ability to parse files where async/await aren't k
https://bugs.python.org/issue35975  opened by gvanrossum

#35978: test_venv fails in Travis with GCC
https://bugs.python.org/issue35978  opened by xtreak

#35981: shutil make_archive create wrong file when base name contains 
https://bugs.python.org/issue35981  opened by highwind

#35982: Create unit-tests for os.renames()
https://bugs.python.org/issue35982  opened by nanjekyejoannah

#35983: tp_dealloc trashcan shouldn't be called for subclasses
https://bugs.python.org/issue35983  opened by jdemeyer

#35984: test__xxsubinterpreters leaked [3, 4, 3] memory blocks, sum=1
https://bugs.python.org/issue35984  opened by pablogsal

#35989: ipaddress.IPv4Network allows prefix > 32
https://bugs.python.org/issue35989  opened by John Florian

#35990: ipaddress.IPv4Interface won't accept 2-tuple (address, mask)
https://bugs.python.org/issue35990  opened by John Florian

#35992: Metaclasses interfere with __class_getitem__
https://bugs.python.org/issue35992  opened by donovick

#35993: incorrect use of released memory in Python/pystate.c line 284
https://bugs.python.org/issue35993  opened by wjq-security

#35995: logging.handlers.SMTPHandler
https://bugs.python.org/issue35995  opened by lidayan

#35996: Optional modulus argument for new math.prod() function
https://bugs.python.org/issue35996  opened by lschoe

#35997: ImportError: dlopen failed: cannot locate symbol "PyBool_Type"
https://bugs.python.org/issue35997  opened by muhzi

#35998: test_asyncio: test_start_tls_server_1() TimeoutError on Fedora
https://bugs.python.org/issue35998  opened by matrixise

#35999: multpirocessing.Process alive after SIGTERM on parent
https://bugs.python.org/issue35999  opened by lids

#36000: __debug__ is a keyword but not a keyword
https://bugs.python.org/issue36000  opened by bup

#36001: LIBFFI_INCLUDEDIR is not detected when set into a profile nor 
https://bugs.python.org/issue36001  opened by neil pop

#36002: configure --enable-optimizations with clang fails to detect ll
https://bugs.python.org/issue36002  opened by mjpieters

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2019-02-15 - 2019-02-22)
Python tracker at https://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:
  open6999 (-10)
  closed 40834 (+87)
  total  47833 (+77)

Open issues with patches: 2795 


Issues opened (45)
==

#36008: [good first issue] Update documentation for 3.8
https://bugs.python.org/issue36008  opened by cheryl.sabella

#36010: Please provide a .zip Windows release of Python that is not cr
https://bugs.python.org/issue36010  opened by jt

#36011: ssl - tls verify on Windows fails
https://bugs.python.org/issue36011  opened by chris-k

#36015: streamhandler cannot represent streams with an integer as name
https://bugs.python.org/issue36015  opened by Riccardo Magliocchetti

#36016: Allow gc.getobjects to return the objects tracked by a specifi
https://bugs.python.org/issue36016  opened by pablogsal

#36017: test_grp
https://bugs.python.org/issue36017  opened by mjbrands

#36018: Add a Normal Distribution class to the statistics module
https://bugs.python.org/issue36018  opened by rhettinger

#36019: test_urllib fail in s390x buildbots: http://www.example.com/
https://bugs.python.org/issue36019  opened by pablogsal

#36020: HAVE_SNPRINTF and MSVC std::snprintf support
https://bugs.python.org/issue36020  opened by palotasb-conti

#36021: [Security][Windows] webbrowser: WindowsDefault uses os.startfi
https://bugs.python.org/issue36021  opened by vstinner

#36022: [Security] logging.config should not use eval()
https://bugs.python.org/issue36022  opened by vstinner

#36023: Improve configparser.ConfigParser repr
https://bugs.python.org/issue36023  opened by remi.lapeyre

#36025: Breaking change in PyDate_FromTimeStamp API
https://bugs.python.org/issue36025  opened by p-ganssle

#36026: Different error message when sys.settrace is used
https://bugs.python.org/issue36026  opened by SylvainDe

#36027: Support negative exponents in pow() where a modulus is specifi
https://bugs.python.org/issue36027  opened by rhettinger

#36029: Use title-case HTTP header fields
https://bugs.python.org/issue36029  opened by maggyero

#36030: add internal API function to create tuple without items array 
https://bugs.python.org/issue36030  opened by sir-sigurd

#36033: logging.makeLogRecord should update "rv" using a dict defined 
https://bugs.python.org/issue36033  opened by ralonsoh

#36034: Suprise halt caused by -Werror=implicit-function-declaration i
https://bugs.python.org/issue36034  opened by Michael.Felt

#36035: pathlib.Path().rglob() breaks with broken symlinks
https://bugs.python.org/issue36035  opened by Jörg Stucke

#36036: Add method to get user defined command line arguments in unitt
https://bugs.python.org/issue36036  opened by remi.lapeyre

#36041: email: folding of quoted string in display_name violates RFC
https://bugs.python.org/issue36041  opened by aaryn.startmail

#36042: Setting __init_subclass__ and __class_getitem__ methods are in
https://bugs.python.org/issue36042  opened by BTaskaya

#36043: FileCookieJar constructor don't accept PathLike
https://bugs.python.org/issue36043  opened by kapsh

#36044: PROFILE_TASK for PGO build is not a good workload
https://bugs.python.org/issue36044  opened by nascheme

#36045: builtins.help function is not much help with async functions
https://bugs.python.org/issue36045  opened by Dan Rose

#36046: support dropping privileges when running subprocesses
https://bugs.python.org/issue36046  opened by patrick.mclean

#36048: Deprecate implicit truncating when convert Python numbers to C
https://bugs.python.org/issue36048  opened by serhiy.storchaka

#36050: Why does http.client.HTTPResponse._safe_read use MAXAMOUNT
https://bugs.python.org/issue36050  opened by bmerry

#36051: Drop the GIL during large bytes.join operations?
https://bugs.python.org/issue36051  opened by bmerry

#36053: pkgutil.walk_packages jumps out from given path if there is pa
https://bugs.python.org/issue36053  opened by karkucik

#36054: Way to detect CPU count inside docker container
https://bugs.python.org/issue36054  opened by keirlawson

#36058: Improve file decoding before re.search
https://bugs.python.org/issue36058  opened by terry.reedy

#36064: docs: urllib.request.Request not accepting iterables data type
https://bugs.python.org/issue36064  opened by sylye

#36066: Add `empty` block to `for` and `while` loops.
https://bugs.python.org/issue36066  opened by wlohu

#36067: subprocess terminate() "invalid handle" error when process is 
https://bugs.python.org/issue36067  opened by giampaolo.rodola

#36071: Add support for Windows ARM32 in ctypes/libffi
https://bugs.python.org/issue36071  opened by Paul Monson

#36072: str.translate() behaves differently for ASCII-only and other s
https://bugs.python.org/issue36072  opened by sir-sigurd

#36073: sqlite crashes with converters mutating cursor
https://bugs.python.org/issue36073  opened by sir-sigurd

Re: [Python-Dev] [RELEASE] Python 2.7.16

[Steve Dower]

On 04Mar2019 1631, Terry Reedy wrote:

On 3/3/2019 10:30 PM, Benjamin Peterson wrote:

I'm pleased to announce the immediate availability of Python 2.7.16 
for download at https://www.python.org/downloads/release/python-2716/.


On Windows 10, this is an 'unrecognized app' and Windows Defender 
SmartScreen, now default, refuses to run it. "Windows protected your PC" 
until one clicks 'more info' to get 'Run anyway'.  This is new since the 
.rc1 release.  We should either make 2.7 a 'known' app* or say something 
on the download page about clicking 'more info'.  I don't know the 
status of python.org 3.x downloads.


Since Steve Dower put 3.7 on the Windows store, PSF must now be a known 
publisher.  Perhaps he can help make 2.7 'known'.


SmartScreen should recognize it now that it's been downloaded a few 
times without reporting, but the real problem is that it hasn't been 
signed properly. (I don't have any validation set up for Python 2 on this.)


I'll try and sign the version on my build machine by hand and upload it 
again this week, and maybe add a validation step to interrupt the upload 
if it's not signed, but anything Python 2 is a very low priority for me 
(sorry Benjamin :) ).


Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Summary of Python tracker Issues

[Ezio Melotti]

On Fri, Mar 1, 2019 at 8:05 AM Ezio Melotti  wrote:
>
> On Fri, Mar 1, 2019 at 5:59 AM Terry Reedy  wrote:
> >
> > On 2/28/2019 6:54 PM, Glenn Linderman wrote:
> >
> > > There seems to be enough evidence that something went wrong somewhere,
> > > though, and whoever maintains that process should start investigating,
> > > but it would still be nice to get confirmation from a non-Google email
> > > recipient whether they did or did not get the Summary messages.
> > >
> > > I wonder if there is a way to manually send them, and if the missing two
> > > weeks of activity can be reported... once the sending problem is
> > > understood and resolved.
> >
> > I posted a note to the core-workflow list, but I don't know if anyone
> > with power or knowledge still reads it.
> >
>
> The tracker got migrated recently, and that's the most likely cause of
> the missing reports.
> We'll look into it and get them back :)
>

Ernest promptly fixed the issue so last week report was sent out correctly.
I just generated and sent out the two reports that were missing and
updated the tracker stats at
https://bugs.python.org/issue?@template=stats
Note that some values in the report might be a bit off (for example,
the list of issues waiting for review doesn't include issues that were
closed after the selected period, and the patch count includes issues
created before or during the selected period even if a patch was
uploaded after the selected period).
The issues counts and deltas at the top of the summary should be correct.
Let me know if you notice any other problem (and thanks Ned for
bringing this to my attention!).

Best Regards,
Ezio Melotti

> > To get a listing, go to the tracker search page, put
> > 2019-02-09 to 2019-03-01
> > in the date box, and change status to don't care.  At the moment, this
> > returns 204 issues.
> >
> > --
> > Terry Jan Reedy
> >
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[Steve Dower]

On 05Mar2019 0620, James Edwards wrote:
I have to say, this is sort of surprising for what seems like the first 
official action of the steering committee.  Are there really /that many 
/PEPs that a team that is now, what, 5x the size of the BFDL model is 
worried that they'll be able to keep up?  As a long-time lurker, this 
hardly seems to be the case.  Despite the seemingly-well-intentioned 
rationale, this seems like an ominous sign.


FWIW, I'm 100% on board with this idea (and feel free to continue 
stealing ideas from PEP 8013 ;) ). However, the presentation of it 
certainly didn't emphasize the good rationale for the decision.


In short, the five person steering council is not the equivalent of 5x 
BDFL. If they want to delegate early decision making to the core team as 
a whole, they can, and that's what they've done here.


For non-core developers, and particularly first-time contributors, the 
PEP process typically starts at python-ideas. (Even core devs probably 
ought to start there, though part of being accepted as a core developer 
means we trust your judgement in selecting the correct venue for 
discussion, so if security-sig, datetime-sig, capi-sig, core-workflow, 
or just python-dev is more appropriate, feel free to start there.)


To "get out" of python-ideas, someone needs to suggest where it goes 
next. Most of the time, this is python-dev. However, if you don't have 
*a single* core developer on board from python-ideas, chances are the 
whole team is going to reject the proposal.


In the past, an idea would be shut down by just one negative vote 
(Guido's). In this future, an idea is promoted by just one positive vote 
(any core developer's). It's actually much easier for an "outsider" to 
get their idea in front of the whole core team than before. And 
python-ideas has core developers and regular contributors who have 
self-selected to "triage" ideas and help move them along. If the 
triagers don't like your idea, it's probably not a good idea :)


Asking for proclamation from the council/delegate is literally saying 
"this proposal is ready". As a contributor (first time or 100th time), 
if you think your proposal is ready without *anyone else* agreeing with 
you, then *we* think you have a humility problem and we'd like you to go 
work on that.


It's not a big ask to have one of the lower level mailing lists look at 
your proposal before the council has to make an official decision. You 
should *want* the mailing lists to look at your proposal. I certainly 
do, because every time they do my proposals get better, and I get better 
at writing proposals. This is a situation where everyone wins.


Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[Brett Cannon]

On Mon, Mar 4, 2019 at 10:13 PM Jeroen Demeyer  wrote:

> Does this apply to existing draft PEPs or only new ones?
>

Only new ones; this is not retroactive.

-Brett


> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[Brett Cannon]

On Tue, Mar 5, 2019 at 5:33 AM Jeroen Demeyer  wrote:

> On 2019-03-05 14:05, Calvin Spealman wrote:
> > I'm worried this creates a gatekeeping perception that will scare away
> > contributors.
>

It might, but if people are not prepared properly for the PEP process then
it's best to spare them and everyone else the time sink.


>
> +1
>
> I also expressed this worry at https://github.com/python/peps/pull/903
>
> You could keep the positive part of the sponsoring idea (somebody acting
> as mentor) but drop the negative part (make it a hard requirement to
> find a sponsor supporting the proposal before the proposal can even
> become a draft PEP).
>

The hard requirement is on purpose. This is not a suggestion for a reason
as PEPs are not a cheap, cost-free thing for both authors and those
participating in the discussion. They take up a ton of time and if people
are not properly equipped to be successful then it just leads to a massive
loss of time that could be been better used by everyone involved.

Please also realize that the top 4 PEP authors are on the steering council,
and some of the longest active core devs and PEP editors are on the
council, so this isn't coming from people that lack experience and exposure
to all facets of the PEP process.

As I said in my announcement email, if this turns out to be a bad decision
then we can change the process back/again, but please do realize this is
not coming out of thin air just because we like fiddling with the PEP
process.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[Brett Cannon]

On Tue, Mar 5, 2019 at 3:36 AM Victor Stinner  wrote:

> Hi,
>
> Le mar. 5 mars 2019 à 02:53, Brett Cannon  a écrit :
> > The steering council has implemented a new idea called sponsors to the
> PEP process (...). The thinking is that to help make sure PEPs from
> non-core developers receive appropriate guidance through the PEP process
> (...)
>
> Hum, this isn't fully new, some PEPs already got a "PEP champion" (old
> name), no?
>

Sure. You can consider this just making it a more formal thing then.

-Brett


>
> A recent example is PEP 572 who has been "championed" by Guido van
> Rossum, then by Tim Peters. In this specific case, they became
> co-authors :-)
>
> > ... eventually becoming a co-author or BDFL-delegate later
>
> Nitpick: since Python has no more BDFL, maybe the expression should
> becocme "PEP-delegate"? ;-)
>

That's covered in PEP 1 as to why the name has been kept so far.

-Brett


>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[Jeroen Demeyer]

On 2019-03-05 18:14, Steve Dower wrote:

However, if you don't have
*a single* core developer on board from python-ideas, chances are the
whole team is going to reject the proposal.


Sure, I couldn't agree more. But this is something that a PEP mentor 
(instead of sponsor) also could deal with. Any potential mentor would 
quickly dismiss the PEP as having no chance and that would work just fine.


The problem with the "sponsor" idea is that the sponsor must come from 
the group of core devs supporting the PEP. What if all core devs 
supporting it don't have time to act as sponsor or just don't care enough?


On the other hand, if there is some support for an idea, then anybody 
should be able to mentor even if the mentor doesn't personally support 
the idea. I guess the mentor shouldn't be opposed either, but there is a 
large gray zone of -0/+0 in between where mentors could come from.



Jeroen.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[Brett Cannon]

On Tue, Mar 5, 2019 at 11:59 AM Jeroen Demeyer  wrote:

> On 2019-03-05 18:14, Steve Dower wrote:
> > However, if you don't have
> > *a single* core developer on board from python-ideas, chances are the
> > whole team is going to reject the proposal.
>
> Sure, I couldn't agree more. But this is something that a PEP mentor
> (instead of sponsor) also could deal with. Any potential mentor would
> quickly dismiss the PEP as having no chance and that would work just fine.
>
> The problem with the "sponsor" idea is that the sponsor must come from
> the group of core devs supporting the PEP. What if all core devs
> supporting it don't have time to act as sponsor or just don't care enough?
>

If no one cares enough then there isn't enough support to begin with. I
can't think of a PEP that was accepted with a universally lukewarm
reception; there's always been at least one person who liked the idea to
care.


> On the other hand, if there is some support for an idea, then anybody
> should be able to mentor even if the mentor doesn't personally support
> the idea. I guess the mentor shouldn't be opposed either, but there is a
> large gray zone of -0/+0 in between where mentors could come from.
>

If the hypothetical situation comes up of:

   1. An external person proposes a PEP
   2. No supportive core dev has time to sponsor
   3. Someone who doesn't support the PEP is willing to sponsor

then we can talk about changing the process, but otherwise we are worrying
about a hypothetical situation versus personal experience which suggests
this won't be the case. IOW we need to give this a shot before we consider
changing it.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[Chris Angelico]

On Wed, Mar 6, 2019 at 7:41 AM Brett Cannon  wrote:
>
>
>
> On Tue, Mar 5, 2019 at 11:59 AM Jeroen Demeyer  wrote:
>>
>> On 2019-03-05 18:14, Steve Dower wrote:
>> > However, if you don't have
>> > *a single* core developer on board from python-ideas, chances are the
>> > whole team is going to reject the proposal.
>>
>> Sure, I couldn't agree more. But this is something that a PEP mentor
>> (instead of sponsor) also could deal with. Any potential mentor would
>> quickly dismiss the PEP as having no chance and that would work just fine.
>>
>> The problem with the "sponsor" idea is that the sponsor must come from
>> the group of core devs supporting the PEP. What if all core devs
>> supporting it don't have time to act as sponsor or just don't care enough?
>
>
> If no one cares enough then there isn't enough support to begin with. I can't 
> think of a PEP that was accepted with a universally lukewarm reception; 
> there's always been at least one person who liked the idea to care.
>
>>
>> On the other hand, if there is some support for an idea, then anybody
>> should be able to mentor even if the mentor doesn't personally support
>> the idea. I guess the mentor shouldn't be opposed either, but there is a
>> large gray zone of -0/+0 in between where mentors could come from.
>
>
> If the hypothetical situation comes up of:
>
> An external person proposes a PEP
> No supportive core dev has time to sponsor
> Someone who doesn't support the PEP is willing to sponsor
>
> then we can talk about changing the process, but otherwise we are worrying 
> about a hypothetical situation versus personal experience which suggests this 
> won't be the case. IOW we need to give this a shot before we consider 
> changing it.
>

How much effort does it take to sponsor a PEP? I'm not a core dev, but
I can help someone with the work of writing and publishing. So if, in
that hypothetical situation, some (very busy) core dev were willing to
say "yeah, go ahead, put my name on it", would that be sufficient? If
so, it shouldn't be a problem to require this - any proposal with
enough support to be worth PEPing should have at least one person
who's willing to have his/her name in the headers.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[Steve Dower]

On 05Mar2019 1245, Chris Angelico wrote:

How much effort does it take to sponsor a PEP? I'm not a core dev, but
I can help someone with the work of writing and publishing. So if, in
that hypothetical situation, some (very busy) core dev were willing to
say "yeah, go ahead, put my name on it", would that be sufficient? If
so, it shouldn't be a problem to require this - any proposal with
enough support to be worth PEPing should have at least one person
who's willing to have his/her name in the headers.


For the record, now that he's joined the conversation, Chris is who I 
had in mind when I invented the term "PEP triager" in my email :)


If we had a way of appointing people who we trust to be non-core dev 
sponsors of PEPs, I'd nominate him. Though I suspect he's well known 
enough to the council that they'd accept his support of a PEP as 
sufficient to consider it from someone who's otherwise completely 
unknown. There are always grey areas in any policy.


Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

[Steve Holden]

On Tue, Mar 5, 2019 at 9:04 PM Steve Dower  wrote:

> On 05Mar2019 1245, Chris Angelico wrote:
> > How much effort does it take to sponsor a PEP? I'm not a core dev, but
> > I can help someone with the work of writing and publishing. So if, in
> > that hypothetical situation, some (very busy) core dev were willing to
> > say "yeah, go ahead, put my name on it", would that be sufficient? If
> > so, it shouldn't be a problem to require this - any proposal with
> > enough support to be worth PEPing should have at least one person
> > who's willing to have his/her name in the headers.
>
> For the record, now that he's joined the conversation, Chris is who I
> had in mind when I invented the term "PEP triager" in my email :)
>
> If we had a way of appointing people who we trust to be non-core dev
> sponsors of PEPs, I'd nominate him. Though I suspect he's well known
> enough to the council that they'd accept his support of a PEP as
> sufficient to consider it from someone who's otherwise completely
> unknown. There are always grey areas in any policy.
>

If core devs trust someone enough to let them act as a PEP sponsor, they
probably know at least one core dev well enough to get them to add their
name as sponsor on the condition that they are only responsiible for
ensuring their "proxy" (?) responds adequately and in a sufficiently timely
manner.

I don't have a great deal to add to most conversations here, but I would
urge all concerned to consider Brett's point, from my own now distant
experience as a PSF chair. If I may paraphrase him, it's easier to change
the rules when someone wants or needs to do something outside their current
scope than it is to devise bullet-proof rules. It was only after I learned
this lesson that much of the constitutional lawyering in the PSF was
(gradually) replaced by useful mission-directed volunteer-led activity.

Please don't concern yourselves too much about process, but instead focus
on the desired results. If lawyering is needed, delegate it to the PSF! I'd
rather have you pushing Python forward ;-).

Finally, thanks again to everyone who contributes, particularly for
managing to hide a great deal of Python's modern-day complexity from those
who neither want nor need to know about it. Ultimately I think that is
perhaps the biggest factor fuelling the language's continued growth.

Kind regards
Steve Holden
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Summary of Python tracker Issues

[Inada Naoki]

Thank you for fixing it.Weekly status give me motivation to look issues.

-- 
Inada Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASE] Python 2.7.16

[Benjamin Peterson]

On Tue, Mar 5, 2019, at 03:18, Miro Hrončok wrote:
> On 04. 03. 19 4:30, Benjamin Peterson wrote:
> > Hello all,
> > I'm pleased to announce the immediate availability of Python 2.7.16 for 
> > download at https://www.python.org/downloads/release/python-2716/.
> > 
> > The only change since the release candidate was a fix for the IDLE icon on 
> > macOS. See https://bugs.python.org/issue32129. Refer to the changelog for a 
> > full list of changes: 
> > https://raw.githubusercontent.com/python/cpython/v2.7.16/Misc/NEWS.d/2.7.16rc1.rst
> 
> 
> https://www.python.org/downloads/release/python-2716/ links changelog to 
> https://raw.githubusercontent.com/python/cpython/v2.7.16/Misc/NEWS.d/2.7.16.rst
>  
> but that only has 1 change (I suppose against rc1).
> 
> Is there a better link, or should I read those two combined?
> 
> https://raw.githubusercontent.com/python/cpython/v2.7.16/Misc/NEWS.d/2.7.16rc1.rst
> https://raw.githubusercontent.com/python/cpython/v2.7.16/Misc/NEWS.d/2.7.16.rst

Correct, those the full delta between 2.7.15 and 2.7.16.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com