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
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
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,
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
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
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:
>
>
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
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
> 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 "
> 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
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
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
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
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
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,
islower',
'isnumeric', 'isprintable', 'isspace', 'istitle', 'isupper', 'join',
'ljust', 'lower', 'lstrip', 'maketrans', 'partition', 'replace', 'rfind',
'
> -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
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
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
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
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
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
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
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
> 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
> 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
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
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
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
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
> 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'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
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
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
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
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
__
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
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
101 - 138 of 138 matches
Mail list logo
