This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Use of ternary operator instead of if and else in month calculation function
Type: Stage: resolved
Components: Library (Lib) Versions: Python 3.10, Python 3.9, Python 3.8, Python 3.7, Python 3.6
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: ElianMariano, serhiy.storchaka, steven.daprano
Priority: normal Keywords: patch

Created on 2020-11-22 19:46 by ElianMariano, last changed 2022-04-11 14:59 by admin. This issue is now closed.

File name Uploaded Description Edit ElianMariano, 2020-11-22 19:46
Pull Requests
URL Status Linked Edit
PR 23468 closed ElianMariano, 2020-11-22 19:56
Messages (3)
msg381629 - (view) Author: Elian Mariano Gabriel (ElianMariano) * Date: 2020-11-22 19:46
Inside the file, there are two functions which are supposed to calculate the previous and next month relative to the actual year and month.

def _prevmonth(year, month):
    if month == 1:
        return year-1, 12
        return year, month-1

def _nextmonth(year, month):
    if month == 12:
        return year+1, 1
        return year, month+1

Because of the concise calculation that is being made by these functions, it would be convenient to use the ternary operator to calculate that. So, the result would be:

def _prevmonth(year, month):
    return [year-1, 12] if month == 1 else [year, month-1]

def _nextmonth(year, month):
    return [year+1, 1] if month == 12 else [year, month+1]
msg381631 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2020-11-22 20:25
Why do you care what the implementation of the private methods are? Does it make them faster or fix a bug? How is it "convenient" to change the implementation to ternary if?

Without some better justification, this strikes me as just code churn for no benefit, but the risk of breaking things. For example, you changed the result from a tuple to a list.

Will this break anything? I don't know, but it will take time to find out, and with no obvious benefit to the change, spending that time to find out if this is a safe change is effort for no visible benefit.
msg381633 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-11-22 20:34
I concur with Steven. We usually reject pure cosmetic changes. And I do not see any advantages of the new code.
Date User Action Args
2022-04-11 14:59:38adminsetgithub: 86605
2020-11-22 20:34:59serhiy.storchakasetstatus: open -> closed

nosy: + serhiy.storchaka
messages: + msg381633

resolution: rejected
stage: patch review -> resolved
2020-11-22 20:25:23steven.dapranosetnosy: + steven.daprano
messages: + msg381631
2020-11-22 19:56:46ElianMarianosetkeywords: + patch
stage: patch review
pull_requests: + pull_request22358
2020-11-22 19:46:39ElianMarianocreate