Congratulations Erlend, it's well deserved!
Victor
On Sat, May 7, 2022 at 1:03 AM Brett Cannon wrote:
>
> EOM
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
>
On Fri, May 6, 2022 at 2:14 PM Pablo Galindo Salgado
wrote:
> Today we need to start the release of Python 3.11 beta 1. Currently, we have
> the following blockers:
>
> * https://github.com/python/cpython/issues/91162 (was deferred blocker - but
> all deferred blockers are bumped to release bloc
On Tue, May 3, 2022 at 8:49 PM Brett Cannon wrote:
>> On 5/2/22 16:00, Jelle Zijlstra wrote:
>>
>> > We have added several new triagers today:
>>
>> Do triagers have access to this list?
>
> Nope, core devs only.
>
> -Brett
But archives of the python-committers list are public:
https://mail.pytho
Congratulations to newly promoted triagers! Enjoy the new reactive GitHub
UI for bug triage!
Victor
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.
On Tue, Apr 19, 2022 at 12:36 AM Brett Cannon wrote:
> And now the PR is merged! https://github.com/python/peps/pull/2442
Wow! That's huge! Thanks you so much Brett for handling this heavy
task! It has been discussed for like 5 years at least.
It's great to have a way more *practical* definition
On Thu, Apr 7, 2022 at 5:35 AM Inada Naoki wrote:
> 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.
It's easier to a
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
On Fri, Apr 1, 2022 at 11:19 PM Christian Heimes wrote:
> How about:
>
> * a buildbot is required. For a transition period a public CI system,
> that runs Python's test suite at least once per day, is also acceptable.
>
> * at least one active contributor who acts as a point of contact,
> monitors
I like your proposal better than mine :-) I agree that my Tier 3's
constraints were too weak :-(
On Fri, Apr 1, 2022 at 9:22 PM Brett Cannon wrote:
>> For me the main threat of (adding a platform to) Tier 3 is the risk
>> that we might never ever able to drop support for these platforms. PEP
>> 1
On Fri, Apr 1, 2022 at 1:42 AM Victor Stinner wrote:
>
> On Fri, Apr 1, 2022 at 12:25 AM Brett Cannon wrote:
> > powerpcle-linux-gnu glibc, clang
>
> This one has 2 core devs in the PR: "Petr Viktorin, Victor Stinner".
Oh wait, "Petr Viktorin, Victor Stinner
On Fri, Apr 1, 2022 at 12:25 AM Brett Cannon wrote:
> powerpcle-linux-gnu glibc, clang
This one has 2 core devs in the PR: "Petr Viktorin, Victor Stinner".
> s390x-linux-gnu glibc, gcc
> s390x-linux-gnu glibc, clang
> x86_64-unknown-freebsd BSD libc, cc (Victor is alread
Hi,
I don't think that the current PEP 11 draft (*) describes correctly
the current status of a bunch of platforms which are not "actively"
supported. I like to call these plaforms as "best effort support"
platforms. I propose considering adding an explicit "Tier 3" to PEP
11.
(*) https://github.
On Fri, Mar 25, 2022 at 7:04 PM Brett Cannon wrote:
>
> On Fri, Mar 25, 2022 at 4:23 AM Victor Stinner wrote:
>>
>> I dislike the Tier 1 rule "All core developers are responsible to keep
>> these platforms, and thus ``main``, working."
>>
>> In my
I dislike the Tier 1 rule "All core developers are responsible to keep
these platforms, and thus ``main``, working."
In my experience, "Everyone is reponsible" means in practice "nobody
is responsible". IMO you must also put two names in front of each
platform. Otherwise, nobody will fix them when
Ok, I added myself on the PR.
Victor
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archiv
You wrote that you want at least 2 core devs responsible for each tier
1 platform. I didn't understand if this requirement is also for Tier
2.
Who are these core devs? Is there a list?
Victor
___
python-committers mailing list -- python-committers@pytho
Hi Brett,
You can put my name as Contact of all Fedora and RHEL platforms.
Note: Fedora "Rawhide" is the rolling release and it's common that
these buildbots are broken by kernel, compiler or glibc updates,
rather than actual Python regressions. Time to time, it detects real
Python regressions. T
By the way, AMD64 Arch Linux Usan 3.x started failing because I
enabled more tests on this buildbot yesterday.
Previously, "test_faulthandler test_hashlib test_concurrent_futures
test_ctypes" were simply skipped on this UBSAN buildbot.
I'm working on fixing the 3 failing tests: test_ctypes,
test_
When I propose a PR on a project and I don't plan to contribute more
than than PR, when the PR is merged, I delete my fork. At work, I send
patches to many different projects to fix some Python 3.11
compatibility issues.
It just was a general remark. If you enable 2FA on GitHub, the effect
is not
On Tue, Feb 8, 2022 at 12:11 AM Brett Cannon wrote:
> And to be clear, you only need access to your 2FA solution when you log in;
> it's not a day-to-day action at all (I personally have not used my 2FA since
> the last time I logged into a new device for the first time or when my GitHub
> acco
On Thu, Jan 6, 2022 at 12:33 PM Pablo Galindo Salgado
wrote:
> * https://bugs.python.org/issue46006
>
> Victor made a revert of his PR but unfortunately, we cannot easily backport
> it to 3.10 as it affects the ABI. It affects the interpreter state structure
> that although is not on the stable
Oh, I confirm that it landed in my Spam folder.
I created a Gmail filter to mark emails coming from
no-re...@mail.heliosvoting.org as "Never send to the spam folder".
Victor
___
python-committers mailing list -- python-committers@python.org
To unsubscri
Hi Antoine,
You can report miss-islington issues to its GitHub project:
https://github.com/python/miss-islington
I reported two issues:
(*) Backport fails with no explaination, but work if retried (September):
https://github.com/python/miss-islington/issues/389
(*) Approved backport PR not merg
Hi Eric,
The bot source code and bug tracker can be found at:
https://github.com/python/miss-islington
Victor
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://m
Hi Ezio,
What is the status of the migration of Python issues from
bugs.python.org (Roundup) to GitHub? Is it still a work-in-progress or
is it stalled?
Victor
On Mon, Jun 21, 2021 at 4:20 AM Ezio Melotti wrote:
>
> As you might know, PEP 581 (Using GitHub Issues for CPython) has been
> approve
Welcome aboard Ammar!
I worked with Ammar in various places of Python which is a good sign.
He is curious to enhance many things and he was already very helpful!
I was in holiday last weeks. Since the vote is closed, I cannot vote
anymore, but I don't care and I vote +1 for his promotion anyway :
Hi Terry,
When I detect a spam on bugs.python.org:
* I remove the "User" role of the author
* I unlink messages from the issue and then mark them as spam
Victor
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an e
Hi
I'm always confused by expressions "good" and "bad". Previously, I
added shell comments:
$ git bisect bad # slow
$ git bisect good # fast
or:
$ git bisect bad # no leak
$ git bisect good # leak
where good = leak is counter-intuitive...
Since it confused too many people (including myself),
Hi,
If someone sees a random issue on a CI, I suggest to open an issue at
bugs.python.org to track it. Otherwise, slowly, the number of random
failures becomes so high that it takes several "re-run all jobs"
steps, and so merging a basic typo fix takes 1 hour if not longer.
Victor
On Tue, Jun 22
Hi Irit,
Since it's documented as deprecated, asyncore and asynchat are
deprecated as well since Python 3.6 (smtpd uses asynchat), I suggest
to remove these 3 modules right now. I would prefer to make such
incompatible change early in the development cycle, to give more time
to users to adapt thei
Hi Andrew,
If someone ones smtpd, I would suggest to copy it from Python 3.10
(with asyncore and asynchat) and continue the maintenance outside the
CPython Git repository.
Create a project on PyPI if you expect contributions.
Victor
On Wed, Jun 23, 2021 at 9:13 AM Andrew McNamara
wrote:
>
> >I
See also
https://discuss.python.org/t/remove-coordinator-role-of-inactive-coordinators-on-bugs-python-org/866
for the security of bugs.python.org. So far, no action was taken.
Inactive coordinators kept their permission.
For GitHub, I'm using a Yubikey and FreeOTP for the 2FA.
Victor
On Mon, Ju
On Fri, May 28, 2021 at 6:55 AM Tim Peters wrote:
> I suppose I could ask why heap types were fiddled to point to their
> module objects too - but that's really got nothing to do with getting
> the release done, so I won't :-)
PyHeapTypeObject.ht_module was added by the PEP 573 "Module State
Acce
On Thu, May 27, 2021 at 8:24 PM Pablo Galindo Salgado
wrote:
> > And if a type pointer is the only thing being visited, then there's no
> > point unless the object can itself be reachable from the type object.
>
> But that could happen easily for heap types as they are mutable by default.
> For
I confirm that commits merged in 3.9, 3.10 and main branches are
logged again in bugs.python.org. Thanks to everyone who helped to
solve this issue!
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
python-committers
On Tue, May 18, 2021 at 12:33 AM Zachary Ware wrote:
> I might have found it; I at least opened
> https://github.com/psf/bpo-roundup/pull/1 against what I found :)
Sadly, commits in the main branch are still not logged to bugs.python.org, see:
https://github.com/psf/bpo-roundup/pull/1#issuecommen
Your poll has a choice: "IRC channel other than #python-dev".
FYI buildbot notifications already moved from #python-dev to #python-dev-notifs.
I created a PR to move GitHub notifications there as well:
https://github.com/python/psf-salt/pull/209
Victor
On Sun, May 23, 2021 at 1:08 AM Senthil Ku
Any update on this issue? Nobody recalls what code and service sends a
comment to bugs.python.org when a commit is merged?
Victor
On Wed, May 12, 2021 at 4:23 PM Guido van Rossum wrote:
>
> Recently it seems that when a PR linked to a bpo issue is merged, no note of
> this event is made in the
Did you notice that you are already chatting by email? Chatting about
other chat platforms :-) Why not just accepting that emails won? :-)
When discuss.python.org was launched, a few discussions moved there,
and slowly, moved back to python-dev list.
Emails will never die! :-D
Victor
___
Hi,
I'm always connected to IRC #python-dev (Freenode) for 10 years, a few
other core devs use it time to time. Come to say hello ;-)
The bugs.python.org and buildbot notifications are useful to me and I
don't feel annoyed by them. But GitHub review are hard to use: only
the user name and the PR
Congratulations Irit and welcome aboard!
I hope that PEP 654 "Exception Groups and except*" will be accepted soon ;-)
For the record, link to the vote which lists Irit's work and
endorsement: https://discuss.python.org/t/vote-to-promote-irit-katriel/8457
Victor
On Tue, May 11, 2021 at 7:18 AM B
Hi,
Please don't attempt to merge PRs until the GitHub issue described
below is solved ;-)
Pablo renamed the default "master" branch to "main" (in a live Twitch
stream ;-)) but got a GitHub internal error! Maybe it's because the
dialog announced that 1.4k+ pull requests and 700+ repositositories
On Wed, Apr 21, 2021 at 1:24 PM M.-A. Lemburg wrote:
> Isn't that an educational problem ? Adjusting reporting of
> warnings isn't all that hard:
A common practical problem is a project CI which pulls the most recent
verisons of 3rd party dependencies and suddenly break if a new
deprecation warni
Hi,
In this case, we need more advanced warnings filters to only show
deprecation warnings in the "current application code", and ignore
deprecation warnings from any other module. Is there a way to create
an entry point in setuptools which says "this application uses the
package xxx"?
Since ther
Oh, there is an update! 3 days ago, a member of the GitHub "staff" wrote:
"This should be fixed. Please do let us know if it is not."
https://github.community/t/i-am-getting-notifications-due-to-being-mentioned-in-a-commit/172531/32
Victor
On Tue, Apr 6, 2021 at 4:36 PM V
Oh, I recognize his GitHub nickname. He fixed a few bugs that I introduced
and helped me on some issues. Congrats Ken Jin!
Victor
On Sun, Apr 11, 2021 at 7:31 PM Pablo Galindo Salgado
wrote:
> Hi everyone,
>
> I started to mentor Ken Jin (Fidget-Spinner on Github) and I gave him bug
> triage pe
On Tue, Apr 6, 2021 at 6:41 PM Pablo Galindo Salgado
wrote:
> I think this is a good motivation to use
> https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request
> instead as you can write your own commit message there and schedule the
>
python project. Example:
https://github.com/zooba/cpython/commit/9a5e643483578c3a944ceb5aa511d6c24280aedc
"You are receiving this because you were mentioned."
Some email headers:
-
From: Anthony Sottile
To: "zooba/cpython"
Cc: Victor Stinner , Mention
Reply-
Hi,
About this very specific ABI issue, one long term solution would be to
exclude the PyThreadState structure from the C API, to not rely on it
the ABI level.
I started to add getter functions in Python 3.9:
PyThreadState_GetInterpreter(), PyThreadState_GetFrame() and
PyThreadState_GetID(). I'm
Hi Ewa,
This is really awesome! It's great that the PSF can now hire someone for that!
The job offer is great, but I would like some clarification :-) (While
I was part of the previous Steering Council who helped to write the
job offer, sadly I was not avaialble last months when it was
discussed.
On Tue, Mar 16, 2021 at 9:16 PM Gregory P. Smith wrote:
> The benefit of listing the sha256 for files is that it prevents this question
> coming up again and again because md5 is old and rightfully on the "never
> use" list for many people. Even if there are situations where it is fine as
> an
Congratulation INADA-san! I'm impressed by your tenacity :-)
Last months, I followed your different propositions on
discuss.python.org to use UTF-8 by default in Python. It's good to see
the first non-controversial part being accepted! I hope that this PEP
will help to move towards a world where w
Hi Serhiy,
On Thu, Mar 11, 2021 at 8:33 AM Serhiy Storchaka wrote:
> I have above 200 feature branches in my local repository. Will renaming
> the master branch cause any problems?
I don't think that you need to do anything on your machine nor on your open PRs.
When I use "git switch -c new_bra
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 Nao
Hi Ethan,
In general, I would say that we don't provide any backward
compatibility warranties on the exact repr() output. In practice, we
attempt to not change it unless there is a good reason for that. IMO
in your case, it's justified. When float repr() was changed, it broke
tons of doctests :-(
Reminder: the deadline for nomination is tonight, hurry up ;-)
Current candidates can be found at:
https://discuss.python.org/c/core-dev/steering-council-nominations/21
Victor
Le mer. 28 oct. 2020 à 20:55, Ewa Jodlowska a écrit :
>
> Hi!
>
> The timeline for this year's election will be the sam
Hi,
I just gave the bug triage permission to Hai Shi. I will continue to
mentor him for his new responsibilities, as I already did through code
reviews last months.
In 2020, he is the #5 most active developer and the #1 most active
non-core dev developer on the CPython project!
He got 101 commit
t; with it for a long long time. Long enough maybe for someone to fix the bug!
> Or for someone to replace Travis CI with something less race-condition-y!
>
>
> /arry
>
> On 10/16/20 1:41 AM, Victor Stinner wrote:
>
> Hi,
>
> Python has no mandatory Linux CI job on pull
Hi,
Python has no mandatory Linux CI job on pull requests anymore. Right
now Windows (x64) remains the only mandatory job. Please be careful to
manually check other CI before merging a PR.
--
We had to deal with at least 3 different issues on the Travis CI over
the last 6 months. The latest one
Le mer. 14 oct. 2020 à 17:59, Antoine Pitrou a écrit :
> unpack-sequence is a micro-benchmark. (...)
I suggest removing it.
I removed other similar micro-benchmarks from pyperformance in the
past, since they can easily be misunderstood and misleading. For
curious people, I'm keeping a collection
I suggest to limit to one "dot" per week, since CodeSpeed (the website
to browse the benchmark results) is somehow limited to 50 dots (it can
display more if you only display a single benchmark).
Previously, it was closer to one "dot" per month which allowed to
display a timeline over 5 years. In
Le lun. 12 oct. 2020 à 08:56, Tal Einat a écrit :
> I've come to think that #2 is especially important. This is a
> difference with a project like ours vs. a work environment: At a
> workplace, there usually isn't a need to thank people for their work
> on an issue, so just making sure that status
GitHub workflow is nice when a single commit is enough to close an
issue. But what if a bug should be fixed in multiple branches? Is
there a way in GitHub to require one commit per branch to close an
issue?
Victor
Le dim. 11 oct. 2020 à 21:16, Guido van Rossum a écrit :
>
> Once issues move to G
Le jeu. 17 sept. 2020 à 11:57, Łukasz Langa a écrit :
> The 3.9 branch is now accepting changes for 3.9.1. To maximize stability, the
> final release will be cut from the v3.9.0rc2 tag. If you need the release
> manager to cherry-pick any critical fixes, mark issues as release blockers
> and/or
FYI this MSDN subscription allowed me to debug tons of Windows
specific issues and to enhance Windows support. It's really very
helpful, at least to me :-) Thanks Microsoft!
Victor
Le jeu. 13 août 2020 à 19:29, Steve Dower a écrit :
>
> Hi all
>
> It seems like people are due to renew their subs
Le mar. 7 juil. 2020 à 04:21, Raymond Hettinger
a écrit :
> At beta 1, freeze the addition of new features but continue to tweak the
> implementation with code clean-ups, (...)
IMHO clean-ups should stop after beta1. Only the master branch should
receive cleanup changes. A clean-up doesn't bring
Congratulations Lysandros! It's well deserved, the PEG parser is a
giant beast of complexity. It's good to have someone to take care of
it ;-)
Victor
Le mar. 30 juin 2020 à 21:21, Brett Cannon a écrit :
>
>
> ___
> python-committers mailing list -- py
Hi,
FYI the Windows x64 CI is now mandatory on Python pull requests (on
the master branch).
Victor
Le ven. 15 mai 2020 à 17:09, Victor Stinner a écrit :
>
> Hi,
>
> Changes on CIs run on GitHub pull requests:
>
> * Travis CI became mandatory
> * Azure Pipelines i
Le mer. 20 mai 2020 à 02:39, Terry Reedy a écrit :
> First, with 2.x really past us, is removing remaining long deprecated
> features, plus some others advocated for removal. I think these are
> best done by the first alpha so that early testers are rewarded with an
> early opportunity to change
Hi,
Changes on CIs run on GitHub pull requests:
* Travis CI became mandatory
* Azure Pipelines is no longer mandatory
* Please watch Windows x64 job: I would like to make it mandatory in 2 weeks
--
I asked to make Azure Pipelines CI not mandatory on Python PRs since
there were more and more ran
ean here. My changes rely on the assumption
that objects are not shared between two interpreters.
I didn't work at all on the inter-interpreter communication.
> On 06/05/2020 6:49 pm, Victor Stinner wrote:
> > It's a practical solution to be able to experiment quickly
> > per
Yes, it can wait until 3.9 branch is created and master becomes the future 3.10.
Victor
Le mer. 6 mai 2020 à 21:40, Brett Cannon a écrit :
>
> Can we wait until after 3.10 development opens up? And could it be a `-X`
> flag?
> ___
> python-committers
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: preve
Hi,
In the Python 3.8.3rc1 changelog, I see these two changes:
(1) bpo-39776: Fix race condition where threads created by
PyGILState_Ensure() could get a duplicate id. This affects consumers
of tstate->id like the contextvar caching machinery, which could
return invalid cached objects under heavy
Hi,
Thanks for the release!
Python 3.8.3rc1 has a compiler regression introduced after Python
3.8.2: https://bugs.python.org/issue39562#msg365311
I proposed different options to fix it:
https://bugs.python.org/issue39562#msg367018
Victor
Le jeu. 30 avr. 2020 à 01:08, Łukasz Langa a écrit :
>
Antonio Cuni's slides:
"HPy: a future-proof way of extending Python?"
https://speakerdeck.com/antocuni/hpy-a-future-proof-way-of-extending-python
Guido, Pablo: are your slides public? (Guido sent a link but I didn't
know if it can be shared in public, moreover I lost the link :-))
Victor
Le mer.
Welcome aboard Kyle! Congratulations for your promotion!
Victor
Le mer. 15 avr. 2020 à 03:38, Kyle Stanley a écrit :
>
> Thank you for the support everyone and for adding my permissions, Brett! I
> wrote my "acceptance speech" over on discuss:
> https://discuss.python.org/t/vote-to-promote-kyl
Le lun. 6 avr. 2020 à 13:31, Steve Dower a écrit :
> The CI configuration is loaded from the PR head, at least on GitHub
> Actions (where you can validate config changes in PR) and Azure
> Pipelines. I just validated this by re-running an old PR and watched it
> choose OpenSSL 1.1.1d instead of 1.
Oh sorry, the vote will close automatically *Wednesday* morning (in 2
days), not tomorrow morning.
Victor
Le dim. 5 avr. 2020 à 02:43, Victor Stinner a écrit :
>
> Reminder: the "Vote to promote Dong-hee Na" will close next tuesday
> morning. So far, it got 21 voters.
>
&
Reminder: the "Vote to promote Dong-hee Na" will close next tuesday
morning. So far, it got 21 voters.
Victor
Le mar. 31 mars 2020 à 01:48, Victor Stinner a écrit :
>
> https://discuss.python.org/t/vote-to-promote-dong-hee-na/3794
>
> Victor
> --
> Night gathers,
Hi,
tl; dr Maybe the 1090 pending pull requests will have to be rebased on
master to be able to be merged, unless we enhance our CI to always
test PRs after rebasing them on the master branch. I'm not sure at
this point.
--
FYI the Night’s Watch is still fixing the CIs in the darkness for you
:-
https://discuss.python.org/t/vote-to-promote-dong-hee-na/3794
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-co
Hi,
There is a new "CodeCov" thing on Python pull requests which adds a
giant comment with many numbers and statistics and then mark my pull
request as "failed" (red).
I know the concept of code coverage, ok. But who uses this service?
Does it *have to* send emails to say:
"Merging #18743 into m
FYI I'm using a Gmail filter to ensure that emails coming from
rep...@bugs.python.org are never marked as spam.
Victor
Le ven. 28 févr. 2020 à 20:51, Antoine Pitrou a écrit :
>
>
> Le 28/02/2020 à 19:56, Mariatta a écrit :
> > I think this is same issue
> > as https://github.com/python/bugs.pyth
Le mar. 18 févr. 2020 à 19:42, Jason R. Coombs a écrit :
> The Fedora failures in shutil and zipfile are "no space left on device".
> Seems like an environment/infrastructure issue.
Did you see my email? I opened an issue for the Fedora and Windows failures.
> "test_shutil fails with OSError: [
Le mar. 18 févr. 2020 à 01:14, Łukasz Langa a écrit :
> - macOS (importlib) -
> https://buildbot.python.org/all/#/builders/275/builds/249
It's a regression of a change merged yesterday:
https://bugs.python.org/issue38691
> - Fedora (shutil and zipfile) -
> https://buildbot.python.org/all/#/bui
Le mar. 18 févr. 2020 à 09:47, Steve Dower a écrit :
> Windows 7 is not supported for 3.9, but the buildbots have not been
> removed/repurposed yet. They can be ignored.
I created https://github.com/python/buildmaster-config/issues/168
"Disable Windows 7 on the Python 3.x branch".
Can someone p
Hi,
Le ven. 31 janv. 2020 à 21:59, Pablo Galindo Salgado
a écrit :
> I have been mentoring Batuhan Taskaya ("BTaskaya" on BPO, "isidentical" on
> GitHub) for
> the past few months. We have been working closely together on some features
> as "ast.unparse",
> many bugfixes and documentation impro
Congratulations to our bug triagger champion, Karthikeyan
Singaravelan! ;-) Thanks Andrew for promoting him.
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
python-committers mailing list -- python-committers@pytho
Le mer. 11 déc. 2019 à 01:00, Brett Cannon a écrit :
> We discussed the situation on the steering council and we are fine with
> making an exception for folks who felt caught off-guard asking Ernest to be
> added to the voter roll even though voting has already started.
>
> In the new year I wil
Can you please open an issue at https://bugs.python.org/ and then post
the link in this thread?
Thanks in advance,
Victor
Le mar. 10 déc. 2019 à 14:18, Christian Tismer a écrit :
>
> Hi Łukasz,
>
> tonite I found a critical bug that affects all heaptype extension
> classes with a custom (not PyT
If a core dev asks to have their commit bit removed, what happens if
they change their mind? Do we have go through the usual vote process?
Or should we just add it back whenever they ask?
Victor
Le mer. 4 déc. 2019 à 21:23, Brett Cannon a écrit :
>
> You ask me to do it. :) I have gone ahead and
I saw you fixing dozens of tarfile issues last years. Thanks for all
the work you did for Python!
Victor
Le mar. 3 déc. 2019 à 16:33, Lars Gustäbel a écrit :
>
> Hi!
>
> My name is Lars Gustäbel. I am the author of the tarfile module, and I have
> been its maintainer for over ten years. I have n
Hi Łukasz,
Le lun. 30 sept. 2019 à 16:32, Łukasz Langa a écrit :
> > On 30 Sep 2019, at 16:09, Nick Coghlan wrote:
> >
> > I've filed https://bugs.python.org/issue38326 as a release blocker, as
> > I don't think we should be cutting RCs when changes have been made to
> > a PEP-approved API witho
Congrats Joannah! You deserve this promotion ;-)
As I wrote in the vote, I will mentor Joannah one more month to help
her to deal with her new responsibilities. Usually, I ask to validate
with me before merging a PR.
Note: I'm not sure if she is already subscribed to the
Victor
Le mer. 25 sept.
Hi,
The PEP 13 says "A new council is elected after each feature release."
Does it mean that we need elect a new Steering Council before/after
Python 3.8.0 final release which is scheduled at 2019-10-21 (in more
or less one month)?
If a vote is organized, when should "Candidates advertise their
i
lun. 16 sept. 2019 à 14:53, Victor Stinner a écrit :
>
> You have one week to vote at:
> https://discuss.python.org/t/vote-to-promote-joannah-nanjekye-as-a-core-dev/2347
>
> Victor
___
python-committers mailing list -- python-committer
You have one week to vote at:
https://discuss.python.org/t/vote-to-promote-joannah-nanjekye-as-a-core-dev/2347
Victor
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
ht
Hi Brett,
Le jeu. 12 sept. 2019 à 18:54, Brett Cannon a écrit :
> https://devguide.python.org/developers/ has been updated to use a CSV
> generated from the python-core.toml file using code found in that repository.
> This should make maintaining that page in the devguide much easier and make
Le lun. 9 sept. 2019 à 18:46, Benjamin Peterson a écrit :
> No one could think of a reason not to replace AppVeyor with Azure, so I've
> gone ahead and done that on all those branches.
Here is a reason to not replace AppVEyor with Azure:
https://bugs.python.org/issue37245
The macOS job of Azure
1 - 100 of 534 matches
Mail list logo
