D'oh! I have a second draft already.
Your NEWS entry should be written in the /present tense,/ and should
start with a verb:
* Add foo [...]
* Change bar [...]
* Remove bat [...]
* Fix buffalo.spam [...]
Function and class names should not be followed by
I'll wait to see if anybody else has contrary opinions, but for now
here's a first draft:
Your NEWS entry should be written in the present tense, and should
start with a verb:
* Added foo [...]
* Changed bar [...]
* Removed bat [...]
* Fixed buffalo.spam [...]
There’s something in the dev guide, but not about tense. Worth adding. (My
pet peeve is not to write “The foo module resets the bar state when spam
happens,” because that isn’t clear about whether that’s the before or after
behavior.)
On Thu, Apr 29, 2021 at 17:37 Ethan Furman wrote:
> On
On 4/29/21 7:57 PM, Larry Hastings wrote:
> When one writes one's "blurb" for the changelog, in what tense should it be?
Present tense. :)
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
When one writes one's "blurb" for the changelog, in what tense should it
be? I mostly see entries in present tense:
bpo-43660: Fix crash that happens when replacing sys.stderr with a
callable that can remove the object while an exception is being
printed. Patch by Pablo Galindo.
On 2021-04-29 18:56, Ethan Furman wrote:
On 4/29/21 10:52 AM, Antoine Pitrou wrote:
> On Thu, 29 Apr 2021 18:37:29 +0100, MRAB wrote:
>> On 2021-04-29 18:19, Ethan Furman wrote:
>>> An excerpt from bpo-31369: re.RegexFlag and `__all__`
>>>
>>> GvR:
>>>
>>>> One thing I
On Fri, Apr 30, 2021 at 4:28 AM Jonathan Goble wrote:
>
> On Thu, Apr 29, 2021 at 2:00 PM Ethan Furman wrote:
>>
>> On 4/29/21 10:35 AM, Jonathan Goble wrote:
>> > On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote:
>>
>>
>> >> Which raises the question: Do we want to have a standard name for
On Thu, Apr 29, 2021 at 2:00 PM Ethan Furman wrote:
> On 4/29/21 10:35 AM, Jonathan Goble wrote:
> > On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote:
>
>
> >> Which raises the question: Do we want to have a standard name for
> stdlib Flags when no flags are set?
> >
> > If you want a
On 4/29/21 10:35 AM, Jonathan Goble wrote:
> On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote:
>> Which raises the question: Do we want to have a standard name for stdlib
Flags when no flags are set?
>
> If you want a flag to represent no flags set, it takes one line to write it
yourself,
On 4/29/21 10:52 AM, Antoine Pitrou wrote:
> On Thu, 29 Apr 2021 18:37:29 +0100, MRAB wrote:
>> On 2021-04-29 18:19, Ethan Furman wrote:
>>> An excerpt from bpo-31369: re.RegexFlag and `__all__`
>>>
>>> GvR:
>>>
>>>> One thing I discovered when developing this example: there doesn't
On Thu, 29 Apr 2021 18:37:29 +0100
MRAB wrote:
> On 2021-04-29 18:19, Ethan Furman wrote:
> > An excerpt from bpo-31369: re.RegexFlag and `__all__`
> >
> > GvR:
> >
> > > One thing I discovered when developing this example: there doesn't seem
> > to be a flag to
> > > represent 0
On 2021-04-29 18:19, Ethan Furman wrote:
An excerpt from bpo-31369: re.RegexFlag and `__all__`
GvR:
> One thing I discovered when developing this example: there doesn't seem to
be a flag to
> represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even
though it works
>
On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote:
> An excerpt from bpo-31369: re.RegexFlag and `__all__`
>
> GvR:
>
> > One thing I discovered when developing this example: there doesn't seem
> to be a flag to
> > represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even
>
An excerpt from bpo-31369: re.RegexFlag and `__all__`
GvR:
> One thing I discovered when developing this example: there doesn't seem to be
a flag to
> represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even though
it works
> fine at runtime).
Which raises the question: Do
Hello,
I've merged the main part of PEP-652 implementation. The Limited C API
(introduced in PEP 384 and used for extension modules that work across
Python versions without recompilation) is now explicitly defined and
better tested.
When changing/extending the limited API:
- Stop and think!
On Wed, Apr 28, 2021 at 8:53 PM Nathaniel Smith wrote:
> Looking at the relevant section of the PEP again [1], it notes the
> same fatal flaw with my first suggestion, and then says that the
> multiple-except-executions option should be rejected because users
> have written code like 'except
16 matches
Mail list logo
