Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Steve Holden
As a mere user I'd like to thank the developer team for biting this bullet.
Remembering the transition to Git I am sure that the further
democratisation (?) of the development process will similarly increase the
diversity and scope of the development effort.

It will indeed be a significant effort to effect this migration. While it's
inevitable this will involve significant dev time, perhaps there roles can
be identified specifically as to be filled by _other_ than core devs.


On Wed, May 15, 2019 at 2:43 AM Victor Stinner  wrote:

> Congrats Mariatta :-)
>
> Victor
>
> Le mer. 15 mai 2019 à 03:14, Barry Warsaw  a écrit :
> >
> > As the BDFL-Delegate for PEP 581, and with the unanimous backing of the
> rest of the Steering Council, I hereby Accept this PEP.
> >
> > We would like to thank Mariatta for championing PEP 581, and to all the
> contributors to the discussion, both pro and con.  We appreciate your
> candor and respect for your fellow developers.  The SC believes that this
> migration is in the best interest of the Python community, and we look
> forward to the elaboration of the detailed migration plan (PEP 588).
> >
> > We also extend our heartfelt thanks Berker, Ezio, and everyone who has
> helped develop and maintain Roundup and bugs.python.org over the years.
> bpo has been a critical component for Python development for a very long
> time, and we all greatly appreciate the time, effort, and devotion you have
> put into this resource.
> >
> > https://www.python.org/dev/peps/pep-0581/
> >
> > Onward we go!  The migration will be a large effort, with much planning,
> development, and testing, and we welcome volunteers who wish to help make
> it a reality.  I look forward to your contributions on PEP 588 and the
> actual work of migrating issues to GitHub.
> >
> > Cheers,
> > -Barry (BDFL-Delegate, and on behalf of the Python Steering Council)
> >
> > ___
> > 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/vstinner%40redhat.com
>
>
>
> --
> 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/steve%40holdenweb.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


Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Antoine Pitrou
On Wed, 15 May 2019 08:40:58 +0100
Steve Holden  wrote:
> As a mere user I'd like to thank the developer team for biting this bullet.
> Remembering the transition to Git I am sure that the further
> democratisation (?) of the development process will similarly increase the
> diversity and scope of the development effort.

"Similarly"?

We still lack some metrics on that point, IIRC.

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] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Antoine Pitrou
On Tue, 14 May 2019 18:11:14 -0700
Barry Warsaw  wrote:

> As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest 
> of the Steering Council, I hereby Accept this PEP.

For future reference, is it possible to post the Steering Council's
reflection and rationale on the PEP?

Thank you

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] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Ivan Pozdeev via Python-Dev

On 15.05.2019 11:48, Antoine Pitrou wrote:

On Tue, 14 May 2019 18:11:14 -0700
Barry Warsaw  wrote:


As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of 
the Steering Council, I hereby Accept this PEP.

For future reference, is it possible to post the Steering Council's
reflection and rationale on the PEP?
+1. Specifically, I'd like to know if the risks and the potential for GitHub missing any needed features were estimated. The PEP says 
nothing about this.

Thank you

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/vano%40mail.mipt.ru


--
Regards,
Ivan

___
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] Adding a toml module to the standard lib?

2019-05-15 Thread Bastian Venthur

Hi,

I'd like to discuss the idea to add a module to parse TOML [toml-lang] 
to Python's standard library.


PEP-0518 -- Specifying Minimum Build System Requirements for Python 
Projects [pep] suggests to store build system dependencies in 
`pyproject.toml`, yet Python itself does not support this format. 
Various packaging related projects like pip and pipenv already support 
PEP-0518 and vendored one of the existing TOML libraries in order to 
read `pyproject.toml` files.


Besides that, TOML seems a better alternative to .cfg/.ini, .json -- 
both of which are already supported by Python's standard lib and 
parsing/dumping TOML properly is tricky enough to solve it properly 
[requirements].


There are a couple of TOML implementations out there [toml, pytoml, 
tomlkit] and one would have to find out which one to prefer and migrate 
into the stdlib.


If the result of this discussion is leaning towards adding TOML, I'd 
volunteer to do it. This includes: coordinating with the maintainer of 
the chosen library, writing the PEP (hopefully with some help) and 
maintain the module for at least two years.



Cheers,

Bastian


[toml-lang]: https://github.com/toml-lang/toml
[pep]: https://www.python.org/dev/peps/pep-0518
[pip]: https://github.com/pypa/pip
[pipenv]: https://github.com/pypa/pipenv
[toml]: https://github.com/uiri/toml
[pytoml]: https://github.com/avakar/pytoml
[tomlkit]: https://github.com/sdispater/tomlkit
[requirements]: https://devguide.python.org/stdlibchanges/#requirements


--
Dr. Bastian Venthur  http://venthur.de
Debian Developer venthur at debian 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] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Christian Heimes
On 15/05/2019 10.55, Ivan Pozdeev via Python-Dev wrote:
> On 15.05.2019 11:48, Antoine Pitrou wrote:
>> On Tue, 14 May 2019 18:11:14 -0700
>> Barry Warsaw  wrote:
>>
>>> As the BDFL-Delegate for PEP 581, and with the unanimous backing of
>>> the rest of the Steering Council, I hereby Accept this PEP.
>> For future reference, is it possible to post the Steering Council's
>> reflection and rationale on the PEP?
> +1. Specifically, I'd like to know if the risks and the potential for
> GitHub missing any needed features were estimated. The PEP says nothing
> about this.

I'm not happy with the fact, that the PEP does not mention any arguments
or concerns that were raised against the current feature set of Github's
issue tracker. In the past, PEPs also listed risks and arguments against
a change, then weighted the arguments.

What are the next step? Will there be another PEP that explores how we
are going to deal with migration, workflow changes, and how we plan to
map current BPO features to Github?

Christian
___
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] Adding a toml module to the standard lib?

2019-05-15 Thread Antoine Pitrou
On Wed, 15 May 2019 10:44:35 +0200
Bastian Venthur  wrote:
> Hi,
> 
> I'd like to discuss the idea to add a module to parse TOML [toml-lang] 
> to Python's standard library.

How stable is the TOML format?  Is it bound to change significantly in
the coming years?

If the format is stable enough, then I think it's a good idea.

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] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Paul Moore
On Wed, 15 May 2019 at 09:51, Antoine Pitrou  wrote:
>
> On Tue, 14 May 2019 18:11:14 -0700
> Barry Warsaw  wrote:
>
> > As the BDFL-Delegate for PEP 581, and with the unanimous backing of the 
> > rest of the Steering Council, I hereby Accept this PEP.
>
> For future reference, is it possible to post the Steering Council's
> reflection and rationale on the PEP?

Also, is there an archive of the discussions anywhere? The PEP says
discussions happened on Zulip, but I don't follow that and I don't
know where I can find an archived copy of the discussions.

It's not as if I'm going to object to the PEP (I'd have participated
in the discussions if I had a strong opinion) but I am curious.

Paul
___
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] Adding a toml module to the standard lib?

2019-05-15 Thread Bastian Venthur

On 15.05.19 11:33, Antoine Pitrou wrote:

How stable is the TOML format?  Is it bound to change significantly in
the coming years?

If the format is stable enough, then I think it's a good idea.



The last update to the spec [1] was 10 months ago and added a few 
features. The version before that was stable for more than 3 years. It 
is also worth noting that he writes about the current version [2]:


"As of version 0.5.0, TOML should be considered extremely stable. The 
goal is for version 1.0.0 to be backwards compatible (as much as humanly 
possible) with version 0.5.0. All implementations are strongly 
encouraged to become 0.5.0 compatible so that the transition to 1.0.0 
will be simple when that happens."


That is of course no guarantee, but maybe the best we can hope for.


Cheers,

Bastian


[1]: https://github.com/toml-lang/toml/releases
[2]: https://github.com/toml-lang/toml


--
Dr. Bastian Venthur  http://venthur.de
Debian Developer venthur at debian 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] Adding a toml module to the standard lib?

2019-05-15 Thread Paul Moore
On Wed, 15 May 2019 at 11:49, Bastian Venthur  wrote:
>
> On 15.05.19 11:33, Antoine Pitrou wrote:
> > How stable is the TOML format?  Is it bound to change significantly in
> > the coming years?
> >
> > If the format is stable enough, then I think it's a good idea.
>
>
> The last update to the spec [1] was 10 months ago and added a few
> features. The version before that was stable for more than 3 years. It
> is also worth noting that he writes about the current version [2]:

I think it's a good idea too - the analysis in PEP 518 concluded that
TOML was, while maybe not perfect, certainly a good general purpose
config file format, and I think that analysis is applicable in other
contexts as well. While "easy to install/vendor" was a point in the
analysis, I think having TOML support in the stdlib would be useful
for simple scripts/applications looking for a good "out of the box"
config solution.

Paul
___
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] Adding a toml module to the standard lib?

2019-05-15 Thread Steven D'Aprano
On Wed, May 15, 2019 at 10:44:35AM +0200, Bastian Venthur wrote:
> Hi,
> 
> I'd like to discuss the idea to add a module to parse TOML [toml-lang] 
> to Python's standard library.

You ought to read this thread here:

https://mail.python.org/pipermail/python-ideas/2018-October/054101.html

It isn't very long (only about a dozen or so quite short posts) but you 
probably ought to be at least familiar with it, and if possibly respond 
to any opposing comments.

Thanks,




-- 
Steven
___
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] Adding a toml module to the standard lib?

2019-05-15 Thread Steven D'Aprano
On Wed, May 15, 2019 at 09:35:16PM +1000, Steven D'Aprano wrote:
> It isn't very long (only about a dozen or so quite short posts) but you 
> probably ought to be at least familiar with it, and if possibly respond 
> to any opposing comments.

Sorry, to clarify, I don't mean respond on the Python-Ideas thread. I 
think it is sufficient to keep the current discussion here.


-- 
Steven
___
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] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Victor Stinner
Le mer. 15 mai 2019 à 11:31, Christian Heimes  a écrit :
> What are the next step? Will there be another PEP that explores how we
> are going to deal with migration, workflow changes, and how we plan to
> map current BPO features to Github?

Yes, it's the:

PEP 588 -- GitHub Issues Migration Plan
https://www.python.org/dev/peps/pep-0588/

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] Adding a toml module to the standard lib?

2019-05-15 Thread Victor Stinner
H Bastian,

IMHO we should wait until the format reach version 1.0, since the
stdlib has a slow release cycle (one release every 18 months). Too
slow for a "fast moving" standard.

In the meanwhile, I'm sure setuptools and pip will manage to install a
toml parser/generator for their needs, as they already do :-)

Victor

Le mer. 15 mai 2019 à 12:50, Bastian Venthur  a écrit :
>
> On 15.05.19 11:33, Antoine Pitrou wrote:
> > How stable is the TOML format?  Is it bound to change significantly in
> > the coming years?
> >
> > If the format is stable enough, then I think it's a good idea.
>
>
> The last update to the spec [1] was 10 months ago and added a few
> features. The version before that was stable for more than 3 years. It
> is also worth noting that he writes about the current version [2]:
>
> "As of version 0.5.0, TOML should be considered extremely stable. The
> goal is for version 1.0.0 to be backwards compatible (as much as humanly
> possible) with version 0.5.0. All implementations are strongly
> encouraged to become 0.5.0 compatible so that the transition to 1.0.0
> will be simple when that happens."
>
> That is of course no guarantee, but maybe the best we can hope for.
>
>
> Cheers,
>
> Bastian
>
>
> [1]: https://github.com/toml-lang/toml/releases
> [2]: https://github.com/toml-lang/toml
>
>
> --
> Dr. Bastian Venthur  http://venthur.de
> Debian Developer venthur at debian 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/vstinner%40redhat.com



-- 
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] Adding a toml module to the standard lib?

2019-05-15 Thread Paul Ganssle
As someone involved in the packaging side of this, I think while we'd
eventually /appreciate/ a TOML parser in the standard library, I agree
with Victor that there's no rush, for two reasons:

1. setuptools and pip have a decent number of dependencies that we
vendor /anyway/, so vendoring one more is not a big deal.
2. We will be supporting older versions of Python for some time to come,
so we'd need to vendor a TOML-parser backport for several years before
we could actually use the one in the standard library.

I think /if/ a 1.0 version of the spec is going to be forthcoming (not
clear from the issue requesting it:
https://github.com/toml-lang/toml/issues/515 ), then it's worth waiting
at least a bit longer for it.

I also think it's probably worth asking the current maintainers of
TOML-parsing libraries if /they/ think it's time to adopt/adapt one of
their libraries for use in the standard library. They probably have a
better perspective on the stability and maturity of their codebases.

Best,
Paul


On 5/15/19 8:39 AM, Victor Stinner wrote:
> H Bastian,
>
> IMHO we should wait until the format reach version 1.0, since the
> stdlib has a slow release cycle (one release every 18 months). Too
> slow for a "fast moving" standard.
>
> In the meanwhile, I'm sure setuptools and pip will manage to install a
> toml parser/generator for their needs, as they already do :-)
>
> Victor
>
> Le mer. 15 mai 2019 à 12:50, Bastian Venthur  a écrit :
>> On 15.05.19 11:33, Antoine Pitrou wrote:
>>> How stable is the TOML format?  Is it bound to change significantly in
>>> the coming years?
>>>
>>> If the format is stable enough, then I think it's a good idea.
>>
>> The last update to the spec [1] was 10 months ago and added a few
>> features. The version before that was stable for more than 3 years. It
>> is also worth noting that he writes about the current version [2]:
>>
>> "As of version 0.5.0, TOML should be considered extremely stable. The
>> goal is for version 1.0.0 to be backwards compatible (as much as humanly
>> possible) with version 0.5.0. All implementations are strongly
>> encouraged to become 0.5.0 compatible so that the transition to 1.0.0
>> will be simple when that happens."
>>
>> That is of course no guarantee, but maybe the best we can hope for.
>>
>>
>> Cheers,
>>
>> Bastian
>>
>>
>> [1]: https://github.com/toml-lang/toml/releases
>> [2]: https://github.com/toml-lang/toml
>>
>>
>> --
>> Dr. Bastian Venthur  http://venthur.de
>> Debian Developer venthur at debian 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/vstinner%40redhat.com
>
>


signature.asc
Description: OpenPGP digital signature
___
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] [python-committers] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Victor Stinner
Hi Paul,
Le mer. 15 mai 2019 à 11:40, Paul Moore  a écrit :
> Also, is there an archive of the discussions anywhere? The PEP says
> discussions happened on Zulip, but I don't follow that and I don't
> know where I can find an archived copy of the discussions.

Well, the PEP has been discussed a lot at many places since May 2018.

The PEP 581 has been (first?) discussed at the Language Summit which
was part of Pycon US 2018 (May 2018).

Discussion on the PR:

https://github.com/python/peps/pull/681/

Multiple threads on Discourse:

https://discuss.python.org/t/move-pep-581-discussion/873
https://discuss.python.org/t/pep-581-using-github-issues/535
https://discuss.python.org/t/what-are-next-steps-for-pep-581/864
https://discuss.python.org/t/pep-process-after-pep-8016/558/4

Thread on python-dev:

https://mail.python.org/pipermail/python-dev/2019-March/156626.html

Threads on python-committers:

https://mail.python.org/pipermail/python-committers/2018-May/005428.html
https://mail.python.org/pipermail/python-committers/2018-June/005506.html
https://mail.python.org/pipermail/python-committers/2018-July/005657.html

Discussion on Zulip Chat:

https://python.zulipchat.com/#narrow/stream/130206-pep581

The Steering Council discussed it internally as well:

https://github.com/python/steering-council/blob/master/updates/2019-04-26_steering-council-update.md

The PEP 581 and 588 have been discussed at the Language Summit which
was part of Pycon US 2019 (2 weeks ago).

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] RFC: PEP 587 "Python Initialization Configuration": 2nd version

2019-05-15 Thread Sebastian Koslowski
On Tue, May 14, 2019, 19:52 Steve Dower  wrote:

> It looks like Py_DecodeLocale() is available very early on - why
> wouldn't we recommend using this function? It seems to be nearly a
> drop-in replacement for mbtowcs in the samples, and if memory allocation
> is a big deal perhaps we could just add a version that writes to a buffer?
>
>
Actually, it is recommended in the docs
https://docs.python.org/3/c-api/init.html#c.Py_SetPythonHome

Sebastian
___
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] [python-committers] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Paul Moore
On Wed, 15 May 2019 at 15:56, Victor Stinner  wrote:
>
> Hi Paul,
> Le mer. 15 mai 2019 à 11:40, Paul Moore  a écrit :
> > Also, is there an archive of the discussions anywhere? The PEP says
> > discussions happened on Zulip, but I don't follow that and I don't
> > know where I can find an archived copy of the discussions.
>
> Well, the PEP has been discussed a lot at many places since May 2018.

Thanks for all of these. I appreciate the time you took locating them
for me. But I do have to say that I still can't really follow any
useful "thread of discussion" - it all seems very fragmented, and it's
difficult to see the progress towards consensus. Maybe that's just
because I'm too used to mailing lists :-)

> The PEP 581 has been (first?) discussed at the Language Summit which
> was part of Pycon US 2018 (May 2018).

Was that written up, or is it all just from people's memories by now?

> https://github.com/python/peps/pull/681/

Ah - I don't really follow this sort of PR discussion, as the github
emails don't tend to have sufficient context on what's being said, so
I (mostly) gave up a long time ago. Also, I tend to assume that
discussions on PRs are mostly about details of wording, and
substantive changes will be dealt with in a wider forum. I wonder if I
should be following PRs on the PEPs repository more closely...?

> Multiple threads on Discourse:
>
> https://discuss.python.org/t/move-pep-581-discussion/873
> https://discuss.python.org/t/pep-581-using-github-issues/535
> https://discuss.python.org/t/what-are-next-steps-for-pep-581/864
> https://discuss.python.org/t/pep-process-after-pep-8016/558/4
>
> Thread on python-dev:
>
> https://mail.python.org/pipermail/python-dev/2019-March/156626.html
>
> Threads on python-committers:
>
> https://mail.python.org/pipermail/python-committers/2018-May/005428.html
> https://mail.python.org/pipermail/python-committers/2018-June/005506.html
> https://mail.python.org/pipermail/python-committers/2018-July/005657.html

I saw these, but didn't get much of a sense of progress towards
agreement. Again, maybe just because they were lots of fragmented
threads and locations.

> Discussion on Zulip Chat:
>
> https://python.zulipchat.com/#narrow/stream/130206-pep581

I can't see this without logging in :-(

> The Steering Council discussed it internally as well:
>
> https://github.com/python/steering-council/blob/master/updates/2019-04-26_steering-council-update.md

I did see that, I was more wondering what led to that decision
(whether it was a general consensus from the core devs that it was a
good move, or mainly the SC's own view that prevailed).

> The PEP 581 and 588 have been discussed at the Language Summit which
> was part of Pycon US 2019 (2 weeks ago).

Again, has there been any write up of that (yet)?

As I say, I don't object to the decision, I'm more just trying to
better understand the process of being involved under the new regime
of the SC, combined with multiple fragmented forums for discussion. It
feels a lot harder these days to keep track of all the
discussions/decisions going on. But maybe that's a good thing - only
people with a genuine interest get involved, and I can spend less of
my time reading mailing lists! :-)

Paul
___
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] [python-committers] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Brett Cannon
On Wed, May 15, 2019 at 8:18 AM Paul Moore  wrote:

> On Wed, 15 May 2019 at 15:56, Victor Stinner  wrote:
> >
> > Hi Paul,
> > Le mer. 15 mai 2019 à 11:40, Paul Moore  a écrit :
> > > Also, is there an archive of the discussions anywhere? The PEP says
> > > discussions happened on Zulip, but I don't follow that and I don't
> > > know where I can find an archived copy of the discussions.
> >
> > Well, the PEP has been discussed a lot at many places since May 2018.
>
> Thanks for all of these. I appreciate the time you took locating them
> for me. But I do have to say that I still can't really follow any
> useful "thread of discussion" - it all seems very fragmented, and it's
> difficult to see the progress towards consensus. Maybe that's just
> because I'm too used to mailing lists :-)
>
> > The PEP 581 has been (first?) discussed at the Language Summit which
> > was part of Pycon US 2018 (May 2018).
>
> Was that written up, or is it all just from people's memories by now?
>

There's at least https://lwn.net/Articles/754779/. Don't remember if other
people wrote up their own summary.

[SNIP]

> The PEP 581 and 588 have been discussed at the Language Summit which
> > was part of Pycon US 2019 (2 weeks ago).
>
> Again, has there been any write up of that (yet)?
>

Not yet, but A. Jesse Jiryu Davis attended so the PSF could blog about it.



>
> As I say, I don't object to the decision, I'm more just trying to
> better understand the process of being involved under the new regime
> of the SC,


I think everyone is. :)

In the case of this PEP the various members of the SC have been keeping up
with the PEP and its discussions over the year that the PEP has been
around, we discussed the pros and cons that people brought up, thought
through what will be required for us to do the migration if the PEP was
accepted, and in the end decided it was worth the effort.


> combined with multiple fragmented forums for discussion.


A PEP is being worked on to try and propose a way to straighten this all
out, but travel, life, etc. has been keeping that one from being finished.
I've added discussing the status of it to our next meeting's agenda.


> It
> feels a lot harder these days to keep track of all the
> discussions/decisions going on. But maybe that's a good thing - only
> people with a genuine interest get involved, and I can spend less of
> my time reading mailing lists! :-)
>

Obviously YMMV, but I actually find it easier. :)

-Brett


>
> Paul
> ___
> python-committers mailing list
> python-committ...@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Brett Cannon
On Wed, May 15, 2019 at 5:38 AM Victor Stinner  wrote:

> Le mer. 15 mai 2019 à 11:31, Christian Heimes  a
> écrit :
> > What are the next step? Will there be another PEP that explores how we
> > are going to deal with migration, workflow changes, and how we plan to
> > map current BPO features to Github?
>
> Yes, it's the:
>
> PEP 588 -- GitHub Issues Migration Plan
> https://www.python.org/dev/peps/pep-0588/
>

And to be very clear here, PEP 588 is *not* accepted yet, so it's open for
changes.

I personally would consider the accepting of PEP 581 as a signal that the
SC thinks it's worth putting the effort into migrating to GitHub for issues
and so now we can focus our efforts as a team in trying to make this result
in the workflow that we want.

And I suspect everyone knows this, but just in case, I want to personally
state that I hope everyone understands that there is no way everyone will
be happy with the outcome of this transition and that's okay. :) Workflow
is one of those things where people are very often opinionated (just look
at all of us and our preference in programming language ;) . Obviously we
can all do what we can to be accommodating and come up with a solution that
works for as many people as possible (including external folks like
triagers and issue reporters), but I hope everyone goes into this being as
understanding as possible so we can try to get the best outcome we can.
___
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] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Steve Dower

On 15May2019 0240, Paul Moore wrote:

On Wed, 15 May 2019 at 09:51, Antoine Pitrou  wrote:


On Tue, 14 May 2019 18:11:14 -0700
Barry Warsaw  wrote:


As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of 
the Steering Council, I hereby Accept this PEP.


For future reference, is it possible to post the Steering Council's
reflection and rationale on the PEP?


Also, is there an archive of the discussions anywhere? The PEP says
discussions happened on Zulip, but I don't follow that and I don't
know where I can find an archived copy of the discussions.


I think it would be ideal if the PEP itself summarised the major points 
of these discussions, or at least the links to the discussions (assuming 
we trust Zulip and Discourse to never lose them).


Right now I have a lot of fundamental problems with this PEP as written. 
But I'm assured that the Steering Council gave it thorough consideration 
and that the discussions covered all relevant aspects, so I'm not going 
to create too much of a fuss about it. If they want to move us 
completely to GitHub, so be it!


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] [python-committers] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Ezio Melotti
Hello,

On Wed, May 15, 2019 at 5:18 PM Paul Moore  wrote:
>
> On Wed, 15 May 2019 at 15:56, Victor Stinner  wrote:
> >
> > Hi Paul,
> > Le mer. 15 mai 2019 à 11:40, Paul Moore  a écrit :
> > > Also, is there an archive of the discussions anywhere? The PEP says
> > > discussions happened on Zulip, but I don't follow that and I don't
> > > know where I can find an archived copy of the discussions.
> >
> > Well, the PEP has been discussed a lot at many places since May 2018.
>
> Thanks for all of these. I appreciate the time you took locating them
> for me. But I do have to say that I still can't really follow any
> useful "thread of discussion" - it all seems very fragmented, and it's
> difficult to see the progress towards consensus. Maybe that's just
> because I'm too used to mailing lists :-)
>

I share the same concerns:
1) the discussion was fragmented between
zulip/discuss/github/python-dev/python-committers/sprints/pycons and
very difficult to follow, even for interested people (Victor already
posted several links but missed a few others);
2) the progress toward consensus was not clear and the approval came
somewhat unexpectedly (it was mentioned a couple of weeks ago on
https://mail.python.org/pipermail/python-committers/2019-April/006705.html
and AFAICT no further discussion took place in public forums since
then);

In addition:
1) the PEP contains several factual errors.  I pointed this out during
the core-sprints last year and more recently Berker pointed out some
on GitHub: https://github.com/python/peps/pull/1013 ;
2) the "discussions-to" header of the PEP points to the zulip stream.
The stream has not been active for 6 months (it got a few new messages
today, the previous activity was in Dec 2018);
3) most of the discussions linked by Victor happened last year.
Unless I missed some, the only discussions happened this year are the
two on Discuss from February (with 3 messages each from a total of 5
authors), and the python-dev thread from March (with 12 messages from
7 authors).  One of the two Discuss threads was a inquiry about the
process (https://discuss.python.org/t/move-pep-581-discussion/873);
4) Berker is/was writing a competing PEP, in order to address the
problems of PEP 581 more effectively since his comments on GitHub
haven't been addressed;
5) next week a student is supposed to start working for the PSF on
b.p.o and Roundup as part of Google Summer of Code
(http://python-gsoc.org/psf_ideas.html);
6) PEP 8016 says "The council should look for ways to use these powers
as little as possible. Instead of voting, it's better to seek
consensus. Instead of ruling on individual PEPs, it's better to define
a standard process for PEP decision making.";

To summarize, I feel the approval of this PEP is premature and that
consensus was reached in a way that wasn't very transparent, without
considering some of the concerns.
(This might also be a symptom of a wider problem caused by the
fragmentation of the discussions between the old MLs, discuss, zulip,
IRC, GitHub PRs and issues, and IRL meetings, but this is a separate
topic.)

Best Regards,
Ezio Melotti




> > The PEP 581 has been (first?) discussed at the Language Summit which
> > was part of Pycon US 2018 (May 2018).
>
> Was that written up, or is it all just from people's memories by now?
>
> > https://github.com/python/peps/pull/681/
>
> Ah - I don't really follow this sort of PR discussion, as the github
> emails don't tend to have sufficient context on what's being said, so
> I (mostly) gave up a long time ago. Also, I tend to assume that
> discussions on PRs are mostly about details of wording, and
> substantive changes will be dealt with in a wider forum. I wonder if I
> should be following PRs on the PEPs repository more closely...?
>
> > Multiple threads on Discourse:
> >
> > https://discuss.python.org/t/move-pep-581-discussion/873
> > https://discuss.python.org/t/pep-581-using-github-issues/535
> > https://discuss.python.org/t/what-are-next-steps-for-pep-581/864
> > https://discuss.python.org/t/pep-process-after-pep-8016/558/4
> >
> > Thread on python-dev:
> >
> > https://mail.python.org/pipermail/python-dev/2019-March/156626.html
> >
> > Threads on python-committers:
> >
> > https://mail.python.org/pipermail/python-committers/2018-May/005428.html
> > https://mail.python.org/pipermail/python-committers/2018-June/005506.html
> > https://mail.python.org/pipermail/python-committers/2018-July/005657.html
>
> I saw these, but didn't get much of a sense of progress towards
> agreement. Again, maybe just because they were lots of fragmented
> threads and locations.
>
> > Discussion on Zulip Chat:
> >
> > https://python.zulipchat.com/#narrow/stream/130206-pep581
>
> I can't see this without logging in :-(
>
> > The Steering Council discussed it internally as well:
> >
> > https://github.com/python/steering-council/blob/master/updates/2019-04-26_steering-council-update.md
>
> I did see that, I was more wondering what led to that decision

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Brett Cannon
On Wed, May 15, 2019 at 9:53 AM Steve Dower  wrote:

> On 15May2019 0240, Paul Moore wrote:
> > On Wed, 15 May 2019 at 09:51, Antoine Pitrou 
> wrote:
> >>
> >> On Tue, 14 May 2019 18:11:14 -0700
> >> Barry Warsaw  wrote:
> >>
> >>> As the BDFL-Delegate for PEP 581, and with the unanimous backing of
> the rest of the Steering Council, I hereby Accept this PEP.
> >>
> >> For future reference, is it possible to post the Steering Council's
> >> reflection and rationale on the PEP?
> >
> > Also, is there an archive of the discussions anywhere? The PEP says
> > discussions happened on Zulip, but I don't follow that and I don't
> > know where I can find an archived copy of the discussions.
>
> I think it would be ideal if the PEP itself summarised the major points
> of these discussions, or at least the links to the discussions (assuming
> we trust Zulip and Discourse to never lose them).
>
> Right now I have a lot of fundamental problems with this PEP as written.
> But I'm assured that the Steering Council gave it thorough consideration
>

Yes, sorry if that wasn't communicated better. This was in no way a
knee-jerk decision. Beyond all of us following this topic personally since
it was first brought up last year, we have also been discussing it nearly
every meeting in some form or another since we began discussing PEPs (which
would be probably since February).


> and that the discussions covered all relevant aspects, so I'm not going
> to create too much of a fuss about it. If they want to move us
> completely to GitHub, so be it!
>

I've added to our next meeting's agenda discussing potentially fleshing out
PEP 581 a bit more.

-Brett


>
> 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/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] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Guido van Rossum
IMO the text of PEP 581 could use some improvements to capture more of the
debate. For example:

- If people want to submit PRs to the peps repo that correct *factual*
mistakes in PEP 581, they're welcome to (and I will personally see that
they will be merged). For example, IIRC you *can* reply to a bpo issue via
email, so that bullet should probably be struck.

- If someone wants to volunteer a PR to the peps repo that adds a list of
objections against the move, e.g. losing certain bpo capabilities, or
specific undesirable behaviors or properties of GitHub, that will also be
entertained (but be reasonable).

But trust me that the SC didn't take this decision lightly. It was
unanimous, and we have all thought about this a great deal (and listened to
long arguments pro and con). It's also impossible to satisfy everyone --
some people find GitHub unacceptable (I've heard about 1-2 people who
refused to create GitHub accounts), but others find bpo unusable (the need
to have a bpo account in order to accept the CLA has been brought up
repeatedly).

A successful migration will take a lot of work, and PEP 588 is where we
keep track of tasks to be accomplished. (There are more that haven't made
it to that PEP, e.g. the mechanics of the actual move.) We're also hoping
to get professional help managing the migration so that not everything
relies on volunteers.

(Speaking of relying on volunteers, if you haven't seen Russel
Keith-Magee's keynote at the most recent PyCon US, please watch it. It is
an amazing thing. https://www.youtube.com/watch?v=ftP5BQh1-YM -- start at
21:00 to skip the conference opening remarks.)

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*

___
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] deprecation of abstractstaticmethod and abstractclassmethod

2019-05-15 Thread Ethan Furman

In issue 11610* abstractclassmethod and abstractstaticmethod were deprecated, 
apparently because they were redundant with the new technique of calling 
`classmethod` or `staticmethod` followed by a call to `abstractmethod`.  To put 
it in code:

# deprecated

class Foo(ABC):

@abstractclassmethod
def foo_happens(cls):
# do some fooey stuff

# the new(er) way

class Foo(ABC):

@classmethod
@abstractmethod
def foo_happens(cls):
# do some fooey stuff


I would like to remove the deprecated status of `abstractclassmethod` and 
`abstractstaticmethod` mainly because:

- using the combined decorator is easy to get right
  (@abstractmethod followed by @classmethod doesn't work)

- getting the order wrong can be hard to spot and fix

Obviously, decorator order matters for many, if not most, decorators out there -- so why should 
these two be any different?  Because 'abstract', 'class', and 'static' are adjectives -- they're 
describing the method, rather than changing it**; to use an example, what is the difference between 
"hot, dry sand" and "dry, hot sand"?  The sand is just as dry and just as hot 
either way.  In a debugging session looking at:

   @abstractmethod
   @classmethod
   def some_func(self, this, that, the_other):
# many
# many
...
...
...
# many
# lines
# of
# code

Not noticing that the two decorators are in reverse order would be very easy to 
do.

Because order matters here, but cognitively should not, a helper function to 
make sure it is always done right is a prime candidate to be added to a module 
-- and, luckily for us, those helper functions already exist!  Unfortunately, 
they are also deprecated, discouraging their use, when we should be encouraging 
their use.

What are the reasons to /not/ remove the deprecation?

--
~Ethan~



* https://bugs.python.org/issue11610

** I realize that abstractmethod does actually change the function, but that's 
an implementation detail.
___
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] deprecation of abstractstaticmethod and abstractclassmethod

2019-05-15 Thread Nathaniel Smith
I don't care about the deprecation either way. But can we fix the
individual decorators so both orders work? Even if it requires a special
case in the code, it seems worthwhile to remove a subtle user-visible
footgun.

On Wed, May 15, 2019, 12:39 Ethan Furman  wrote:

> In issue 11610* abstractclassmethod and abstractstaticmethod were
> deprecated, apparently because they were redundant with the new technique
> of calling `classmethod` or `staticmethod` followed by a call to
> `abstractmethod`.  To put it in code:
>
> # deprecated
>
> class Foo(ABC):
>
>  @abstractclassmethod
>  def foo_happens(cls):
>  # do some fooey stuff
>
> # the new(er) way
>
> class Foo(ABC):
>
>  @classmethod
>  @abstractmethod
>  def foo_happens(cls):
>  # do some fooey stuff
>
>
> I would like to remove the deprecated status of `abstractclassmethod` and
> `abstractstaticmethod` mainly because:
>
> - using the combined decorator is easy to get right
>(@abstractmethod followed by @classmethod doesn't work)
>
> - getting the order wrong can be hard to spot and fix
>
> Obviously, decorator order matters for many, if not most, decorators out
> there -- so why should these two be any different?  Because 'abstract',
> 'class', and 'static' are adjectives -- they're describing the method,
> rather than changing it**; to use an example, what is the difference
> between "hot, dry sand" and "dry, hot sand"?  The sand is just as dry and
> just as hot either way.  In a debugging session looking at:
>
> @abstractmethod
> @classmethod
> def some_func(self, this, that, the_other):
>  # many
>  # many
>  ...
>  ...
>  ...
>  # many
>  # lines
>  # of
>  # code
>
> Not noticing that the two decorators are in reverse order would be very
> easy to do.
>
> Because order matters here, but cognitively should not, a helper function
> to make sure it is always done right is a prime candidate to be added to a
> module -- and, luckily for us, those helper functions already exist!
> Unfortunately, they are also deprecated, discouraging their use, when we
> should be encouraging their use.
>
> What are the reasons to /not/ remove the deprecation?
>
> --
> ~Ethan~
>
>
>
> * https://bugs.python.org/issue11610
>
> ** I realize that abstractmethod does actually change the function, but
> that's an implementation detail.
> ___
> 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/njs%40pobox.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


Re: [Python-Dev] deprecation of abstractstaticmethod and abstractclassmethod

2019-05-15 Thread Steve Dower

On 15May2019 1248, Nathaniel Smith wrote:
I don't care about the deprecation either way. But can we fix the 
individual decorators so both orders work? Even if it requires a special 
case in the code, it seems worthwhile to remove a subtle user-visible 
footgun.


The classmethod and staticmethod objects already have a getter for 
__isabstractmethod__ that forwards to the underlying object, so they 
should just need a setter as well, right?


I also have no strong opinion about deprecation. But fixing this seems 
pretty straightforward and may be a good task for someone's first C 
contribution?


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


[Python-Dev] Consolidating channel of record [was: 581 (Using GitHub issues for CPython) is accepted]

2019-05-15 Thread Stephen J. Turnbull
Stripping the list of addressees, since I'm pretty sure all the
people who will *make* the decision read Python-Dev regularly, except
perhaps Carol.

Paul Moore writes:

 > Thanks for all of these. I appreciate the time you took locating them
 > for me. But I do have to say that I still can't really follow any
 > useful "thread of discussion" - it all seems very fragmented, and it's
 > difficult to see the progress towards consensus. Maybe that's just
 > because I'm too used to mailing lists :-)

Please, let's not start by privileging any particular type of channel
in this discussion.  I know what I like, but it's far more important
to have a single place to refer to past discussion IMO.  It's bad
enough with python-ideas and python-dev.

Maybe this fragmentation is OK in the long run, but at least while the
Steering Council is shaking down (say, until release of 3.9?), the
Council should consider anointing two archived "channels of record",
one for private deliberations of the Council itself (for the sake of
future members), and one for PEP discussions.

Of course if the SC chooses Discourse for the PEP channel, people
*will* discuss PEPs on Python-Dev and IRL.  The point is "no fair
pointing people to *other* channels for reference".  If you want to
make a public argument, make it in the proper place.  Everything else
is effectively private.  If you want to refer to that in the public
discussion, read it into the public record.

The stricture for the Council deliberation channel is different, since
I expect the archives would be private to Council members: if you came
into this discussion in the middle, what conversations would you want
to be able to review?

While I'm here, is there a place where general Pythonistas can bring
matters to the attention of the Council?

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] Consolidating channel of record [was: 581 (Using GitHub issues for CPython) is accepted]

2019-05-15 Thread Chris Barker - NOAA Federal via Python-Dev
Frankly, multiple long meandering threads in s single mailing list are
not s very good archive either.

Ideally, the PEP is updated with a summary of the issues discussed as
the discussion unfolds.

(And links to the main discussion threads?)

It founds like that didn’t happen in this case, but it’s not
necessarily too late.

As the community seems to be moving to a wider variety of fora, this
will become all the more critical.

- CHB

> On May 15, 2019, at 1:09 PM, Stephen J. Turnbull 
>  wrote:
>
> Stripping the list of addressees, since I'm pretty sure all the
> people who will *make* the decision read Python-Dev regularly, except
> perhaps Carol.
>
> Paul Moore writes:
>
>> Thanks for all of these. I appreciate the time you took locating them
>> for me. But I do have to say that I still can't really follow any
>> useful "thread of discussion" - it all seems very fragmented, and it's
>> difficult to see the progress towards consensus. Maybe that's just
>> because I'm too used to mailing lists :-)
>
> Please, let's not start by privileging any particular type of channel
> in this discussion.  I know what I like, but it's far more important
> to have a single place to refer to past discussion IMO.  It's bad
> enough with python-ideas and python-dev.
>
> Maybe this fragmentation is OK in the long run, but at least while the
> Steering Council is shaking down (say, until release of 3.9?), the
> Council should consider anointing two archived "channels of record",
> one for private deliberations of the Council itself (for the sake of
> future members), and one for PEP discussions.
>
> Of course if the SC chooses Discourse for the PEP channel, people
> *will* discuss PEPs on Python-Dev and IRL.  The point is "no fair
> pointing people to *other* channels for reference".  If you want to
> make a public argument, make it in the proper place.  Everything else
> is effectively private.  If you want to refer to that in the public
> discussion, read it into the public record.
>
> The stricture for the Council deliberation channel is different, since
> I expect the archives would be private to Council members: if you came
> into this discussion in the middle, what conversations would you want
> to be able to review?
>
> While I'm here, is there a place where general Pythonistas can bring
> matters to the attention of the Council?
>
> 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/chris.barker%40noaa.gov
___
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] PEP 581 (Using GitHub issues for CPython) is accepted

2019-05-15 Thread Victor Stinner
Le mer. 15 mai 2019 à 20:46, Guido van Rossum  a écrit :
> But trust me that the SC didn't take this decision lightly. It was unanimous, 
> and we have all thought about this a great deal (and listened to long 
> arguments pro and con). It's also impossible to satisfy everyone -- some 
> people find GitHub unacceptable (I've heard about 1-2 people who refused to 
> create GitHub accounts), but others find bpo unusable (the need to have a bpo 
> account in order to accept the CLA has been brought up repeatedly).

Around me, many people told me that they were awaiting for the PEP 581
to be accepted,. They are now *very kind* that Python issues are
moving to GitHub.

Honestly, I don't understand why people are excited by bug tracker,
for me it's not the most exciting part of development :-) But it seems
like many people were unhappy with Roundup.

At least, I can say that I'm not a big fan of it's UI (maybe too
complex, too many fields) compared to GitHub. I can also understand
that it's annoying for contributor to have to create 2 separated
accounts (bugs.python.org and GitHub) and link them *carefully*
(mistakes are common, you can see that when a contributor waits for
the "CLA signed" label). Sometimes, they are some glitches with
bugs.python.org <=> GitHub integration: some notifications take longer
30 sec or simply never happen.

I understand that GitHub is better to *report* bugs (and maybe to
comment an issue), but maybe worse for bug triage, and that we want to
make sure that it's easier to contribute to Python for "regular
contributors".

I also know that GitHub isn't perfect and that it will take time to
build a new efficient workflow on top of GitHub.


> A successful migration will take a lot of work, and PEP 588 is where we keep 
> track of tasks to be accomplished. (There are more that haven't made it to 
> that PEP, e.g. the mechanics of the actual move.) We're also hoping to get 
> professional help managing the migration so that not everything relies on 
> volunteers.

That would be great! The migration of the code took something like 2
years and it was a little bit painful for everybody at the beginning.
Having someone paid for that would make the migration shorter and
maybe also smoother.

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] Consolidating channel of record [was: 581 (Using GitHub issues for CPython) is accepted]

2019-05-15 Thread Brett Cannon
On Wed, May 15, 2019 at 1:10 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

[SNIP]


>
> While I'm here, is there a place where general Pythonistas can bring
> matters to the attention of the Council?
>

https://github.com/python/steering-council is where we're asking people to
ask stuff so it's recorded in a central location that's publicly visible.

-Brett


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


[Python-Dev] Python Language Summit 2019 blog posts

2019-05-15 Thread Mariatta
If you have FOMO (fear of missing out) of Python Language Summit 2019,
worry no more.

We invited A. Jesse Jiryu Davis to cover for the language summit, and the
blog posts are starting to appear in The PSF's official blog.

Starts here:
http://pyfound.blogspot.com/2019/05/the-2019-python-language-summit.html

More links will be added as they become available.

Currently available posts:

- Russell Keith-Magee: Python On Other Platforms
https://pyfound.blogspot.com/2019/05/russell-keith-magee-python-on-other.html

- Paul Ganssle: Time Zones In The Standard Library
https://pyfound.blogspot.com/2019/05/paul-ganssle-time-zones-in-standard.html

Thank you Jesse for writing up these posts, and thanks to all language
summit presenters and attendees.

ᐧ
___
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] Consolidating channel of record [was: 581 (Using GitHub issues for CPython) is accepted]

2019-05-15 Thread Paul Moore
On Wed, 15 May 2019 at 21:34, Chris Barker - NOAA Federal via
Python-Dev  wrote:
>
> Frankly, multiple long meandering threads in s single mailing list are
> not s very good archive either.

They aren't, I agree. But in my view, they constitute the *source
material* that the summaries in the PEP should be based on. No-one
should need to read the archives if they just want to know the points
being made. But for someone who wonders how a particular conclusion
was reached, having a single archive of record (to use Stephen's
phrase) makes sense - certainly people *can* search multiple sources,
but we should be trying to be transparent, and not making it too hard
to research the background of a decision is part of that.

> Ideally, the PEP is updated with a summary of the issues discussed as
> the discussion unfolds.

I'm not sure that's just "ideally" - one of the key purposes of a PEP
should be to summarise the discussions.

> (And links to the main discussion threads?)

That's nice to have, yes.

> It founds like that didn’t happen in this case, but it’s not
> necessarily too late.

Definitely. In fact, I doubt there's much of any real interest that
needs to be referenced (workflow debates are not the most interesting
reading, in my experience :-))

> As the community seems to be moving to a wider variety of fora, this
> will become all the more critical.

I completely agree here.

> On May 15, 2019, at 1:09 PM, Stephen J. Turnbull 
>  wrote:

> > Please, let's not start by privileging any particular type of channel
> > in this discussion.  I know what I like, but it's far more important
> > to have a single place to refer to past discussion IMO.  It's bad
> > enough with python-ideas and python-dev.

100% agree. This shouldn't be about whether any particular channel is
"better" or "worse" than any other. It's just about not having the
original content of the discussions that feed into an accepted PEP be
scattered too widely.

> > The stricture for the Council deliberation channel is different, since
> > I expect the archives would be private to Council members: if you came
> > into this discussion in the middle, what conversations would you want
> > to be able to review?

In theory, PEP 13 says that the council should look for consensus
rather than making decisions on their own. Ideally, the council's
private deliberations should be of little interest to anyone else,
because either (a) the consensus should be clearly visible from the
public record of the debate, or (b) the public record should show that
the discussion was getting nowhere, and the council had to make the
final decision (at which point, the community has effectively given up
the right to argue about why the council chose what they did).

The reason the decision on PEP 581 started me thinking about this was
precisely because I hadn't seen any signs of that consensus or of a
stalled discussion. Maybe I wasn't looking in the right places, but I
*thought* I was following the majority of PEP-related discussions (at
least skimming them). So I was somewhat startled to see a formal
decision come with what felt like no real warning.

Paul
___
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] Python Language Summit 2019 blog posts

2019-05-15 Thread Terry Reedy

On 5/15/2019 6:06 PM, Mariatta wrote:
If you have FOMO (fear of missing out) of Python Language Summit 2019, 
worry no more.


We invited A. Jesse Jiryu Davis to cover for the language summit, and 
the blog posts are starting to appear in The PSF's official blog.


Starts here: 
http://pyfound.blogspot.com/2019/05/the-2019-python-language-summit.html


More links will be added as they become available.

Currently available posts:

- Russell Keith-Magee: Python On Other Platforms
https://pyfound.blogspot.com/2019/05/russell-keith-magee-python-on-other.html

- Paul Ganssle: Time Zones In The Standard Library
https://pyfound.blogspot.com/2019/05/paul-ganssle-time-zones-in-standard.html

Thank you Jesse for writing up these posts, and thanks to all language 
summit presenters and attendees.


These appear on the Python Planet list, mirrored at news.gmane.org as
gwene.org.python.planet



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


[Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 3rd version

2019-05-15 Thread Victor Stinner
Hi,

Thanks to the constructive discussions, I enhanced my PEP 587. I don't
plan any further change, the PEP is now ready to review (and maybe
even for pronouncement, hi Thomas! :-)).

The Rationale now better explains all challenges and the complexity of
the Python Initialization Configuration.

The "Isolate Python" section is a short guide explaining how configure
Python to embed it into an application.

The "Path Configuration" section elaborates the most interesting part
of the configuration: configure where Python looks for modules
(sys.path). I added PyWideStringList_Insert() to allow to prepend a
path in module_search_paths.

The "Python Issues" section give a long list of issues solved directly
or indirectly by this PEP.

I'm open for bikeshedding on PyConfig fields names and added functions
names ;-) I hesitate for "use_module_search_paths": maybe
"module_search_paths_set" is a better name, as in "is
module_search_paths set?". The purpose of this field is to allow to
have an empty sys.path (ask PyConfig_Read() to not override it). IMHO
an empty sys.path makes sense for some specific use cases, like
executing Pyhon code without any external module.

My PEP 587 proposes better names: Py_FrozenFlag becomes
PyConfig.pathconfig_warnings and Py_DebugFlag becomes
PyConfig.parser_debug. I also avoided double negation. For example,
Py_DontWriteBytecodeFlag becomes write_bytecode.

Changes between version 3 and version 2:

* PyConfig: Add configure_c_stdio and parse_argv; rename _frozen to
pathconfig_warnings.
* Rename functions using bytes strings and wide strings. For example,
Py_PreInitializeFromWideArgs() becomes Py_PreInitializeFromArgs(), and
PyConfig_SetArgv() becomes PyConfig_SetBytesArgv().
* Add PyWideStringList_Insert() function.
* New "Path configuration", "Isolate Python", "Python Issues" and
"Version History" sections.
* PyConfig_SetString() and PyConfig_SetBytesString() now requires the
configuration as the first argument.
* Rename Py_UnixMain() to Py_BytesMain()


HTML version:
https://www.python.org/dev/peps/pep-0587/

Full PEP text below.

I know that the PEP is long, but well, it's a complex topic, and I
chose to add many examples to make the API easier to understand.

Victor

---

PEP: 587
Title: Python Initialization Configuration
Author: Victor Stinner , Nick Coghlan 
BDFL-Delegate: Thomas Wouters 
Discussions-To: python-dev@python.org
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 27-Mar-2019
Python-Version: 3.8

Abstract


Add a new C API to configure the Python Initialization providing finer
control on the whole configuration and better error reporting.

It becomes possible to read the configuration and modify it before it is
applied. It also becomes possible to completely override how Python
computes the module search paths (``sys.path``).

Building a customized Python which behaves as regular Python becomes
easier using the new ``Py_RunMain()`` function. Moreover, command line
arguments passed to ``PyConfig.argv`` are now parsed as the regular
Python parses command line options, and ``PyConfig.xoptions`` are
handled as ``-X opt`` command line options.

This extracts a subset of the API design from the PEP 432 development and
refactoring work that is now considered sufficiently stable to make public
(allowing 3rd party embedding applications access to the same configuration
APIs that the native CPython CLI is now using).


Rationale
=

Python is highly configurable but its configuration evolved organically.
The initialization configuration is scattered all around the code using
different ways to set them: global configuration variables (ex:
``Py_IsolatedFlag``), environment variables (ex: ``PYTHONPATH``),
command line arguments (ex: ``-b``), configuration files (ex:
``pyvenv.cfg``), function calls (ex: ``Py_SetProgramName()``). A
straightforward and reliable way to configure Python is needed.

Some configuration parameters are not accessible from the C API, or not
easily. For example, there is no API to override the default values of
``sys.executable``.

Some options like ``PYTHONPATH`` can only be set using an environment
variable which has a side effect on Python child processes.

Some options also depends on other options: see `Priority and Rules`_.
Python 3.7 API does not provide a consistent view of the overall
configuration.

The C API of Python 3.7 Initialization takes ``wchar_t*`` strings as
input whereas the Python filesystem encoding is set during the
initialization which can lead to mojibake.

Python 3.7 APIs like ``Py_Initialize()`` aborts the process on memory
allocation failure which is not convenient when Python is embedded.
Moreover, ``Py_Main()`` could exit directly the process rather than
returning an exit code. Proposed new API reports the error or exit code
to the caller which can decide how to handle it.

Implementing the PEP 540 (UTF-8 Mode) and the new ``-X dev`` correctly
was almost impossible in Python 3.6. The code ba

[Python-Dev] bpo-36829: Add sys.unraisablehook()

2019-05-15 Thread Victor Stinner
Hi,

I recently modified Python 3.8 to start logging I/O error in io
destructors when using the development mode (-X dev) or when Python is
built in debug mode. This change allows to debug bpo-18748 very
strange crash in PyThread_exit_thread(), when a thread closes an
arbitrary file descriptor by mistake.

The problem is that exceptions raised in a destructor cannot be passed
to the current function call: the exception is logged into sys.stderr
with a message like "Exception ignored in: ...". It's easy to miss
such message in stderr.

Thomas Grainger opened 36829 to propose to add -X abortunraisable
command line option: abort immediately the current process (by calling
Py_FatalError()) at the first PyErr_WriteUnraisable() call. Thomas had
like a way to easily detect these in CI. I'm not satisfied by his
proposal, since it only gives little control to the user on how
"unraisable exceptions" are handled: the process dies, that's all.

https://bugs.python.org/issue36829

I proposed a different approach: add a new sys.unraisablehook hook
which is called to handle an "unraisable exception". To handle them
differently, replace the hook. For example, I wrote a custom hook to
log these exceptions into a file (the output on the Python test suite
is interesting!). It also becomes trivial to reimplement Thomas's idea
(kill the process):

import signal
def hook(unraisable): signal.raise_signal(signal.SIGABRT)
sys.unraisablehook = hook

I plan to merge my implementation soon, are you fine with that?

https://github.com/python/cpython/pull/13187

--

The first implementation of my API used sys.unraisablehook(exc_type,
exc_value, exc_tb, obj). The problem is that Serhiy Storchaka asked me
to add a new error message field which breaks the API: the API is not
future-proof.

I modified my API to create an object to pack arguments. The new API
becomes sys.unraisablehook(unraisable) where unraisable has 4 fields:
exc_type, exc_value, exc_tb, obj. This API is now future-proof: adding
a new field will not break existing custom hooks!

By the way, I like this idea of adding an optional error message, and
I plan to implement it once sys.unraisablehook is merged ;-) I already
implemented it previously, but I reverted my changes to make the PR
simpler to review.


Extract of the documentation:

"""
Add new :func:`sys.unraisablehook` function which can be overriden to control
how "unraisable exceptions" are handled. It is called when an exception has
occurred but there is no way for Python to handle it. For example, when a
destructor raises an exception or during garbage collection
(:func:`gc.collect`).
"""

My implementation has a limitation: if PyErr_WriteUnraisable() is
called after the Python finalization cleared sys attributes (almost
the last function call of Py_Finalize), the default hook is called
instead of the custom hook. In this case, sys.stderr is None and so
the default hook does nothing.

These late calls to PyErr_WriteUnraisable() cannot be catched with my
approached, whereas Thomas Grainger's command line option "-X
abortunraisable" allows that.

My concern with Thomas's approach is that if the problem is killed
with SIGABRT by such late PyErr_WriteUnraisable(), a low-level
debugger like gdb is needed to investigate the crash, since Python is
already finalized and so cannot be used to investigate.

I prefer to allow arbitrary hook with the limitation, rather than
always kill the process with SIGABRT at the first
PyErr_WriteUnraisable() and require to use a low-level debugger.

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] bpo-36829: Add sys.unraisablehook()

2019-05-15 Thread Nathaniel Smith
On Wed, May 15, 2019 at 6:25 PM Victor Stinner  wrote:
> I proposed a different approach: add a new sys.unraisablehook hook
> which is called to handle an "unraisable exception". To handle them
> differently, replace the hook. For example, I wrote a custom hook to
> log these exceptions into a file (the output on the Python test suite
> is interesting!). It also becomes trivial to reimplement Thomas's idea
> (kill the process):

What happens if the hook raises an exception?

-n

-- 
Nathaniel J. Smith -- https://vorpus.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] RFC: PEP 587 "Python Initialization Configuration": 3rd version

2019-05-15 Thread Gregory Szorc
On 5/15/2019 4:10 PM, Victor Stinner wrote:
> Hi,
> 
> Thanks to the constructive discussions, I enhanced my PEP 587. I don't
> plan any further change, the PEP is now ready to review (and maybe
> even for pronouncement, hi Thomas! :-)).
> 
> The Rationale now better explains all challenges and the complexity of
> the Python Initialization Configuration.
> 
> The "Isolate Python" section is a short guide explaining how configure
> Python to embed it into an application.
> 
> The "Path Configuration" section elaborates the most interesting part
> of the configuration: configure where Python looks for modules
> (sys.path). I added PyWideStringList_Insert() to allow to prepend a
> path in module_search_paths.
> 
> The "Python Issues" section give a long list of issues solved directly
> or indirectly by this PEP.
> 
> I'm open for bikeshedding on PyConfig fields names and added functions
> names ;-) I hesitate for "use_module_search_paths": maybe
> "module_search_paths_set" is a better name, as in "is
> module_search_paths set?". The purpose of this field is to allow to
> have an empty sys.path (ask PyConfig_Read() to not override it). IMHO
> an empty sys.path makes sense for some specific use cases, like
> executing Pyhon code without any external module.
> 
> My PEP 587 proposes better names: Py_FrozenFlag becomes
> PyConfig.pathconfig_warnings and Py_DebugFlag becomes
> PyConfig.parser_debug. I also avoided double negation. For example,
> Py_DontWriteBytecodeFlag becomes write_bytecode.
> 
> Changes between version 3 and version 2:
> 
> * PyConfig: Add configure_c_stdio and parse_argv; rename _frozen to
> pathconfig_warnings.
> * Rename functions using bytes strings and wide strings. For example,
> Py_PreInitializeFromWideArgs() becomes Py_PreInitializeFromArgs(), and
> PyConfig_SetArgv() becomes PyConfig_SetBytesArgv().
> * Add PyWideStringList_Insert() function.
> * New "Path configuration", "Isolate Python", "Python Issues" and
> "Version History" sections.
> * PyConfig_SetString() and PyConfig_SetBytesString() now requires the
> configuration as the first argument.
> * Rename Py_UnixMain() to Py_BytesMain()
> 
> 
> HTML version:
> https://www.python.org/dev/peps/pep-0587/
> 
> Full PEP text below.
> 
> I know that the PEP is long, but well, it's a complex topic, and I
> chose to add many examples to make the API easier to understand.

I saw your request for feedback on Twitter a few days back and found
this thread.

This PEP is of interest to me because I'm the maintainer of PyOxidizer -
a project for creating single file executables embedding Python. As part
of hacking on PyOxidizer, I will admit to grumbling about the current
state of the configuration and initialization mechanisms. The reliance
on global variables and the haphazard way in which you must call certain
functions before others was definitely a bit frustrating to deal with.

I don't want to wade into too much bikeshedding in my review. I'll let
the professionals deal with things like naming :) Also, I haven't read
previous posts about this PEP. Apologies if my comments bring up old topics.

Let's get on with the review...

My most important piece of feedback is: thank you for tackling this!
Your work to shore up the inner workings of interpreter state and
management is a big deal on multiple dimensions. I send my sincere
gratitude.

Overall, I'm very happy with the state of the proposal. Better than what
we currently have on nearly every dimension. When reading my feedback,
please keep in mind that I'm in like 95% agreement with the proposal as is.

The following paragraphs detail points of feedback.

PyPreConfig_INIT and PyConfig_INIT as macros that return a struct feel
weird to me. Specifically, the `PyPreConfig preconfig =
PyPreConfig_INIT;` pattern doesn't feel right. I'm sort of OK with these
being implemented as macros. But I think they should look like function
calls so the door is open to converting them to function calls in the
future. An argument to make them actual function calls today is to
facilitate better FFI interop. As it stands, non-C/C++ bindings to the
API will need to reimplement the macro's logic. That might be simple
today. But who knows what complexity may be added in years ahead. An
opaque function implementation future proofs the API.

PyPreConfig.allocator being a char* seems a bit weird. Does this imply
having to use strcmp() to determine which allocator to use? Perhaps the
allocator setting should be an int mapping to a constant instead?
Relatedly, how are custom allocators registered? e.g. from Rust, I want
to use Rust's allocator. How would I do that in this API? Do I still
need to call PyMem_SetAllocator()? I thought a point of this proposal
was to consolidate per-interpreter config settings?

I'm a little confused about the pre-initialization functions that take
command arguments. Is this intended to only be used for parsing the
arguments that `python` recognizes? Presumably a custom application
embedding 

Re: [Python-Dev] bpo-36829: Add sys.unraisablehook()

2019-05-15 Thread Serhiy Storchaka

16.05.19 04:23, Victor Stinner пише:

The first implementation of my API used sys.unraisablehook(exc_type,
exc_value, exc_tb, obj). The problem is that Serhiy Storchaka asked me
to add a new error message field which breaks the API: the API is not
future-proof.

I modified my API to create an object to pack arguments. The new API
becomes sys.unraisablehook(unraisable) where unraisable has 4 fields:
exc_type, exc_value, exc_tb, obj. This API is now future-proof: adding
a new field will not break existing custom hooks!


I prefer the former design, when the hook takes 5 arguments: exc_type, 
exc_value, exc_tb, obj and msg. Any additional human readable 
information can be encoded in msg, and machine readable information can 
be encoded in msg or obj. Currently we have no plans for adding more 
details, and I do not think that we will need to do this in future. 
Packing arguments into a single extendable object just complicates the 
code and increases the chance of raising an exception or crashing.


Even obj and msg could be merged into a single object, and the hook 
could check whether it is a string or callable. But passing them as 
separate arguments is fine to me, I just think that no more complication 
is necessary.


___
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