Re: [python-committers] Codecov and PR
> While I use code coverage to improve automated unittesting, I am opposed to > turning a usable but limited and sometime faulty tool into a blind robotic > master that blocks improvements. The prospect of this being done has > discouraged me from learning the new system. (More on 'faulty tool' later.) > > The temptation to write artificial tests to satisfy an artificial goal is > real. Doing so can eat valuable time better used for something else. For > instance: > > def meth(self, arg): > mod.inst.meth(arg, True, ob=self, kw='cut') > > Mocking mod.class.meth, calling meth, and checking that the mock is called > will satisfy the robot, but does not contribute much to the goal of > providing a language that people can use to solve problems. > > Victor, can you explain 'tested indirectly' and perhaps give an example? > This is one examples I merged "untested line of code". https://github.com/python/cpython/pull/162/files#diff-0ad86c44e7866421ecaa5ad2c0edb0e2R552 +file_object = builtins.open(f, 'wb') +try: +self.initfp(file_object) +except: +file_object.close() +raise `self.initfp()` is very unlikely raise exceptions. But MemoryError, KeyboardInterrupt or other rare exceptions may be happen. Test didn't cover this except clause. But I merged it because: * this code is simple enough. * I can write test for it with mocking `self.initfp()` to raise exception. But such test code have significant maintenance cost. I don't think this except clause is important enough to maintain such code. If I remove the except clause, all lines are tested, but there is (very unlikely) leaking unclosed file. Which are "broken"? Coverage is very nice information to find code which should be tested, but not tested. But I don't think "all code should be tested". It may make hard to improve Python. So I agree with Victor and Terry. Regards, ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] New workflow - some questions
On Sat, Jul 29, 2017 at 7:30 AM, Mariatta Wijaya wrote: >> 1. Section 32.2 in the Git bootcamp section - is there any reason to >> use git@github URLs for the clones? I normally always use >> https://github.com URLs, as they work with my proxy at work. > > > I don't have any explanation other than Git bootcamp was initially written > based on my personal setup. > I cloned CPython using SSH, and that's what I wrote in the devguide :) > You can use HTTPS if that works for you. > Perhaps someone else can explain better the difference between cloning via > HTTPS and SSH. > I usually uses https for "read-only" remote. Sometimes, even I have commit rights, I use pull request from personal fork and I don't want to push directly. Of course, I can use https to push. But it requires some additional steps. So it prevent accidental push to "origin". I think there are no downside to use HTTPS for "read only" remotes. > >> I generally use "Compare and create pull request" >> from my clone's github page, as that seems simpler. > > > Note that the link is only visible within 30 minutes (or so) after you > pushed your branch to remote. > If you did not create the PR immediately after pushing, the link disappears. > In this case, the instructions in 32.10 will help (maybe?). > Can we assume that people will create their PR immediately? > Maybe an improvement is to mention the "Compare and create pull request", > and to do this immediately after pushing the branch. > > side-topic: Does anyone have some sort of script/git > alias/program/whatchamacallit that will open the PR page once we push to > remote? (similar to what cherry_picker does) That could be a time saver :) > I use Github's "hub" CLI. https://github.com/github/hub "hub pull-request" can be used to create pull request from terminal. "hub browse" can be used to open browser for current branch. Regards, ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Cherry picker bot deployed in CPython repo
Congrats! INADA Naoki On Wed, Sep 6, 2017 at 10:10 AM, Mariatta Wijaya wrote: > Hi, > > The cherry picker bot has just been deployed to CPython repo, codenamed > miss-islington. > > miss-islington made the very first backport PR for CPython and became a > first time GitHub contributor: https://github.com/python/cpython/pull/3369 > > GitHub repo: https://github.com/python/miss-islington > > What is this? > == > > As part of our workflow, quite often changes made on the master branch need > to be backported to the earlier versions. (for example: from master to 3.6 > and 2.7) > > Previously the backport has to be done manually by either a core developer > or the original PR author. > > With the bot, the backport PR is created automatically after the PR has been > merged. A core developer will need to review the backport PR. > > The issue was tracked in https://github.com/python/core-workflow/issues/8 > > How it works > == > > 1. If a PR needs to be backported to one of the maintenance branches, a core > developer should apply the "needs backport to X.Y" label. Do this **before** > you merge the PR. > > 2. Merge the PR > > 3. miss-islington will leave a comment on the PR, saying it is working on > backporting the PR. > > 4. If there's no merge conflict, the PR should be created momentarily. > > 5. Review the backport PR created by miss-islington and merge it when you're > ready. > > Merge Conflicts / Problems? > == > > In case of merge conflicts, or if a backport PR was not created within 2 > minutes, it likely failed and you should do the backport manually. > > Manual backport can be done using cherry_picker: > https://pypi.org/project/cherry-picker/ > > Older merged PRs not yet backported? > == > > At the moment, those need to be backported manually. > > Don't want PR to be backported by a bot? > > > My recommendation is to apply the "needs backport to X.Y" **after** the PR > has been merged. The label is still useful to remind ourselves that this PR > still needs backporting. > > Who is Miss Islington? > = > > I found out from Wikipedia that Miss Islington is the name of the witch in > Monty Python and The Holy Grail. > > miss-islington has not signed the CLA! > = > > A core dev can ignore the warning and merge the PR anyway. > > Thanks! > > > Mariatta Wijaya > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Let's give commit privileges to Nathaniel J. Smith
+1 -- INADA Naoki ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions?
0: I will use it if it's accepted, but I'm not sure it's merit is enough for changing how Python code looks. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposing Mark Shannon to be a core developer
+1 2018年5月15日(火) 6:55 Ivan Levkivskyi : > +1 > > Yes, I actually thought he is a core dev for ages :-) > Me too. > -- > Ivan > > > > On 14 May 2018 at 17:42, Eric Snow wrote: > >> +1 >> >> -eric >> >> On Mon, May 14, 2018 at 4:41 PM, Larry Hastings >> wrote: >> > >> > >> > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, >> writing >> > both the PEP and the implementation. This shipped in Python 3.3 and was >> > listed as one of the top features of that release as according to the >> > "What's New?" document. >> > >> > We've asked Mark in the past if he'd be interested in becoming a core >> > developer--and he actually said no. At the time he said he didn't like >> our >> > antiquated workflow. Now that we've switched to the git-based core dev >> > workflow, this objection is gone, and he's now interested in accepting >> the >> > commit bit and the responsibilities that it entails. >> > >> > I suspect you, my colleagues in CPython core development, will be >> surprised >> > at the current state of affairs. I'm expecting a load of "you mean Mark >> > *isn't* a core developer yet?" replies. >> > >> > >> > Submitted for your consideration, >> > >> > >> > /arry >> > >> > ___ >> > python-committers mailing list >> > [email protected] >> > https://mail.python.org/mailman/listinfo/python-committers >> > Code of Conduct: https://www.python.org/psf/codeofconduct/ >> > >> ___ >> python-committers mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-committers >> Code of Conduct: https://www.python.org/psf/codeofconduct/ >> > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Python 4.0 or Python 3.10?
For the record, Guido prefer 3.10 to 4.0, before he retired BDFL. https://python.zulipchat.com/#narrow/stream/116503-core/subject/rhel/near/124934902 Regards, -- INADA Naoki ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] OpenMandriva and Fedora abandoned Discourse for development discussions
Scala uses two discourse instances; users and contributors. https://www.scala-lang.org/community/ This is discourse for Scala contributors. https://contributors.scala-lang.org/ It looks discourse works fine for Scala team. -- Inada Naoki ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: [Python-checkins] remove a strange non-ASCII character in _iomodule.c (GH-17239)
I don't think we need to revive ^L once it is removed. The steering council decided there is no real "code owner". Codes are owned by everyone. On the other hand, ^L is very minor control character nowadays. Many new people use many new editors. I don't believe every common editors support ^L well. And even though editor supports it, people may be confused by it. If only few core developer likes ^L, why we need to add it even though it is removed by accident? What makes ^L more important than TAB? Regards, On Tue, Nov 19, 2019 at 3:52 AM Tal Einat wrote: > > On Mon, Nov 18, 2019 at 8:50 PM Eric V. Smith wrote: >> >> Replying to python-committers for visibility, although maybe python-dev >> would be better. >> >> That's not a "strange non-ASCII character"! That's a form feed >> (control-L), definitely defined by ASCII. >> >> There are plenty of these in the code. Some people (who won't be named, >> but match the regex "Barry") like them. I don't think we should start >> removing them. > > > Oh wow, I completely missed that! :blush: > > Terribly sorry, I'll revert the change. > > - Tal Einat > ___ > python-committers mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/MJ4GFBC72FGFX52Z7VDBJ4V2VURAWPHJ/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ -- Inada Naoki ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/JBEJZPBFKQVO52OVEWECQI3F4CP7SIMT/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Experimental isolated subinterpreters
I am moving home this week and do not have time to review. But I want to notice about the difference between --enable-X and --with-X. See https://autotools.io/autoconf/arguments.html Since isolated subinterpreter is not external dependency, "--enable" should be used here. (I know we already abuse "--with-lto".) Regards, On Thu, May 7, 2020 at 2:50 AM Victor Stinner wrote: > Hi, > > tl; dr I'm asking for your permission to merge the following PR :-) > > https://github.com/python/cpython/pull/19958 > > > In bpo-40514, I added a new > --with-experimental-isolated-subinterpreters configuration option. I > chose to use a very long option name and to not document it on > purpose: prevent users to use it "by mistake", without understanding > its purpose. The option is related to "per-interpreter GIL": > > https://bugs.python.org/issue40512 > > It's a practical solution to be able to experiment quickly > per-interpreter GIL without having to fix all issues at once. For > example, it disables Unicode interned strings which is unsafe with > multiple interpreters running in parallel. > > I added this #ifdef to encourage other core developers work on this > project, and let early adopters test this experimental feature to give > us their feedback. > > I hope that soon we will discover all places which need to be fixed, > so it will help to better estimate how much work is needed to finish > the implementation of per-interpreter GIL. > > Currently, the special build changes: > > * Per-interpreter GIL > * Store the current Python thread state in a TLS > * Disable dict, frame, tuple and list free list > * Disable type method cache > * Disable pymalloc: force usage of libc malloc > * Disable the GC in subinterpreters > * _xxsubinterpreters.run_string() releases the GIL > > I consider that's a reasonable small number of changes to get a cool > feature (per-interpreter GIL), compared to the same of the CPython > code base (637K lines). > > -- > > All these "#ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS" are temporary > workarounds until a proper fix is designed. For example, some caches > should be made "per-interpreter". > > Most changes are easy to write, but some other changes are non > trivial. For example, I modified _PyThreadState_GET() and > _PyThreadState_Swap() to use a Thread Local Storage (TLS) to get and > set the current Python thread state. > > Currently, "#ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS" are not > "visible" to users: it is only used in .c files and a few internal > header files. But the following PR modify the public Include/object.h > header file to make PyObject.ob_refcnt atomic: > > https://github.com/python/cpython/pull/19958 > > I would like to ensure that you are ok to put a few more temporary > "#ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS" in CPython to speedup > the development of subinterpreters running in parallel > (per-interpreter GIL), or if you consider that it has gone too far and > a Git fork would be better. > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > python-committers mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/2WHQBHFK7UQ7OYAJV5S2QCINODVVKGJY/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -- Inada Naoki ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/4F67S3G7ME64G2R73326TWOCFX5XNNMB/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Submit PEP 624 to SC.
Hi, all. I think PEP 624 is ready to SC review for now. How can I submit it to the SC? Regards, -- Inada Naoki ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/N6CARPZYUFABZQYQDXVEA6T6ZHPAUVUW/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Submit PEP 624 to SC.
Thank you! I submit it to GitHub. https://github.com/python/steering-council/issues/48 On Mon, Feb 15, 2021 at 5:07 PM Victor Stinner wrote: > > You can write an email to Python Steering Council > . > > There is also: https://github.com/python/steering-council/ > > Victor > > On Sat, Feb 13, 2021 at 3:02 AM Inada Naoki wrote: > > > > Hi, all. > > > > I think PEP 624 is ready to SC review for now. > > How can I submit it to the SC? > > > > Regards, > > -- > > Inada Naoki > > ___ > > python-committers mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > https://mail.python.org/mailman3/lists/python-committers.python.org/ > > Message archived at > > https://mail.python.org/archives/list/[email protected]/message/N6CARPZYUFABZQYQDXVEA6T6ZHPAUVUW/ > > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > > > -- > Night gathers, and now my watch begins. It shall not end until my death. -- Inada Naoki ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/W7LGFBKK275EYMGYGF2PHBZEQXHPBAR3/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Accepting PEP 597 (Add optional EncodingWarning)
Thank you, Council members and all members joined in the long discussion. On Tue, Mar 16, 2021 at 8:29 AM Guido van Rossum wrote: > >> >> Once the whole stdlib and most of top PyPI projects will be fixed to >> no longer emit EncodingWarning, I will become safer to opt-in for >> UTF-8 by default by enabling the Python UTF-8 Mode! >> https://docs.python.org/dev/library/os.html#python-utf-8-mode >> >> One day, we will silently switch Python to UTF-8 by default, and >> nobody will notice! ;-) > > > In particular it's important that nobody living in Japan or China should > notice. This is also still the biggest challenge. :-( > Java has a very similar problem and proposal. See JEP 400 (*) that was updated recently. If JEP 400 is accepted, users can use `-Dfile.encoding=COMPAT` for legacy behavior. If UTF-8 mode is enabled by default, users can use `PYTHONUTF8=0` or `-Xutf8=0` for legacy behavior. (*) https://openjdk.java.net/jeps/400 Anyway, PEP 597 adds `encoding="locale"` option. Let's implement it in Python 3.10 and wait 4 years. Many libraries will use only UTF-8, or can drop Python 3.9 support and use `encoding="locale"` where locale encoding is needed. Regards, -- Inada Naoki ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/EMYJ6KVCRNM3ZGPY6BWBVXHYBXIDPNU7/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Accepting PEP 624 (Remove Py_UNICODE encoder APIs)
Thank you, SC members, Victor, and Marc. On Tue, Mar 16, 2021 at 3:49 AM Thomas Wouters wrote: > > > Hi Inada, > > Thank you for submitting PEP 624 (Remove Py_UNICODE encoder APIs). The > Steering Council is happy to accept it, but we do have two conditions. We > want to make sure that the documentation is clear on what is deprecated, and > when they are scheduled to be removed. For example, > PyUnicode_TransformDecimalToASCII is itself not currently marked as > deprecated (although the section header does mention the deprecation, that is > easy to miss), PyUnicode_TranslateCharmap is scheduled for removal in 4.0, > and PyUnicode_AsUnicode has two deprecation notices, one mentioning removal > in 3.10 and one in 3.12. > > We would also like to make sure users who need to migrate off of these APIs > have the information necessary to do so. The PEP currently lists alternatives > with caveats, and it's not immediately obvious from the PEP or the API > documentation what the right alternative is for those caveats. As a condition > of this PEP’s acceptance, we request that you fully document the recommended > workarounds for these caveats. We do recognise that PyUnicode_EncodeDecimal > is currently entirely undocumented. Documenting at this stage is probably not > worth the effort, but perhaps it could be mentioned in a brief ‘porting’ > section in the PEP instead. > > With the Python Steering Council's gratitude, > Thomas. > -- > Thomas Wouters > > Hi! I'm an email virus! Think twice before sending your email to help me > spread! -- Inada Naoki ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/6VOKLYSEHGPX3IIXGR2NBXN45LSBOFAM/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Roundup to GitHub Issues migration
FWIW, GitHub announced new powerful Issues today. https://github.com/features/issues It may fill some gap between GitHub Issues and Roundup. Regards, -- Inada Naoki ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/IVTIRU4X6PXAAMUKFJU3IJB35BAR4A67/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: GitHub mystery: "Check for source changes (pull_request)" failed
It seems to an incident of GitHub.
https://www.githubstatus.com/incidents/cypv026dr23w?utm_ts=1641954539
On Wed, Jan 12, 2022 at 12:24 PM Tim Peters wrote:
>
> Bizarre. "Check for source changes (pull_request)" apparently fixed
> itself by magic. Now "Check if generated files are up to date
> (pull_request)" is failing instead, in a similar way ("Can't use 'tar
> -xzf' extract archive file"). Nope! No idea here what that's trying to
> check either ;-)
>
>
> On Tue, Jan 11, 2022 at 8:57 PM Tim Peters wrote:
> >
> > New one to me!
> >
> > The new
> >
> > https://github.com/python/cpython/pull/30555
> >
> > is dead in the water, with a "Check for source changes (pull_request)"
> > failure.
> >
> > Afraid to say I don't even know what that's trying to check.
> >
> > The details show this at the end:
> >
> > Error: Can't use 'tar -xzf' extract archive file:
> > /home/runner/work/_actions/_temp_e6eccc97-eabe-4596-b4b2-6ea2f8c672cb/8fca955b-16e0-4c1b-81a8-38d568264bd6.tar.gz.
> > return code: 2.
> >
> > Clues? It's a simple PR, making a few changes to just one C file.
> ___
> python-committers mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/HYI7DZYIZ5GNXV3UHWJFEE47LCMUKDQH/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
--
Inada Naoki
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/JEM3IHMLP2ABKHWSFCPGJFETTIQWDJGY/
Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: [IMPORTANT] Preparations for 3.11.0 beta 1
Hi, Pablo. I just submitted the PEP 686 to the SC. https://github.com/python/steering-council/issues/118 In this PEP, I am proposing: a. Small improvement for UTF-8 mode in Python 3.11 b. Make UTF-8 mode default in Python 3.13. (a) is an important change for (b) so I included it in the PEP. More precisely, (a) contains two changes: * Making `open(path, encoding="locale")` use locale encoding in UTF-8 mode (Python 3.10 used UTF-8) * Add `locale.getencoding()` that is same to `locale.getpreferredencoding(False)` but returns locale encoding even in UTF-8 mode. These changes are important for (b). But they are not a big change needing PEP. What should I do? * Do not merge anything until PEP accepted. * Merge (a) without waiting PEP accepted. * Merge (a) and remove it from the PEP. FWI, I and Victor are implementing `locale.getencoding()` for now. https://bugs.python.org/issue47000 https://github.com/python/cpython/pull/32068 Regards, -- Inada Naoki ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/7E4QEKZ6HNDDPDL76LP3TBBKLAUQ7AHB/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: [IMPORTANT] Preparations for 3.11.0 beta 1
Thank you, Victor. I had considered dropping (a) from the PEP. But I keep them because: * I rushed to write PEP, before 3.11 beta. * In the "Backward compatibility" section in the PEP, I want to mention `locale.getencoding()` and `encoding="locale"` * But they are not fixed in the main branch yet. So I need to include what needs to be fixed in 3.11 in the PEP. But for now, we are close to merge `locale.getencoding()`. And I am afraid merging it before the PEP accepted even though it is documented in the PEP... Now I think the best way is: * Withdraw the PEP submission temporarily. * Implement `locale.getencoding()` and fix `encoding="locale"` in the main branch. * Remove them from the PEP. * Resubmit the PEP. And if the PEP is accepted, I want to do this in the 3.11 branch (even though it will be beta already): * Improve document about UTF-8 mode and EncodingWarning based on the PEP. * Add (opt-in) EncodingWarning to `locale.getpreferredencoding()` and `subprocess.Popen(text=True)`. On Thu, Apr 7, 2022 at 9:42 PM Victor Stinner wrote: > > IMO adding locale.getencoding() to Python 3.11 is not controversial > and is useful even if PEP 686 is rejected. This function was discussed > for 1 year (bpo-43510, bpo-43552, bpo-43557, bpo-47000) and there is > an agreement that there is a need for this function. > > > Making `open(path, encoding="locale")` use locale encoding in UTF-8 mode > > (Python 3.10 used UTF-8) > > If someone explicitly opts in for the "locale encoding", it sounds > surprising that the locale (encoding) is ignored and that UTF-8 is > used if the Python UTF-8 Mode is enabled. I'm fine with this change. > If you want to always UTF-8... Pass explicitly UTF-8: > > # no surprise, always decode file content from UTF-8 > json_file = open(filename, encoding="utf-8") > > -- > > I will not comment PEP 686 here. It's being discussed on Discourse: > > * https://discuss.python.org/t/14435 > * https://discuss.python.org/t/14737 > > Victor > > On Thu, Apr 7, 2022 at 5:35 AM Inada Naoki wrote: > > > > Hi, Pablo. > > > > I just submitted the PEP 686 to the SC. > > https://github.com/python/steering-council/issues/118 > > > > In this PEP, I am proposing: > > > > a. Small improvement for UTF-8 mode in Python 3.11 > > b. Make UTF-8 mode default in Python 3.13. > > > > (a) is an important change for (b) so I included it in the PEP. > > More precisely, (a) contains two changes: > > > > * Making `open(path, encoding="locale")` use locale encoding in UTF-8 > > mode (Python 3.10 used UTF-8) > > * Add `locale.getencoding()` that is same to > > `locale.getpreferredencoding(False)` but returns locale encoding even > > in UTF-8 mode. > > > > These changes are important for (b). > > But they are not a big change needing PEP. > > > > What should I do? > > > > * Do not merge anything until PEP accepted. > > * Merge (a) without waiting PEP accepted. > > * Merge (a) and remove it from the PEP. > > > > FWI, I and Victor are implementing `locale.getencoding()` for now. > > > > https://bugs.python.org/issue47000 > > https://github.com/python/cpython/pull/32068 > > > > Regards, > > -- > > Inada Naoki > > ___ > > python-committers mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > https://mail.python.org/mailman3/lists/python-committers.python.org/ > > Message archived at > > https://mail.python.org/archives/list/[email protected]/message/7E4QEKZ6HNDDPDL76LP3TBBKLAUQ7AHB/ > > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > > > -- > Night gathers, and now my watch begins. It shall not end until my death. -- Inada Naoki ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/XVJEAF7S2OORL77QMLLQTWKHLRDFA3KH/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: [IMPORTANT] Preparations for 3.11.0 beta 1
On Fri, Apr 8, 2022 at 6:05 PM Petr Viktorin wrote: > > > That shouldn't be necessary. If you're making these changes anyway, you > can just add a note to the SC request that the 3.11 changes are being > merged now. (I'll just do that myself now!) > Then update the PEP to say "This API was added in Python 3.11" instead > of "will be added". > I fixed issues in Python 3.11 and updating the PEP as you suggested. Thank you. https://github.com/python/peps/pull/2525/files -- Inada Naoki ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/ZLT5EEMYK4RG3PZYLK6VDEWXIB5KXRQV/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Greeting from INADA Naoki
Hi, all. Thank you, Yury and all for approve me. I'll focus on polishing dict implementation, and getting familiar with workflow until 3.6. Self-introduction: * Github account name is methane * Maintainer of Japanese translation of Python document (http://docs.python.jp ) * Maintainer of two common MySQL driver: mysqlclient (successor of MySQL-python) and PyMySQL; And serialization library: msgpack-python. * My skills are network application programming on Linux, C, and Go. * I'm not fluent in English. I'm not good at writing documentation and joining long discussion. I want to contribute in C and Python code. * My interest is performance, efficiency, and simplicity. Regards, -- INADA Naoki ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Greeting from INADA Naoki
On Wed, Sep 28, 2016 at 11:14 PM, Victor Stinner wrote: > Hi, > > It's nice to have you on board to take care of the new implementation > of dict :-) Welcome! > > Since you are japanese and probably know well issues with encodings, > it would be nice if you test Python 3.6, especially on Windows, to see > if you see some potential issues and/or enhancements. Python 3.6 > changed deeply how bytes data is handled on Windows, it now uses utf8 > by default for many things (Steve Dower PEPs). Are you developing on > Windows, Linux or something else? I'm using macOS on work, and Ubuntu on home hacking almost every day. I have Windows 10 machine too for building binary wheel, and tasks other than hacking (managing photos and musics, and Windows Update). I use it 1~5 times a month. I'll try 3.6 beta next time. > > Victor > > 2016-09-27 19:35 GMT+02:00 INADA Naoki : >> Hi, all. >> >> Thank you, Yury and all for approve me. >> >> I'll focus on polishing dict implementation, and getting familiar with >> workflow until 3.6. >> >> Self-introduction: >> >> * Github account name is methane >> >> * Maintainer of Japanese translation of Python document >> (http://docs.python.jp ) >> >> * Maintainer of two common MySQL driver: mysqlclient (successor of >> MySQL-python) >> and PyMySQL; And serialization library: msgpack-python. >> >> * My skills are network application programming on Linux, C, and Go. >> >> * I'm not fluent in English. I'm not good at writing documentation and >> joining long >> discussion. I want to contribute in C and Python code. >> >> * My interest is performance, efficiency, and simplicity. >> >> Regards, >> >> -- >> INADA Naoki >> ___ >> python-committers mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-committers >> Code of Conduct: https://www.python.org/psf/codeofconduct/ -- INADA Naoki ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Promote Xiang Zhang as a core developer
+1, if I can vote. He helped me a lot by reviewing my patch, and fixing issues relating to dict. Regards, -- INADA Naoki ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit
Hi, Victor and all. I'm sorry, I haven't read the whole mail yet. Reading long English is tough job for me. I notice this mail is very important for me. I'll take time to read this thread. But it may take long time. I want to post some comments before. I learned many from reviewing Victor's patches. For example, I learned how to add type slot without breaking ABI compatibility in this week. I learned some surprising corner cases from regressions caused by my patches, or patches I said LGTM too. So I thanks to Victor, and everyone who reviewed my patch, who run their test with development branch of Python, and Travis-CI (it ease running tests with "3.7-dev" branch.) About pace of changes, I'll reduce my pace to write patches, because I joined one project in my company. But I'll keep time to watch issue tracker and review patches, though. Regards, ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit
I read this whole thread. Here is my opinion. 1. Lack of reviewers It's really problem. If well written patch is not reviewed and committed for long time, patch writer (core developer, or potential core developer) may lost their motivation. Motivated contributor will be lower and lower. I wrote compact dict patch in June, before Python 3.6a3. Luckily, the patch was reviewed and committed in September, right before 3.6b1. But I realized Python lacks active reviewers heavily. That's main reason why I wanted to be core developer. I was very lucky. But there might be some contributors lost motivation because of lack of review. 2. Stability Stability is important. Review is valuable for stability. But even though careful review, regression may be happens. Python 3.6 has many improvements. And many of them are committed right before 3.6b1, at sprint. http://blog.python.org/2016/09/python-core-development-sprint-2016-36.html I feel adding fundamental changes (like FASTCALL) at early stage of development process (alpha1~3) is also valuable for stability of last beta, RC and final. And I think advocating running test with "nightly" Python on Travis-CI may help stability, even though there are few beta users. One regression caused by compact dict (*), and it was one reason of 3.6rc2 was released. The regression is found by py.test. *) An excuse: the issue was not from compact dict. It was issue of key sharing dict. But compact dict increased method which can touch the issue, and py.test touched it. 3. Domain expert I agree that consult to expert is good. But sometimes the expert may not be active. And mechanical changes by sed or Coccinelle may affects wide part. It's not realistic to consult all experts. We should think carefully it's worth enough. But after some devs agree it's worth enough, "ask forgiveness than permission" seems realistic approach, like Stefan reverted _decimal change. 4. Github Github may ease some problems we have, especially reviewing large patch. https://github.com/blog/2123-more-code-review-tools Python 3.4.6 and 3.5.3 are released already, migration happens near future? Anyway, I'm thanks to people working on the migration. Regards, ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposed new core developer -- Mariatta Wijaya
+1 https://github.com/python/cpython/search?p=1&q=Mariatta&type=Commits&utf8=%E2%9C%93 Her English is definitely better than me :) And I feel it's easy to read for non native speaker. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 4 weeks with the new workflow: what needs changing?
On Sat, Mar 25, 2017 at 12:22 AM, Antoine Pitrou wrote: > > Hi, > > Le 24/03/2017 à 16:11, R. David Murray a écrit : >> On Fri, 24 Mar 2017 14:29:13 +0100, Antoine Pitrou >> wrote: >>> >>> By the way, how do I fetch remote changes for a branch without pulling >>> it into the working copy? e.g. I'd like to do "git fetch origin 3.5" or >>> "git fetch origin/3.5", but that doesn't seem to work... >> >> "git fetch origin 3.5" seems to work fine for me. Maybe I don't >> understand what you are trying to do? > > Apologies for being slightly imprecise. Yes, "git fetch origin 3.5" > actually fetches the remote changes, but it doesn't update the local > "3.5" branch with those changes, so when I do "git diff 3.5" from > another branch, I get spurious changes in the diff. > > (perhaps I should do "git diff origin/3.5" instead?) > > Regards > > Antoine. Yes, `git diff origin/3.5` is normal way. If you always use feature branch, there are no need for local 3.5 branch. I usually create "backport" branch by: `git checkout -b backport-xxx-35 origin/3.5`. OTOH, there is hackey way. Assuming you didn't have checkout of local 3.5 branch, `git push . origin/3.5:3.5` may update 3.5 branch. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
