May he rest in peace, I can't even fathom the impact PIL has had on Python
over the years.
On Fri, Dec 10, 2021 at 3:20 PM Guido van Rossum wrote:
> A former core dev who works at Google just passed the news that Fredrik
> Lundh (also known as Effbot) has died.
>
> Fredrik was an early Python co
Thanks for the update! Although possibly a minor inconvenience to some, I
am certainly of the belief that our choice in language has a subtle, yet
powerful effect on our perception of the world around us, so although some
may see it as needless, I think small changes such as "master" to "main"
are
FWIW that seems like a reasonable approach, at least to me.
On Thu, Nov 18, 2021, 5:29 PM Guido van Rossum wrote:
> I know PEP 646 was one of these. In our defense, we *did* notify the SC
> that there was a pending issue (
> https://github.com/python/steering-council/issues/59#issuecomment-95172
ate, rather than 2 versions for all. Module
removal certainly takes more effort to adjust in code vs simple function
name change with 1:1 replacement.
--
--Kyle R. Stanley, Python Core Developer (what is a core dev?
<https://devguide.python.org/coredev/>)
*Pronouns: they/them **(why is my pro
t is great to see that the incumbents desire to have a wide pool of
applicants for the longevity of Python; rather than being on the SC
indefinitely.
Best Regards,
--
--Kyle R. Stanley, Python Core Developer (what is a core dev?
<https://devguide.python.org/coredev/>)
*Pronouns: they/them *
0_o color me impressed, I did not think that would be legal syntax. Would
be interesting to include in a textbook, if for nothing else other than to
academically demonstrate that it is possible, as I suspect many are not
aware.
--
--Kyle R. Stanley, Python Core Developer (what is a core
I'd suggest both: briefer, easier to read write up for average user in
docs, more details/semantics in informational PEP. Thanks for working on
this, Petr!
On Tue, Nov 2, 2021 at 2:07 PM David Mertz, Ph.D.
wrote:
> This is an amazing document, Petr. Really great work!
>
> I think I agree with Ma
Thanks for the fix! This could have caused some serious issues, so glad we
were able to address it ahead of time.
On Mon, Sep 13, 2021 at 5:06 AM Victor Stinner wrote:
> Hi,
>
> A bug has been identified and *fixed* in the OAuth-based
> authentication code used on the Python bug tracker bugs.pyt
I can agree with the general premise of what Antoine is saying, but to me
even as a non-participant, the following quote from the thread Brett linked
seems a clear CoC violation:
I repeat, even the worst AI will understand from the context what I meant.
> But let me do a very rude example:
>
> Wha
s to (or be able to fix it).
Best Regards,
--
--Kyle R. Stanley, Python Core Developer (what is a core dev?
<https://devguide.python.org/coredev/>)
*Pronouns: they/them **(why is my pronoun here?*
<http://feministing.com/2015/02/03/how-us
bsolute 100%
certainty that no regressions or future unexpected issues will occur as a
result of the change.
Also, for fun, here's a pythonized version of the quote:
“[Guido] said that I was the wisest of all the [pythonistas]. It is because
I alone, of all the [pythonistas], know that I know
On Sun, Jun 6, 2021 at 7:09 PM Dan Stromberg wrote:
> I've got a comparison of sort algorithms in both Cython and Pure Python
> (your choice) at:
> https://stromberg.dnsalias.org/~strombrg/sort-comparison/
> ...including a version of timsort that is in Cython or Pure Python.
>
Thanks for sharing
As someone who's had to make use of the pattern `_sentinel = object()` a
few times within stdlib code, I'd like to give a strong +1 for the proposal
to add a new `sentinel()` function. This is much more intuitive, easier to
look up, etc. From my experience, it's a common enough pattern to be well
With Loving Regards,
--
--Kyle R. Stanley, Python Core Developer (what is a core dev?
<https://devguide.python.org/coredev/>)
*Pronouns: they/them **(why is my pronoun here?*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c
have overcome past struggles*
.
--
--Kyle R. Stanley, Python Core Developer (what is a core dev?
<https://devguide.python.org/coredev/>)
*Pronouns: they/them **(why is my pronoun here?*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-ch
On Jan 20, 2021 at 9:51 PM Chros Jerdonek wrote:
> Is there / would it make sense to have a section analogous to "Porting to
> Python X" that covers "Make All DeprecationWarnings Go Away in X"? If we
> had such a section, the "Porting to" section could be constructed by
> copying the relevant bit
Thanks for bringing attention to this, Victor, and to Ken Jin (GH:
Fidget-Spinner) for the PR. I've just completed reviewing and merging the
PR, so hopefully anyone affected will now have a more clear idea of how to
migrate their asyncio code to 3.10. Having the porting method explicitly
documented
On Sun, Nov 15, 2020 at 1:56 AM Chris Angelico wrote:
> On Sun, Nov 15, 2020 at 4:28 PM Kyle Stanley wrote:
> >
> > FWIW, I'd like to add my +1 to usage of "as" for spelling class capture
> patterns. This is by far the clearest and easiest to read form I'
On Sat, Nov 14, 2020 at 7:54 AM Nick Coghlan wrote:
> On Sat, 14 Nov 2020 at 09:51, Greg Ewing
> wrote:
> >
> > On 14/11/20 7:45 am, Brandt Bucher wrote:
> > > with (using your own syntactic flavor):
> > > ```
> > > case >first, *>middle, >last:
> > > rebuilt = first, *middle, last
> > > ca
Rather than trying to specifically transform the existing tutorial into a
guide exclusively aimed at beginners, I think that we should use the
guideline of: "Is this useful information in 95% of real-world use cases or
does it have a strong niche purpose that will be useful at *some *point for
sig
On Sun, Nov 8, 2020 at 8:17 PM Inada Naoki wrote:
> OK. Since checking all mails in the long thread is tedious job, I will
> pick some up and leave a comment in the b.p.o.
>
Personally, I think that just linking to the python-dev thread in bpo
(and/or PR) is adequate for most cases, especially i
I can't speak for all of the members of the upcoming documentation WG, but
as someone that will be on it (based on our discussions at the recent core
dev sprint), my personal vote would be for keeping it as a comprehensive
guide for beginners of Python. Detailed enough that it covers the
fundamenta
+1 to remove support for Solaris going forward. 4 years is plenty of time
to wait for someone to volunteer to maintain it, IMO. So my preference
would be for option 3 to remove it now, but I wouldn't be opposed to option
2 either w/ deprecating support and waiting a couple versions to remove it.
I'
Thanks, Justin! I'll look over your PR, try to replicate the failure
locally, and test it against the patch to see if it still occurs. I think
your analysis of the issue makes sense, with it likely being a race
condition between the test prototype "MyProto" and the event loop.
On Thu, Oct 15, 2020
On Fri, Oct 2, 2020 at 2:07 AM Kyle Stanley wrote:
> Prior to joining Python Discord, I recommend checking out the Discord
> setup guide that I recently finished:
> https://python-core-sprint-2020.readthedocs.io/communication.html#discord-setup-guide.
> The part on the privacy
scord.gg/Q87A9Y9.
As a reminder, potential participants include Python core developers,
triagers, and those in a core dev mentorship. If you haven't already signed
up and are interested in attending, please do so at
https://forms.gle/fhzJdpRHR4GtSRCk9.
Regards,
Kyle Stanley
__
Thanks for reverting the setuptools version Ned, and to Victor for opening
a PR to make the fix for the latest version. I'm always amazed by the
efforts made and quick responses to keep things running smoothly. :-)
On Tue, Sep 1, 2020 at 5:56 AM Ned Deily wrote:
> On Sep 1, 2020, at 05:47, Ned D
limitation, but for the purposes of scheduling the best
possible times for everyone, it is requested that participants do so at
their earliest convenience.
Regards,
Kyle Stanley
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an
What exactly does the PR involve? Is it a relatively simple compatibility
patch or something that adds significant amounts of platform-specific code?
The former can be reviewed (and potentially merged) by any core dev
knowledgeable in the areas being changed, but the latter requires long-term
suppo
>
> I'm using my mailer's "ignore thread" feature and counting on the fact
> that the flamers will eventually exhaust themselves (most already have).
>
Yep, not all threads are going to be equally worthwhile for everyone to
read. If a thread is going nowhere productive, the best course of action i
> Basically, it feels like we were lied to. And if that wasn't bad enough,
to see that Guido accepted that vitriolic commit message and merged it in
... it makes me embarrassed to be a Python supporter.
Only Guido could attest to this, but as someone who spoke in support of the
change, I personal
I tend to keep out of these types of discussions because they have a
tendency to be rather polarizing, and when introduced in an unrelated
environment (such as python-ideas or python-dev), tend to do nothing other
than set people against each other. But, after the above message, I feel
obligated to
Thank you very much to Brandt, Tobias, Ivan, Guido, and Talin for the
extensive work on this PEP. The attention to detail and effort that
went into establishing the real-world usefulness of this feature (such
as the many excellent examples and code analysis) helps a lot to
justify the complexity of
to be a bit more
vigilant in ensuring that everyone has had a chance to migrate from those
APIs, and delaying the removal if not.
On Sun, Jun 14, 2020 at 9:34 PM Inada Naoki wrote:
> On Sat, Jun 13, 2020 at 8:20 PM Inada Naoki
> wrote:
> >
> > 2020年6月13日(土) 20:12 Kyle Stanley
rnings have already been in place. +1.
On Sat, Jun 13, 2020 at 7:20 AM Inada Naoki wrote:
>
>
> 2020年6月13日(土) 20:12 Kyle Stanley :
>
>> > Additionally, raise DeprecationWarning runtime when these APIs are used.
>>
>> So, just to clarify, current usage of th
> Additionally, raise DeprecationWarning runtime when these APIs are used.
So, just to clarify, current usage of these 7 unicode APIs does not emit
any warnings and would only start doing so in 3.10? If so, I think we may
want to consider giving users until 3.12 until they're removed. Especially
w
> In light of the release of Python 3.9b1, let’s take a moment to celebrate
all the great work that our Python 3.8 and 3.9 release manager Łukasz has
done.
Thank you so much to Łukasz for a fantastic 3.8 release, and for the smooth
transition into 3.9 beta. :-)
> Please join me in welcoming Pablo
Serhiy Storchaka wrote:
> I propose to deprecate these functions and remove them in future Python
versions.
+1, assuming the deprecation lasts for at least two versions and the
available alternatives are explicitly mentioned in the What's New
entry (for both the version they're initially deprecate
Mark Shannon wrote:
> If `run()` can raise
> an exception, why not let it return values?
If there's not an implementation detail that makes this impractical,
I'd like to give my +1 on the `Interpreter.run()` method returning
values. From a usability perspective, it seems incredibly convenient
to h
Eric Snow wrote:
> We will mark it "provisional" in the docs, which I expect will include
> info on what that means and why it is provisional.
If you'd like an example format for marking a section of the docs as
provisional w/ reST, something like this at the top should suffice
(with perhaps somet
Raymond Hettinger wrote:
> Yes, I get that. Just want to point-out that working with heavily
nested dictionaries (typical for JSON) is no fun with square brackets and
quotation marks.
I can certainly agree with that sentiment, especially when working with
something like GraphQL that tends to ret
Guido van Rossum wrote:
> I've seen this pattern a lot at a past employer, and despite the obvious
convenience I've come to see it as an anti-pattern: for people expecting
Python semantics it's quite surprising to read code that writes foo.bar and
then reads back foo['bar'].
Would it be significan
Looking over the commit history for the PR (
https://github.com/python/cpython/pull/18239/commits), it looks like that
specific Azure Pipelines failure did not start occurring until
upstream/master was merged into the PR branch (
https://github.com/python/cpython/pull/18239/commits/13d3742fd897e1ea
Ivan Pozdeev wrote:
> More information is not better if that information is harmful rather than
helpful.
While that argument does apply in some cases, I'd have to very much
disagree that "" is harmful in comparison to just "1";
it clearly shows the value on the right side of the colon. As for the
> -1 on "cut*" (feels too much like what .partition() does)
> -0 on "trim*" (this is the name used in .NET instead of "strip", so I
> foresee new confusion)
> +1 on "remove*" (because this is exactly what it does)
I'm also most strongly in favor of "remove*" (out of the above options).
I'm opposed
islower',
'isnumeric', 'isprintable', 'isspace', 'istitle', 'isupper', 'join',
'ljust', 'lower', 'lstrip', 'maketrans', 'partition', 'replace', 'rfind',
'
Ivan Pozdeez wrote:
> I must note that names conforming to
https://www.python.org/dev/peps/pep-0008/#function-and-variable-names would
be "strip_prefix" and "strip_suffix".
In this case, being in line with the existing string API method names take
priority over PEP 8, e.g. splitlines, startswith,
Nick Coghlan wrote:
> The example where the new function was used instead of a questionable use
of replace gave me an idea, though: what if the new functions were
"replacestart()" and "replaceend()"?
>
> * uses "start" and "with" for consistency with the existing checks
> * substring based, like th
andard library, such as with asyncio and concurrent.futures. Although
it's relevant, it's very different in terms to implementation details.
Also, I'm substantially more interested in the Python parts of the stdlib
rather than the C internals or extension modules, but I certainly ha
rn in
the context of subinterpreters. If we could also see example(s) which
address those scenarios with a thread-local variable instead of a tstate
parameter, I think it would allow for more objective comparison between
them.
Regards,
Kyle Stanley
On Wed, Mar 18, 2020 at 6:36 AM Mark Shannon wrot
Thanks for adding the new section, Brett. :)
Was the name "Core Development" also considered? To me, it seems like "Core
Dev" could be interpreted as abbreviating "Core Developer", which seems
roughly equivalent to the existing "Committers" category (at least based on
the name alone). I'm sure tha
> In most cases of a first-time poster that I've seen, the poster probably
doesn't have the understanding needed to conduct a proper search of the
mailing list. That's why I suggest responding with some genuine help (i.e.
taking their idea at face value and explaining what's wrong with it).
It mig
> So I've also never come across "|=" being used for this purpose.
IIRC, the JavaScript implementation of "|=" can potentially be used in the
way Claudio described it, instead it's based on the truthiness of the
left-hand operand rather than it being "unset". But it works in that
context because "
m to be mildly in conflict of one another regarding the CLA policy.
[2] - Discretion to determine triviality based on best judgement, and
whether or not they personally consider merging any PRs without the CLA
signed.
On Mon, Feb 24, 2020 at 1:54 PM Terry Reedy wrote:
> On 2/23/2020 11:44 PM, Gu
r as
I can tell). As mentioned in the OP, I don't have an especially strong
opinion on how it should be handled. More than anything, I'd just like the
policy to be made clear for future PRs so that I can provide an accurate
answer to newer contributors.
On Sun, Feb 23, 2020 at 11:44 PM Guid
opened it, and then
the label updated to signed within a couple days after signing the CLA.
This has also been the case in the majority of PRs I've reviewed from
first-time contributors.
On Sun, Feb 23, 2020 at 11:24 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
>
>
ntext, but I tend to prefer the former. IMO, it comes
across as more respectful to the efforts made by the author, as even the
smallest of PRs can require substantial efforts from first-time
contributors that are entirely unfamiliar with the workflow; regardless of
how sm
Thanks for bring attention to these PRs, Brandt! I think the second one
should be particularly uncontroversial, seeing as it's just applying PEP
409 (raise from None) to an existing exception in an argparse unit test to
clean up some unhelpful context clutter in the traceback.
On Thu, Feb 20, 2020
Hey Chaitanya,
The "python-dev" mailing list is specifically for the development *of*
Python itself, not for general help with Python. "comp.lang.python" or
"python-help" is more likely the list you're looking for.
Also, for general information on the purpose of each of the primary mailing
lists,
t; actually within our control, so it'll be recreated automatically.
Thanks for the advice! I figured this would be the best option in this
situation, but since I wasn't sure about how exactly the agents worked, it
seemed like a good idea to ask first.
On Sat, Feb 1, 2020 at 6:27 AM Steve D
In a recent PR (https://github.com/python/cpython/pull/18057), I received
the following error message in the Azure Pipelines build results:
##[error]We stopped hearing from agent Azure Pipelines 5. Verify the agent
machine is running and has a healthy network connection. Anything that
terminates a
On the attendance application, there is currently an incorrect link to the
informational page for the Language Summit: "
https://us.pycon.org/2020/events/language-summit/";.
Either the link could be changed to "
https://us.pycon.org/2020/events/languagesummit/"; or "
https://us.pycon.org/2020/even
> The only `OrderedSet` use I have seen in the wild is
https://github.com/python-hyper/uritemplate/search?q=orderedset&unscoped_q=orderedset
.
A more generalized Python code search across GitHub of "orderedset" returns
~500k results: https://github.com/search?l=Python&q=orderedset&type=Code .
Of
Tim Peters wrote:
> Sorry! A previous attempt to reply got sent before I typed anything :-(
No worries, I only saw the link in the footer to the PSF CoC, and I was
mildly concerned for a moment. My first thought was "Oh no, what did I
do?". Thanks for clearing that up (:
> The collision resoluti
10.22558353268
Some more in-depth comparisons might be required for addition of single
items to the containers. I might experiment further with this at some point
in the next week or so, likely with implementing proper tests that omit the
time to initialize the container.
On Mon, De
the "Add" ones. This
should provide a decent general idea though.
On Mon, Dec 23, 2019 at 8:12 PM Guido van Rossum wrote:
> To begin with, please compare performance of dict-with-None-values to that
> of a set, for operations that can be expressed by both (e.g. both have
> up
Larry Hastings wrote:
> a hypothetical collections.OrderedSet would probably work just fine.
I'm also in agreement with adding a collections.OrderedSet. There certainly
seems to be a practical use case for a Set that preserves insertion order,
but with significant push back to modifying the existi
Kyle Stanley wrote:
> or making *object* a positional only argument.
Typo: I meant "positional only parameter", not "argument".
On Mon, Dec 16, 2019 at 4:39 AM Kyle Stanley wrote:
>
> Inada Naoki wrote:
> > If we find it broke some software, we can step back
Inada Naoki wrote:
> If we find it broke some software, we can step back to regular
> deprecation workflow.
> Python 3.9 is still far from beta yet. That's why I'm +1 on these
proposals.
IMO, since this would be changing a builtin function, we should at least
use a version+2 deprecation cycle (in
haka wrote:
> You can get an error here if you run Python with -bb. This is a
> temporary option to catch common errors of porting from Python 2.
Huh, interesting.
On Mon, Dec 16, 2019 at 3:59 AM Serhiy Storchaka
wrote:
> 16.12.19 02:55, Kyle Stanley пише:
> > I'd much pref
pect via string conversion.
Thanks for the insight.
On Mon, Dec 16, 2019 at 3:43 AM Eric V. Smith wrote:
> On 12/16/2019 3:05 AM, Kyle Stanley wrote:
>
> Chris Angelico wrote:
> > ANY object can be passed to str() in order to get some sort of valid
> > printable form. The awkw
as UTF-8, assume the user meant
str(bytes_obj, encoding='utf-8')
Personally, I'm more in favor of (1) since it's much more explicit and
obvious, but I think (2) would at least be more useful than the current
behavior.
On Sun, Dec 15, 2019 at 8:13 PM Chris Angelico wrote:
> On Mon,
Serhiy Storchaka wrote:
> Forbids calling str() without object if encoding or errors are
> specified. It is very unlikely that this can break a real code, so I
> propose to make it an error without a deprecation period.
+1, I suspect that nobody would intentionally pass an argument to the
encoding
that keeps the breakage from landing on
> master?
>
> On Thu, Dec 12, 2019 at 5:46 PM Kyle Stanley wrote:
>
>> Victor Stinner wrote:
>> > What is the issue? Can someone please open a bug report at
>> https://bugs.python.org/ so I can try to investigate?
>>
>>
Victor Stinner wrote:
> What is the issue? Can someone please open a bug report at
https://bugs.python.org/ so I can try to investigate?
>From my understanding, it looks to be pyenv related and not something we
can fix on our end, at least based on the build logs:
https://travis-ci.org/python/cpyt
ill worthwhile to write. I suspect that the topic of
"coroutine object limits" is likely to come up again in the future.
On Wed, Dec 11, 2019 at 4:46 PM Antoine Pitrou wrote:
> On Mon, 9 Dec 2019 21:42:36 -0500
> Kyle Stanley wrote:
>
> > > (b) Why limit corout
ith each
FD, but I believe this can be limited through the FD option F_SETPIPE_SZ (
https://linux.die.net/man/2/fcntl).
Note: I was unable to find a credible source on the minimum memory usage
per additional FD, so clarification on that would be appreciated.
On Wed, Dec 11, 2019 at
With the removal of the coroutine limit, I think that PEP 611 will be a lot
easier to consider. Personally, I've gone from -1 to +0. But, with the
class limit also being rather controversial, I think the PEP would benefit
significantly from backing that up with some form of analysis on memory
usage
7;re not (reasonably) configurable by most users, I would
consider that to further reinforce my previous statement that we should
have some form of concrete evidence; to prove that imposing the limits will
provide tangible benefits to the vast majority of Python users.
On Tue, Dec 10, 2019 at 4:45 AM S
Chris Angelico wrote:
> We have people who believe that a bit
> mask will slow things down, others who claim that improved cache
> locality will speed things up, and Mark asks us to please justify our
> objections with numbers. But surely it's up to Mark to show numbers
> first?
+1. While it would
> I also would suggest for PEP 611 that any limits are discoverable (maybe
in sys) so it can be used by other implementations like Jython.
I agree, I think that sys would likely be the most reasonable place to read
these limits from. Also, it seems like a good location for setting of the
limits, i
, 2019 at 10:17 PM Khazhismel Kumykov wrote:
>
>
> On Mon, Dec 9, 2019, 18:48 Kyle Stanley wrote:
>
>> > (b) Why limit coroutines? It's just another Python object and has no
>> operating resources associated with it. Perhaps your definition of
>> coroutine i
> (b) Why limit coroutines? It's just another Python object and has no
operating resources associated with it. Perhaps your definition of
coroutine is different, and you are thinking of OS threads?
This was my primary concern with the proposed PEP. At the moment, it's
rather trivial to create one
han closing+reopening the
PR. Restarting the checks is typically a last resort since intermittent
regression test failures are a concern, but it's highly useful when the
failure is occurring due to external factors (such as a recently merged PR
or issues with the CI service itself).
On Fri
Victor Stinner wrote:
> Isn't it already the current unwritten deprecation process?
Personally, I don't think we should rely on an unwritten process for
something as important and potentially breaking as a deprecation process.
Regardless of the outcome of this discussion, I think we should try to
Steve Dower wrote:
> As a related aside, I've been getting GitHub Actions support together
> (which I started at the sprints).
Would adding support for GitHub Actions make it easier/faster to
temporarily disable and re-enable specific CI services when they're having
external issues? IIUC, that see
> BTW, I think 2to3 can help to move from 2&3 code to 3-only code.
> Instead, we can do:
> * Don't recommend u-prefix except in Python 2&3 code.
> * Provide a tool to remove the u-prefix.
+1, this seems like the smoothest way of handling it and has very minimal
impact on users. In 5+ years from
> The number of live coroutines in a running interpreter.
Could you further elaborate on what is meant by "live coroutines"? My
guesses (roughly from most likely to least likely) would be:
1) All known coroutine objects in a state of either CORO_RUNNING or
CORO_SUSPENDED, but *not* CORO_CREATED
> I agree with Nick, this is indeed big, but not impossible. If you are not
sure yet whether you will work on implementation, you can focus on
polishing the PEP text, and then if it is accepted and you will decide to
give implementation to someone else, we will find a volunteer.
Unless I'm misunde
> This is all irrelevant if you haven't signed the CLA*.
IMO, this shouldn't be an argument against the proposed changes, as the CLA
is fairly straightforward and only takes 24-48 hours to process. Unless the
OP specifically is unable to or doesn't want to sign the CLA, it won't be a
significant c
> Probably python-list/comp.lang.python mailing list/news group is the
best place
Since this involves a potential suggested change (adding a feature to
assign custom headers to http.server), python-ideas or the "Ideas" section
of https://discuss.python.org/ would also be appropriate.
On Sat, Oct
> You don't need permission to support Python in a commercial IDE. It's
open source.
Adding to this, see
https://docs.python.org/3/license.html#terms-and-conditions-for-accessing-or-otherwise-using-python
for the complete licensing information on Python.
On a somewhat related note to the licensin
> Recently, I started to experiment "./python -m test [options] -F
-j100" to attempt to reproduce some tricky race conditions: -j100
spawns 100 worker processes in parallel and -F stands for --forever
(run tests in loop and stop at the first failure).
Interesting, even as someone who has recently
> Can you help with the "What's New" document?
After seeing this, I went through the whatsnew for 3.8 and found a couple
of typos and broken links (from Sphinx roles that were slightly off). I
opened a PR to fix as many as I was able to:
https://github.com/python/cpython/pull/16535. Raymond will b
nt for a decent while before I started contributing to Python).
This would be a non-issue with a public listing of core developer real
names -> GitHub usernames that isn't dependent on bpo.
On Wed, Sep 25, 2019 at 7:12 AM Victor Stinner wrote:
> Le mer. 25 sept. 2019 à 08:24, Kyle Stanley
> But I will say that listing our GitHub usernames with our real names is
not required to tell who is a core developer. In GitHub's UI there are
multiple places it will tell you if a person is a member of the
repository/team
Within the GitHub UI if you're not a member of the organization, it tells
Recently, Brett updated the developer log in the devguide
(https://devguide.python.org/developers/) to fetch the names of each core
developer and the date they were given commit privileges from the private
python-committers repository.
I think it would also be quite useful to include GitHub userna
> How easy would it be to search the sources and the docs for the ones
that are currently public but not documented?
Comparing the docs and .c files for functions that are not documented
would be fairly trivial, but it's very difficult to define something as
being
public if it's not documented, si
Benjamin, what are you thoughts on usage of the "needs backport to 2.7"
label? For most of the PRs I've reviewed I tend to avoid adding it myself,
but I've seen it used periodically. It seems to be used rather infrequently
(
https://github.com/python/cpython/pulls?q=is%3Apr+label%3A%22needs+backpor
Terry Jan Reedy wrote:
> "This installer also installs the multiversion py.exe launcher if doing
so would not be a downgrade. If you have admin access, we recommend
installing one py.exe for all users. See xxx for how to use py.exe.
[ ] Install py.exe for all users.
+1, Particularly on this pa
1 - 100 of 138 matches
Mail list logo
