Re: [Python-Dev] The future of the wchar_t cache
22.10.18 23:41, Steve Dower пише: That said, I didn't remove the wchar_t cache (though I tried some tricks to avoid it), so it's possible that once that's gone we'll see an avoidable regression here, but on its own this doesn't contribute much. Could you please test PR 2599 on Windows? It makes PyUnicode_AsWideChar() and PyUnicode_AsWideCharString() not filling the wchar_t cache. If there is a significant regression in any benchmark or small regressions in several benchmarks we can consider to continue to fill the cache in these function and to preserve the cache in future. Otherwise I'll merge the PR as is. https://github.com/python/cpython/pull/2599 ___ Python-Dev mailing list [email protected] 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 Governance Proposals
Hi,
Last July, Guido van Rossum decided to resign from his role of BDFL.
Python core developers decided to design a new governance/organization
for Python. 6 governance PEPs have been proposed. It has been decided
that discussions are reserved to core developers (everyone can read,
but only core devs can write), since the governance will mostly impact
the life of core developers. I'm writing this email to python-dev to
keep you aware that something is happening :-)
Core developers (of the GitHub team) will vote to decide the new
Python governance in 3 weeks:
"The vote will happen in a 2-week-long window from November 16 2018 to
November 30 (Anywhere-on-Earth)."
See PEP 8001: Python Governance Voting Process
https://www.python.org/dev/peps/pep-8001/
Below are links to the governance PEPs, their abstract, and link to
the Discourse discussions.
Note: a Discourse instance is experimented at discuss.python.org to
maybe replace python-{ideas,dev,committers} mailing lists. See the
"Discourse Feedback" category at https://discuss.python.org/ :-)
(1) PEP 8010: The BDFL Governance Model
https://www.python.org/dev/peps/pep-8010
Abstract:
"""
This PEP proposes a continuation of the singular project leader model,
euphemistically called the Benevolent Dictator For Life (BDFL) model
of Python governance, to be henceforth called in this PEP the Gracious
Umpire Influencing Decisions Officer (GUIDO). This change in name
reflects both the expanded view of the GUIDO as final arbiter for the
Python language decision making process in consultation with the wider
development community, and the recognition that "for life" while
perhaps aspirational, is not necessarily in the best interest of the
well-being of either the language or the GUIDO themselves.
This PEP describes:
* The rationale for maintaining the singular leader model
* The process for how the GUIDO will be selected, elected, retained,
recalled, and succeeded;
* The roles of the GUIDO in the Python language evolution process;
* The term length of service;
* The relationship of the GUIDO with a Council of Pythonistas (CoP)
that advise the GUIDO on technical matters;
* The size, election, and roles of the CoP;
* The decision delegation process;
* Any changes to the PEP process to fit the new governance model;
This PEP does not name a new BDFL. Should this model be adopted, it
will be codified in PEP 13 along with the names of all officeholders
described in this PEP, as voted on per the guidelines in PEP 8001.
"""
Discussion:
https://discuss.python.org/t/pep-8010-the-singular-leader/188
(2) PEP 8011: Python Governance Model Lead by Trio of Pythonistas
https://www.python.org/dev/peps/pep-8011
Abstract:
"""
This PEP proposes a governance model for the Core Python development
community, led by a trio of equally authoritative leaders. The Trio of
Pythonistas (ToP, or simply Trio) is tasked with making final
decisions for the language. It differs from PEP 8010 by specifically
not proposing a central singular leader, but instead a group of three
people as the leaders.
This PEP also proposes a formation of specialized workgroups to assist
the leadership trio in making decisions.
This PEP does not name the members of the Trio. Should this model be
adopted, it will be codified in PEP 13 along with the names of all
officeholders described in this PEP.
This PEP describes:
* The role and responsibilities of the Trio
* Guidelines of how trio members should be formed
* Reasoning of the group of three, instead of a singular leader
* Role and responsibilities of Python core developers to the trio
* Sustainability considerations
* Diversity and inclusivity considerations
"""
Discussion:
https://discuss.python.org/t/pep-8011-leadership-by-trio-of-pythonistas-top-or-simply-trio/199
(3) PEP 8012: The Community Governance Model
https://www.python.org/dev/peps/pep-8012/
Abstract:
"""
This PEP proposes a new model of Python governance based on consensus
and voting by the Python community. This model relies on workgroups to
carry out the governance of the Python language. This governance model
works without the role of a centralized singular leader or a governing
council.
It describes how, when, and why votes are conducted for decisions
affecting the Python language. It also describes the criteria for
voting eligibility.
Should this model be adopted, it will be codified in PEP 13.
This model can be affectionately called "The Least Worst Governance
Model" by its property that while far from ideal, it's still the most
robust one compared to the others. Since avoiding issues inherent to
the other models is a paramount feature of the Community Governance
Model, we start the discussion a bit unusually: by rejecting the other
models.
"""
Discussion:
https://discuss.python.org/t/pep-8012-the-community-model/156
(4) PEP 8013: The External Council Governance Model
https://www.python.org/dev/peps/pep-8013/
and
https://mail.python.org/pipermail/python-committers/2018-Septemb
Re: [Python-Dev] The future of the wchar_t cache
On Tue, 23 Oct 2018 at 00:50, Steve Dower wrote: > > On 22Oct2018 1007, Serhiy Storchaka wrote: > > 22.10.18 16:24, Steve Dower пише: > >> Yes, that's true. But "should reduce ... footprint" is also an > >> optimisation that deserves a benchmark by that standard. Also, I'm > >> proposing keeping the 'kind' as UCS-2 when the string is created from > >> UCS-2 data that is likely to be used as UCS-2. We would not create the > >> UCS-1 version in this case, so it's not the same as prefilling the > >> cache, but it would cost a bit of memory in exchange for CPU. If > >> slicing and concatentation between matching kinds also preserved the > >> kind, a lot of path handling code could avoid back-and-forth conversions. > > > > Oh, I afraid this will complicate the whole code of unicodeobject.c (and > > several other files) a much and can introduce a lot of subtle bugs. > > > > For example, when you search a UCS2 string in a UCS1 string, the current > > code returns the result fast, because a UCS1 string can't contain codes > > > 0xff, and a UCS2 string should contain codes > 0xff. And there are > > many such assumptions. > > That doesn't change though, as we're only ever expanding the range. So > searching a UCS2 string in a UCS2 string that doesn't contain any actual > UCS2 characters is the only case that would be affected, and whether > that case occurs more than the UCS2->UCS1->UCS2 conversion case is > something we can measure (but I'd be surprised if substring searches > occur more frequently than OS conversions). > > Currently, unicode_compare_eq exits early when the kinds do not match, > and that would be a problem (but is also easily fixable). But other > string operations already handle mismatched kinds. If you did allow for denormalised UCS-2 strings, you'd probably want some kind of flag on the instance to indicate that the real kind was 8-bit. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 Governance Proposals
+1 (for what it's worth) to any proposal which includes one (or more)
GUIDOs :)
S.
On Tue, Oct 23, 2018 at 11:57 AM Victor Stinner wrote:
> Hi,
>
> Last July, Guido van Rossum decided to resign from his role of BDFL.
> Python core developers decided to design a new governance/organization
> for Python. 6 governance PEPs have been proposed. It has been decided
> that discussions are reserved to core developers (everyone can read,
> but only core devs can write), since the governance will mostly impact
> the life of core developers. I'm writing this email to python-dev to
> keep you aware that something is happening :-)
>
> Core developers (of the GitHub team) will vote to decide the new
> Python governance in 3 weeks:
> "The vote will happen in a 2-week-long window from November 16 2018 to
> November 30 (Anywhere-on-Earth)."
>
> See PEP 8001: Python Governance Voting Process
> https://www.python.org/dev/peps/pep-8001/
>
>
> Below are links to the governance PEPs, their abstract, and link to
> the Discourse discussions.
>
> Note: a Discourse instance is experimented at discuss.python.org to
> maybe replace python-{ideas,dev,committers} mailing lists. See the
> "Discourse Feedback" category at https://discuss.python.org/ :-)
>
>
> (1) PEP 8010: The BDFL Governance Model
> https://www.python.org/dev/peps/pep-8010
>
> Abstract:
> """
> This PEP proposes a continuation of the singular project leader model,
> euphemistically called the Benevolent Dictator For Life (BDFL) model
> of Python governance, to be henceforth called in this PEP the Gracious
> Umpire Influencing Decisions Officer (GUIDO). This change in name
> reflects both the expanded view of the GUIDO as final arbiter for the
> Python language decision making process in consultation with the wider
> development community, and the recognition that "for life" while
> perhaps aspirational, is not necessarily in the best interest of the
> well-being of either the language or the GUIDO themselves.
>
> This PEP describes:
>
> * The rationale for maintaining the singular leader model
> * The process for how the GUIDO will be selected, elected, retained,
> recalled, and succeeded;
> * The roles of the GUIDO in the Python language evolution process;
> * The term length of service;
> * The relationship of the GUIDO with a Council of Pythonistas (CoP)
> that advise the GUIDO on technical matters;
> * The size, election, and roles of the CoP;
> * The decision delegation process;
> * Any changes to the PEP process to fit the new governance model;
>
> This PEP does not name a new BDFL. Should this model be adopted, it
> will be codified in PEP 13 along with the names of all officeholders
> described in this PEP, as voted on per the guidelines in PEP 8001.
> """
>
> Discussion:
> https://discuss.python.org/t/pep-8010-the-singular-leader/188
>
>
> (2) PEP 8011: Python Governance Model Lead by Trio of Pythonistas
> https://www.python.org/dev/peps/pep-8011
>
> Abstract:
> """
> This PEP proposes a governance model for the Core Python development
> community, led by a trio of equally authoritative leaders. The Trio of
> Pythonistas (ToP, or simply Trio) is tasked with making final
> decisions for the language. It differs from PEP 8010 by specifically
> not proposing a central singular leader, but instead a group of three
> people as the leaders.
>
> This PEP also proposes a formation of specialized workgroups to assist
> the leadership trio in making decisions.
>
> This PEP does not name the members of the Trio. Should this model be
> adopted, it will be codified in PEP 13 along with the names of all
> officeholders described in this PEP.
>
> This PEP describes:
>
> * The role and responsibilities of the Trio
> * Guidelines of how trio members should be formed
> * Reasoning of the group of three, instead of a singular leader
> * Role and responsibilities of Python core developers to the trio
> * Sustainability considerations
> * Diversity and inclusivity considerations
> """
>
> Discussion:
>
> https://discuss.python.org/t/pep-8011-leadership-by-trio-of-pythonistas-top-or-simply-trio/199
>
>
> (3) PEP 8012: The Community Governance Model
> https://www.python.org/dev/peps/pep-8012/
>
> Abstract:
> """
> This PEP proposes a new model of Python governance based on consensus
> and voting by the Python community. This model relies on workgroups to
> carry out the governance of the Python language. This governance model
> works without the role of a centralized singular leader or a governing
> council.
>
> It describes how, when, and why votes are conducted for decisions
> affecting the Python language. It also describes the criteria for
> voting eligibility.
>
> Should this model be adopted, it will be codified in PEP 13.
>
> This model can be affectionately called "The Least Worst Governance
> Model" by its property that while far from ideal, it's still the most
> robust one compared to the others. Since avoiding issues inherent to
> the other models is a paramount fea
[Python-Dev] Re: Python Language Governance Proposals
Are there any list of candidates? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Python Language Governance Proposals
Hi, Le mar. 23 oct. 2018 à 18:26, eamanu15 a écrit : > Are there any list of candidates? No PEP proposes directly candidates. The process to nominate candidates is part of discussed PEPs. So first core developers must vote for the governance PEP, and then a new process will be organized to select candidates and implement the new governance. Not all PEPs propose to replace the old BDFL with a new single BDFL. One PEP proposes 3 BDFL, some PEP don't propose any BDFL, etc. I will not risk me to summarize the six PEPs here, please read them :-) Victor ___ Python-Dev mailing list [email protected] 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 Governance Proposals
What is the timeframe for the installation of the new governance? In other words, when will it be possible to review PEPs? ___ Python-Dev mailing list [email protected] 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 os.system in favor of subprocess?
Good morning/afternoon/evening/night ;-) In the documentation of os.system [1], there is this paragraph, where we suggest to use subprocess instead of os.system. """ The subprocess module provides more powerful facilities for spawning new processes and retrieving their results; using that module is preferable to using this function. See the Replacing Older Functions with the subprocess Module section in the subprocess documentation for some helpful recipes. """ But I have found some references (between 15 and 23 (if we include setup.py)) of os.system. Do we need to keep the code like that or could we start to use subprocess for these "references" because it is preferable? If you think we could move to subprocess, I would like to open an issue and try to fix it. 1. Add the 'deprecated' directive in the doc 2. Use subprocess for these references What is your opinion? Thank you, Stéphane [1] https://docs.python.org/3.8/library/os.html?highlight=os%20system#os.system -- Stéphane Wirtel - https://wirtel.be - @matrixise ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
