[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Yury Selivanov]

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 SomeError: ...' with the expectation
> that the 'except' clause would run exactly once. That's definitely
> true, and it's a downside of the multiple-except-executions approach,
> but I don't think it's convincing enough to rule this out on its own.
> The problem is, *all* our options for how 'except' should interact
> with ExceptionGroups will somehow break previous expectations.

Well, this is where we respectfully disagree. The case of changing how
the regular try..except works in a backwards incompatible way is a
very convincing blocker to us.

>
> Concretely: imagine you have a pre-existing 'except SomeError', and
> some new code inside the 'try' block raises some number of
> 'SomeError's wrapped in an ExceptionGroup. There are three options:
>
> - Execute the 'except' block multiple times. This breaks the
> expectation that it should be executed at most once.
> - Execute the 'except' block exactly once. But if there are multiple
> SomeError's, this require they be grouped and delivered as a single
> exception, which breaks typing.
> - Execute the 'except' block zero times. This is what the current PEP
> chooses, and breaks the expectation that 'except SomeError' should
> catch 'SomeError'.
>
> So we have to pick our poison.

We did. The PEP talks at length as to why this isn't a problem.

> > I'm confused about the flattening suggestion - above you talk about "flat 
> > EG", but below about tracebacks. It's not clear to me whether you want EG 
> > to be flat (ie no nesting of EGs) or just the traceback to be flat (but you 
> > can still have a nested EG).
>
> Hmm, I was thinking about making both of them flat, so no nested EGs.
> In all my designs, the only reason I ever had nesting was because I
> couldn't figure out any other way to make the tracebacks work. Do you
> have some other motivation for wanting nesting? If so that would be
> interesting, because it might point to why we're talking past each
> other and help us understand the problem better...
>
> > I also don't know what problem you are trying to solve with this.
>
> I'm not saying that there's some fatal problem with the current PEP.
> (In my first message I explicitly said that it would be an improvement
> over the status quo :-).) But I think that nesting will be really
> counterintuitive/confusing for users in some ways. And concurrency
> APIs will be offputting if they force you to use a different special
> form of 'except' all the time. Basically the 'flat' version might be a
> lot more ergonomic, and that's important for a language like Python.

You keep saying that your idea of flat EGs is "ergonomic" and
"important for a language like Python". The problem is that after all
these emails I still have absolutely no idea about:

- what exactly are you trying to propose?
- what specific problem do you want to address? (that the current PEP,
in your opinion, does not address)
- why do you think that what you propose would be more ergonomic or simple?
- what "flat EGs" or "flat tracebacks" even mean; I can't figure out
not only the high level API, I don't even understand what you're
talking about at the data structures level.

Nathaniel, at this point it's clear that this thread somehow does not
help us understand what you want. Could you please just write your own
PEP clearly outlining your proposal, its upsides and downsides?
Without a PEP from you this thread is just a distraction.


Yury
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AR737RYK2KCTATCBW3QSDK5SSF7CH75M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 652: Python 3.10 will have explicit Limited C API & Stable ABI

[Petr Viktorin]

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! This API will  need to be suppported forever (or until 
Python 3 reaches end of life, if that comes sooner). A checklist of what 
to think about is being added to the devguide [0].

- Add/change an entry in `Misc/stable_abi.txt`.
- Run `make regen-limited-abi` [sic].

You can run related checks with `make check-limited-abi`. If that or the 
"Check if generated files are up to date" CI test gives you errors, 
please let me know!


More tests & docs are coming up.

[0]: https://cpython-devguide--682.org.readthedocs.build/c-api/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/W5QG2I2IQXQDPMCFMRDUMGCEX5MX6PHA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] stdlib Flag Enums and the "no value" member

[Ethan Furman]

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 we want to have a standard name for stdlib Flags 
when no flags are set?

What should we call it?

- NONE

- ZERO

- EMPTY

- ???

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ACZOZLWJRW7PTVURJWU3LN6UYVTIBENL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

[Jonathan Goble]

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
> though it works
>  > fine at runtime).
>
> Which raises the question:  Do we want to have a standard name for stdlib
> Flags when no flags are set?
>
> What should we call it?
>
> - NONE
>
> - ZERO
>
> - EMPTY
>
> - ???
>

If you want a flag to represent no flags set, it takes one line to write it
yourself, as in this example I copied verbatim from the docs:

>>> class Color(Flag):
... BLACK = 0
... RED = auto()
... BLUE = auto()
... GREEN = auto()
...
>>> Color.BLACK

>>> bool(Color.BLACK)
False
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UXRKQQWM5HY6ECBBAQ2RUK2TNRJ2AQTT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

[MRAB]

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
  > fine at runtime).

Which raises the question:  Do we want to have a standard name for stdlib Flags 
when no flags are set?

What should we call it?

- NONE

- ZERO

- EMPTY

- ???


Definitely NONE. At some point I might even add it to the regex module! :-)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RBZ7ILB64FBFEHFQNHKGHJLYNUU3DMET/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

[Antoine Pitrou]

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 (zero), i.e. "no flags".  And foo(0) is a type error (even 
> > though it works
> >   > fine at runtime).  
> > 
> > Which raises the question:  Do we want to have a standard name for stdlib 
> > Flags when no flags are set?
> > 
> > What should we call it?
> > 
> > - NONE
> > 
> > - ZERO
> > 
> > - EMPTY
> > 
> > - ???
> >   
> Definitely NONE. At some point I might even add it to the regex module! :-)

Not to confuse with None, which will not be equal to NONE.  Hmm...

Perhaps NONE_SET or ALL_UNSET?

(also, why the ALL_CAPS?)

Regards

Antoine.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VWCFG3B4U6IB6TXZO7L2YQSOAVXBJ57N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

[Ethan Furman]

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 
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 we want to have a standard name for stdlib 
Flags when no flags are set?
>>>
>>> What should we call it?
>>>
>>> - NONE
>>>
>>> - ZERO
>>>
>>> - EMPTY
>>>
>>> - ???
>>>
>> Definitely NONE. At some point I might even add it to the regex module! :-)
>
> Not to confuse with None, which will not be equal to NONE.  Hmm...
>
> Perhaps NONE_SET or ALL_UNSET?
>
> (also, why the ALL_CAPS?)

Since Enum members are constants, ALL_CAPS is recommended for their naming 
scheme.

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WEGL7HPVCLD54QH622WZZLASFIJVE27Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

[Ethan Furman]

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, as in this example I copied
> verbatim from the docs:
>
>  >>> class Color(Flag):
> ... BLACK = 0
> ... RED = auto()
> ... BLUE = auto()
> ... GREEN = auto()
> ...
>  >>> Color.BLACK
> 
>  >>> bool(Color.BLACK)
> False

Are you suggesting that the standard name for 0 be 'BLACK'?  ;-)

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/U365WUWGJBGFVMEXUQUFRPHAONTB7CJP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

[Jonathan Goble]

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 flag to represent no flags set, it takes one line to
> write it yourself, as in this example I copied
>  > verbatim from the docs:
>  >
>  >  >>> class Color(Flag):
>  > ... BLACK = 0
>  > ... RED = auto()
>  > ... BLUE = auto()
>  > ... GREEN = auto()
>  > ...
>  >  >>> Color.BLACK
>  > 
>  >  >>> bool(Color.BLACK)
>  > False
>
> Are you suggesting that the standard name for 0 be 'BLACK'?  ;-)
>

Any color you want as long as it's BLACK. ;-)

But seriously, my point is that it's already trivially possible for enum
authors to give the zero case a name of their own choosing that makes sense
for their use case, so we don't need special automatic names for it. The
one obvious way to do it, and the explicit way to do it, is to define your
own name to be equal to zero. Creating an automatic name for zero now,
after the enum module is well-established, violates the Zen of Python in at
least three, possibly four ways:

- it's implicit behavior (compared to the explicitness of defining your own
name)
- it violates the "one obvious way to do it" principle (I can conceivably
see arguments developing in the community over whether the automatic name
should be preferred or if one should write an explicit name for zero, as
neither is clearly and obviously better than the other)
- it requires a special case for backward compatibility with the
@enum.unique decorator
- it's arguably ambiguous what object should be returned for foo(0) when an
explicit name is defined (due to the documented behavior that a second name
for the same value is an alias for the first; is the automatic name created
first or last?)

So I don't see any compelling argument for giving an automatic name for
zero. Just define your own name. It takes five seconds and one line, with
essentially zero cost to maintainability.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/T3CHW4BTC4K7B5SGZUEFV5JSNCLO3YND/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

[Chris Angelico]

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 
>> 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, as in this example I copied
>>  > verbatim from the docs:
>>  >
>>  >  >>> class Color(Flag):
>>  > ... BLACK = 0
>>  > ... RED = auto()
>>  > ... BLUE = auto()
>>  > ... GREEN = auto()
>>  > ...
>>  >  >>> Color.BLACK
>>  > 
>>  >  >>> bool(Color.BLACK)
>>  > False
>>
>> Are you suggesting that the standard name for 0 be 'BLACK'?  ;-)
>
>
> Any color you want as long as it's BLACK. ;-)
>
> But seriously, my point is that it's already trivially possible for enum 
> authors to give the zero case a name of their own choosing that makes sense 
> for their use case, so we don't need special automatic names for it. The one 
> obvious way to do it, and the explicit way to do it, is to define your own 
> name to be equal to zero. Creating an automatic name for zero now, after the 
> enum module is well-established, violates the Zen of Python in at least 
> three, possibly four ways:
>
> - it's implicit behavior (compared to the explicitness of defining your own 
> name)
> - it violates the "one obvious way to do it" principle (I can conceivably see 
> arguments developing in the community over whether the automatic name should 
> be preferred or if one should write an explicit name for zero, as neither is 
> clearly and obviously better than the other)
> - it requires a special case for backward compatibility with the @enum.unique 
> decorator
> - it's arguably ambiguous what object should be returned for foo(0) when an 
> explicit name is defined (due to the documented behavior that a second name 
> for the same value is an alias for the first; is the automatic name created 
> first or last?)
>

OTOH, zero is already supported. If you create a flag without defining
a zero entry, it implicitly gets one with the name None.

>>> class Color(Flag):
... RED = auto()
... BLUE = auto()
... GREEN = auto()
...
>>> c = Color.GREEN|Color.BLUE
>>> c

>>> c &= Color.GREEN
>>> c

>>> c &= Color.BLUE
>>> c

>>> c.name
>>> c.value
0

It makes good sense to have an actual name for it.

If the automatic/default name (Color.NONE or whatever name it gets) is
considered to be created at the very end of the class definition, this
would resolve the ambiguity. And unique() could simply prevent the
creation of NONE if there's anything else (eg Color.BLACK) with the
value of zero.

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QBWVLDC752PFAADMAM4GYIJGJ7USTRHA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

[MRAB]

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 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 we want to have a standard name for stdlib 
Flags when no flags are set?
  >>>
  >>> What should we call it?
  >>>
  >>> - NONE
  >>>
  >>> - ZERO
  >>>
  >>> - EMPTY
  >>>
  >>> - ???
  >>>
  >> Definitely NONE. At some point I might even add it to the regex module! :-)
  >
  > Not to confuse with None, which will not be equal to NONE.  Hmm...
  >
  > Perhaps NONE_SET or ALL_UNSET?
  >
  > (also, why the ALL_CAPS?)

Since Enum members are constants, ALL_CAPS is recommended for their naming 
scheme.


And the flags of the re module have always been ALL_CAPS.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DCKIHYXVZIRABF43M3NX75RZAXIQ3AOV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] In what tense should the changelog be written?

[Larry Hastings]

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.

   bpo-41561: Add workaround for Ubuntu’s custom OpenSSL security level
   policy.

But occasionally I see entries in past tense:

   bpo-26053: Fixed bug where the pdb interactive run command echoed
   the args from the shell command line, even if those have been
   overridden at the pdb prompt.

   bpo-40630: Added tracemalloc.reset_peak() to set the peak size of
   traced memory blocks to the current size, to measure the peak of
   specific pieces of code.

I couldn't find any guidance in the Python Dev Guide after sixty seconds 
of poking around.



Obviously this isn't a big deal.  But it might be nice to try and nudge 
everybody in the same direction.  It'd be pleasant if the changelog read 
in a more unified voice, and using the same tense and sentence structure 
would help towards that goal.


If we arrived at a firm decision, maybe "blurb" et al could add a little 
text suggesting the proper style.



Cheers,


//arry/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SUEPLPRN2IY7EGC7XBLWWN2BOLM3GYMQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: In what tense should the changelog be written?

[Ethan Furman]

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 python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AM3TQUXVNKGOAEC2GBVNUZAZOCLAD6N3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: In what tense should the changelog be written?

[Guido van Rossum]

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 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 python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/AM3TQUXVNKGOAEC2GBVNUZAZOCLAD6N3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FNV3QHWZCNAHPNLR3SPTOGUFEYHJSYEK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: In what tense should the changelog be written?

[Larry Hastings]

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 [...]

   Function and class names should not be followed by parentheses,
   unless demonstrating an example call.



//arry/

On 4/29/21 9:15 PM, Guido van Rossum wrote:
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 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 python-dev-le...@python.org

https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/AM3TQUXVNKGOAEC2GBVNUZAZOCLAD6N3/


Code of Conduct: http://python.org/psf/codeofconduct/


--
--Guido (mobile)

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FNV3QHWZCNAHPNLR3SPTOGUFEYHJSYEK/
Code of Conduct: http://python.org/psf/codeofconduct/



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DOL55BKC7FNLZCDPKRXLW6PT5EADZXQ3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: In what tense should the changelog be written?

[Larry Hastings]

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 parentheses,
   unless demonstrating an example call.


Slapping my forehead,


//arry/


On 4/29/21 9:50 PM, Larry Hastings wrote:



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 [...]

Function and class names should not be followed by parentheses,
unless demonstrating an example call.



//arry/

On 4/29/21 9:15 PM, Guido van Rossum wrote:
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 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 python-dev-le...@python.org

https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/AM3TQUXVNKGOAEC2GBVNUZAZOCLAD6N3/


Code of Conduct: http://python.org/psf/codeofconduct/


--
--Guido (mobile)

___
Python-Dev mailing list --python-dev@python.org
To unsubscribe send an email topython-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-dev@python.org/message/FNV3QHWZCNAHPNLR3SPTOGUFEYHJSYEK/
Code of Conduct:http://python.org/psf/codeofconduct/





___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YC6NJT4J6GBD37FJZGP6DC26TWUSSLGE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: In what tense should the changelog be written?

[Serhiy Storchaka]

30.04.21 05:57, Larry Hastings пише:
> When one writes one's "blurb" for the changelog, in what tense should it
> be?

See the previous discussion on this topic:
https://mail.python.org/archives/list/python-dev@python.org/thread/C342Y73LALVFLI2ACFB3SH6ZDT2YTGPC/
.

I always use "fixed", "removed", "added" when describe changes following
the rule formulated by Oleg Broytman:

> I use past tense to describe what I did on the code, and present
> simple to describe what the new code does when running.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6SXYOA73FGFRP4HND6UM6SXGT23ZH7PS/
Code of Conduct: http://python.org/psf/codeofconduct/