compiler need support in(de)crement operation or all of it should have syntax error.

[shihai1991]

BPO	37304
Nosy	@ericvsmith, @stevendaprano, @shihai1991
PRs	compiler dosen't support in(de)crement operation #18292 bpo-37304: compiler dosen't support in(de)crement operation #18297

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-06-16.10:20:41.063>
created_at = <Date 2019-06-16.09:46:23.098>
labels = ['interpreter-core', 'type-bug', '3.9']
title = 'compiler need support in(de)crement operation or all of it should have syntax error.'
updated_at = <Date 2020-01-31.15:48:24.761>
user = 'https://github.com/shihai1991'

bugs.python.org fields:

activity = <Date 2020-01-31.15:48:24.761>
actor = 'shihai1991'
assignee = 'none'
closed = True
closed_date = <Date 2019-06-16.10:20:41.063>
closer = 'steven.daprano'
components = ['Interpreter Core']
creation = <Date 2019-06-16.09:46:23.098>
creator = 'shihai1991'
dependencies = []
files = []
hgrepos = []
issue_num = 37304
keywords = []
message_count = 8.0
messages = ['345738', '345739', '345742', '345754', '345759', '361110', '361113', '361117']
nosy_count = 3.0
nosy_names = ['eric.smith', 'steven.daprano', 'shihai1991']
pr_nums = ['18292', '18297']
priority = 'normal'
resolution = 'wont fix'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue37304'
versions = ['Python 3.9']

[shihai1991]

compiler need support unary operation of in(de)crement or all of it should have syntax error.I have found many user have confused about it(such as:https://stackoverflow.com/questions/2632677/python-integer-incrementing-with). Of course, it is a big change of grammar and it need core developer team to make decision.

If core developer team support it, i will try my best to do it;)

The behavior is:

$ ./python
Python 3.8.0a4+ (heads/master:e225beb, Jun  4 2019, 00:35:07)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> i = 1;
>>> ++i
1
>>> i++
  File "<stdin>", line 1
    i++
      ^
SyntaxError: invalid syntax

[stevendaprano]

For the reasons already discussed on the Stackoverflow link you gave, Python does not have pre- and post-increment and -decrement operators, and probably never will.

I'm closing this ticket as Won't Fix, but if you wish to discuss it further, you can raise it on Python-Ideas for community feedback. If there is significant interest, you can then write a PEP for it, and if the PEP is approved, then you can re-open this ticket and provide a PR or patch.

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

https://www.python.org/dev/peps/

[shihai1991]

Thank for your suggestion,Steven. If python can not support post-increment and -decrement operators now, i think ++i should raise syntax error as i++.

[ericvsmith]

Since ++i already has a meaning, it won't become a syntax error without an extremely good reason, and I don't think this case meets that standard.

But as Steven says, if you want to pursue it, you should start with a discussion on python-ideas.

[shihai1991]

got it, Eric

[shihai1991]

A discussion was initiated in https://discuss.python.org/t/why-compiler-doesnt-support-in-de-crement-operation-should-we-support-it/2181.

And most of user tend not to support this in(de)crement operation.

[stevendaprano]

Please remember that not all Python programmers come from a C background
where ++n is a pre-increment operator. Then may have a OOP background
where the unary + and - operators can do anything they like.

Making --obj or ++obj a syntax error is a backwards-incompatible
change that will break people's code. We take backwards compatibility
seriously. Python is a mature language with millions of users, we don't
break their code lightly.

As you were told (twice) last year, this change will not be considered
until you take it to the Python-Ideas mailing list for feedback. If you
have done this, please post a link to the discussion.

If you get a consensus that the change is a good idea, you need to find
a core developer to sponsor a PEP, then write the PEP, and ask the
Steering Council to approve it. Only then will the PR be approved.

[shihai1991]

Steven, Thank you for your quick comment.

sure, i will keep this bpo stay in closed status until enlist the support of core developers.