Re: [Python-Dev] Interested in serving on Steering Council

2019-01-04 Thread Antoine Pitrou

Hi David,

On Fri, 4 Jan 2019 15:24:20 -0500
David Mertz  wrote:
> 
> I've been part of the Python community since 1998, but really active in it
> since about 2001.  During the early 2000s, I wrote a large number of widely
> read articles promoting Python, often delving into explaining semi-obscure
> features and language design issues.  Most of these were with in my column
> _Charming Python_.  I believe that several changes in Python itself—such as
> making coroutines easier to use and the design of metaclasses and class
> decorators—were significantly influenced by things I wrote on the topics.
> [snip]

Those are useful things to know, thank you.

> If the core developers feel that the overwhelming qualification for the
> Steering Committee is familiarity with the C code base of CPython, then
> indeed I am not the best candidate for that.

Obviously not the overwhelming qualification (though at least _some_ of
the committee members would have to be familiar with the C code base, I
think).

> If language design issues are
> more important—and especially if thinking about Python's place among users
> and industry are important, then I think I'm a very good candidate for the
> role.

That, but I think also familiarity with the development and
contribution process, will definitely play a role.  In other words, if
some external candidate gets elected I would hope they take the time to
become familiar with how things work in that regard, and try to
contribute themselves (not necessarily to make important contributions
to the codebase but to understand the daily routine).

Regards

Antoine.
___
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] Interested in serving on Steering Council

2019-01-04 Thread David Mertz
I do not wish to presume too much on the judgement of the core developers.
But I thank Steve Dower for his characterizations which pretty much exactly
explain why I've had those involvements with the Python community and
language I have had, and haven't done other things.

I've been part of the Python community since 1998, but really active in it
since about 2001.  During the early 2000s, I wrote a large number of widely
read articles promoting Python, often delving into explaining semi-obscure
features and language design issues.  Most of these were with in my column
_Charming Python_.  I believe that several changes in Python itself—such as
making coroutines easier to use and the design of metaclasses and class
decorators—were significantly influenced by things I wrote on the topics.

Mostly in the period after writing that column, i.e. during the 2010s, I
served as a Director of the PSF; both before and since my time as a
Director, I've chaired several PSF committees.  That likewise felt like a
way I could advance Python best, but from more of an organizational or
social perspective than a technical one.  It is interesting to me that
whereas when I started volunteering for the PSF, there was significant
overlap between the PSF board and the core-committers, I think there is
little or no overlap today.  For better or worse, PSF is much more
community than technical today.  I feel like my own skills and interest
remain somewhat at the intersection of those aspects of Python.

I did not choose during that time, nor since, to become a CPython core
developer.  I've certainly contributed to other projects in the Python
ecosystem (I'm not sure if those are "related projects" in the sense Steve
mentions).  Part of that is time commitment needed, but more of it is my
personal strategic choices about what I could best do to advance Python in
the world.  I've felt I can do more by writing, speaking, and participating
in the PSF, than I would have by working on the CPython code base itself.

In particular, I always felt that I am not nearly as strong of a *C*
developer as are most core developers.  In Python itself, yes, but not in
C.  I am certain that I could have found some small bug to fix or small
feature to add, and gotten it accepted.  But doing that would have taken me
comparatively more effort than it would many others; I felt that effort was
better targeted towards educating Python users and teaching the user-level
language design choices Python has made.

If the core developers feel that the overwhelming qualification for the
Steering Committee is familiarity with the C code base of CPython, then
indeed I am not the best candidate for that.  If language design issues are
more important—and especially if thinking about Python's place among users
and industry are important, then I think I'm a very good candidate for the
role.  In particular, I believe my judgement about "Is this feature good
for Python users?" would be as good as that of most anyone (maybe other
than Guido); but I recognize that my judgement about "Is this feature
straightforward to implement in CPython?" or "What are the performance
implications of this features?" are weaker than those of most core
developers.  Not to say I have *no* instinct about those other questions,
but I know to defer.

Best, David...


> (*) (or Committee, I don't remember :-)
> David may of course provide an answer for himself, but allow me to
> provide my answer (and this is why I pushed for allowing external
> nominations).
>
> Historically, the only reason to become a core committer was to commit
> code. Some of us no doubt desired or demonstrated greater influence, but
> all of us have committed code or reviewed and merged PRs, either
> directly to CPython or one of the related projects.
>
> This is not a job for everyone, but it's been the only job we had on offer.
>
> The closest alternative job was to be elected to the board of the Python
> Software Foundation. But this is still not a job for everyone. They also
> are not considered core committers, despite making significant
> contributions.
>
> We now have a new job on offer. Exactly what that job involves isn't
> quite defined yet, but it will certainly include some amount of
> project/program/process management, likely some customer/user engagement
> (or relationship management, if you prefer), and potentially some
> independent decision making.
>
> Guido is the only core developer who has previously contributed to
> Python in this way (whatever "this way" turns out to mean). The rest of
> us happily worked under "someone else" doing it.
>
> Meanwhile, many non-core committers in the Python community have spent
> their time building companies, consulting businesses or educational
> courses. Spending time writing code and reviewing PRs is not how they
> want to contribute, and so they have contributed in other ways -
> including writing and often reviewing PEPs. There was no need for them
> to be a core 

[Python-Dev] Summary of Python tracker Issues

2019-01-04 Thread Python tracker


ACTIVITY SUMMARY (2018-12-28 - 2019-01-04)
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:
  open6922 (+19)
  closed 40487 (+34)
  total  47409 (+53)

Open issues with patches: 2748 


Issues opened (34)
==

#35606: Add prod() function to the math module
https://bugs.python.org/issue35606  opened by rhettinger

#35608: python3 multiprocessing queue deadlock when use thread and pro
https://bugs.python.org/issue35608  opened by beruhan

#35610: IDLE: replace use of EditorWindow.context_use_ps1
https://bugs.python.org/issue35610  opened by terry.reedy

#35611: open doesn't call IncrementalEncoder with final=True
https://bugs.python.org/issue35611  opened by haney

#35615: "RuntimeError: Dictionary changed size during iteration" when 
https://bugs.python.org/issue35615  opened by ltfish

#35616: Change references to '4.0'.
https://bugs.python.org/issue35616  opened by terry.reedy

#35617: unittest discover does not work with implicit namespaces
https://bugs.python.org/issue35617  opened by Simon Fagerholm

#35618: Allow users to set suffix list in cookiejar policy
https://bugs.python.org/issue35618  opened by xtreak

#35619: Support custom data descriptors in pydoc
https://bugs.python.org/issue35619  opened by serhiy.storchaka

#35620: asyncio test failure on appveyor
https://bugs.python.org/issue35620  opened by terry.reedy

#35621: asyncio.create_subprocess_exec() only works with main event lo
https://bugs.python.org/issue35621  opened by sth

#35622: Add support for Linux SCHED_DEADLINE
https://bugs.python.org/issue35622  opened by mb_

#35624: Shelve sync issues while using Gevent
https://bugs.python.org/issue35624  opened by Oded Engel

#35625: documentation of list, set & dict comprehension make no mentio
https://bugs.python.org/issue35625  opened by bzip2

#35627: multiprocessing.queue in 3.7.2 doesn't behave as it was in 3.7
https://bugs.python.org/issue35627  opened by June Kim

#35628: Allow lazy loading of translations in gettext.
https://bugs.python.org/issue35628  opened by s-ball

#35629: hang and/or leaked processes with multiprocessing.Pool(...).im
https://bugs.python.org/issue35629  opened by Anthony Sottile

#35632: support unparse for Suite ast
https://bugs.python.org/issue35632  opened by thautwarm

#35633: test_eintr fails on AIX since fcntl functions were modified
https://bugs.python.org/issue35633  opened by Michael.Felt

#35634: kwargs regression when there are multiple entries with the sam
https://bugs.python.org/issue35634  opened by iceboy

#35635: asyncio.create_subprocess_exec() only works in main thread
https://bugs.python.org/issue35635  opened by stefan

#35636: remove redundant check in unicode_hash(PyObject *self)
https://bugs.python.org/issue35636  opened by Ma Lin

#35638: Introduce fixed point locale aware format type for floating po
https://bugs.python.org/issue35638  opened by steelman

#35639: Lowecasing Unicode Characters
https://bugs.python.org/issue35639  opened by kingofsevens

#35640: Allow passing PathLike arguments to SimpleHTTPRequestHandler
https://bugs.python.org/issue35640  opened by eamanu

#35642: _asynciomodule.c compiled in both pythoncore.vcxproj and _asyn
https://bugs.python.org/issue35642  opened by Gregory.Szorc

#35644: venv doesn't work on Windows when no venvlauncher executable p
https://bugs.python.org/issue35644  opened by Ray Donnelly

#35647: Cookie path check returns incorrect results
https://bugs.python.org/issue35647  opened by xtreak

#35649: http.client doesn't close. Infinite loop
https://bugs.python.org/issue35649  opened by skorpeo

#35651: PEP 257 (active) references PEP 258 (rejected) as if it were a
https://bugs.python.org/issue35651  opened by ExplodingCabbage

#35652: Add use_srcentry parameter to shutil.copytree() II
https://bugs.python.org/issue35652  opened by flokX

#35654: Remove 'guarantee' that sorting only relies on __lt__ from sor
https://bugs.python.org/issue35654  opened by mjpieters

#35656: More matchers in unittest.mock
https://bugs.python.org/issue35656  opened by Petter S

#35657: multiprocessing.Process.join() ignores timeout if child proces
https://bugs.python.org/issue35657  opened by Huazuo Gao



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

#35656: More matchers in unittest.mock
https://bugs.python.org/issue35656

#35652: Add use_srcentry parameter to shutil.copytree() II
https://bugs.python.org/issue35652

#35651: PEP 257 (active) references PEP 258 (rejected) as if it were a
https://bugs.python.org/issue35651

#35647: Cookie path check returns incorrect results
https://bugs.python.org/issue35647

#35642: _asynciomodule.c compiled in both pythoncore.vcxproj and _asyn
https://bugs.python.org/issue35642

#35640: Allow passing PathLike arguments to SimpleHTTPRequestHandler
https://bugs.python.org/issue35640

#35635: 

Re: [Python-Dev] Interested in serving on Steering Council

2019-01-04 Thread Antoine Pitrou
On Fri, 4 Jan 2019 14:27:10 +1100
Steve Dower  wrote:
> 
> We now have a new job on offer. Exactly what that job involves isn't
> quite defined yet, but it will certainly include some amount of
> project/program/process management, likely some customer/user engagement
> (or relationship management, if you prefer), and potentially some
> independent decision making.
> 
> Guido is the only core developer who has previously contributed to
> Python in this way (whatever "this way" turns out to mean).

Not exactly.  Nick's role on packaging comes to mind.  More modestly,
several of us have served as BDFL delegates, have steered various
processes (such as VCS migration), and/or have been responsible
(officially or not) for subparts of the project (such as documentation,
buildbots, version control...).

> In the PEP 8016 discussions (pre vote), we agreed that if we chose to
> elect someone who is not currently a core developer, we would also
> probably vote to make them a core developer, so there is no harm in
> allowing externals to be nominated.

The Council is going to be a 5-person body, some some amount of
involvement and dedication is expected from each of the Council's
members if we want it to function correctly (it's probably not just a
supervision body where you can participate in a meeting every 3 months,
answer a couple e-mails and call it done).

I already have a hard time imagining my level of involvement being
enough for candidating on the Council.  So I would be skeptical of
voting for someone who hasn't submitted a single patch to the codebase
in 10+ years, for example.

Moreover, someone who has never contributed to the codebase hasn't
really experienced how contributing works, which doesn't make them a
very good candidate for managing contributors, IMHO.

Regards

Antoine.
___
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