PEP 570: Weird syntax leading to inconsistence

Python Help
1

Hello.

Came here to express my disturbance about development of Python language, especially about inconsistency of it’s syntax to current args kwargs - related syntax.

I’m about using / to delimit positional args, * to delimit keywords.

As to unpack positional args (actually - tuples) we use *, and for keyword args - **; I would understand if we would use it for delimiting positional args from keyword-positional and pure keyword args.

It should look like so:

def some_func(a, b, *other_args, *, c=None, d=None, **, e=None, f=None, **other_kwargs):
    pass

where a, b - are pure positional args; c, d - can be or positional or keyword args; e, f - keyword args, and other_args, other_kwargs gather all additional positional and keyword args.

I’m really sad that my favorite language with pure syntax and consistent semantics gets overpopulated by inconsistency.

Sources:
Docs to Python 3.8: https://docs.python.org/3/whatsnew/3.8.html
PEP 570: https://www.python.org/dev/peps/pep-0570/

My comments:
it's kind of the opposite of '*' which means "keyword argument" - no, it’s not so. * is used to unpack tuples and lists, or pack positional args to tuple.

def pos_only_arg(arg, /): should lool like so: def pos_only_arg(arg, *):

def kwd_only_arg(*, arg): should lool like so: def kwd_only_arg(**, arg):

Hope, this could be fixed eventually.

Best regards,
Vladislav

2

How do you denote an argument that can be passed either as positional or keyword in your proposal?

3

Same as in PEP 570 proposition: between positional only arguments delimiter and keyword-only arguments delimiter.

4

Is your complaint only that we should use * and ** for
positional-only and keyword-only arguments, instead of / and *?

# Current syntax:
def func(positional_only, /, positional_or_keyword, *, keyword_only)

# Your preference:
def func(positional_only, *, positional_or_keyword, **, keyword_only)

Unfortunately, you’re about ten years too late to change this. You will
just have to live with it. Unfortunately, syntax cannot keep everyone
happy. Personally, there are a few little niggles and annoyances that I
don’t like about Python syntax, such as ** for powers/exponentiation
and + for concatenation, I would prefer ^ and &, but its nearly 30
years too late to change that.

2 Likes
5

Yes, only for using * and ** instead of / and /.
But I see that PEP 570 was opened in March 2019, and it was not yet delivered to Python release, so thought, it could be discussed and, probably, changed.

Yeah, agree that there’s no anything ideal for everybody, but here is straight mismatch to current syntax, so I hoped it could be fixed before delivering to release…

6

The nice idea of using * and ** unfortunately seems not to be backward compatible e.g. with PEP 3102 from Python 3.0 in 2006, unlike PEP 570’s / and *.

7

PEP 570 is already accepted and included in the 3.8 release, which is already out.

As to unpack positional args (actually - tuples) we use *, and for keyword args - **; I would understand if we would use it for delimiting positional args from keyword-positional and pure keyword args.

Using * and ** as you propose would have been backwards-incompatible so even if you were on time for the original discussion, sadly that proposal could not be considered as some others in this thread are indicating. The meaning of * and ** (and the “inconsistency” you mentioned) was already established even before PEP570 was created.

Also, the same discussion has been raised some times before and answered as well. For instance:

Yeah, agree that there’s no anything ideal for everybody, but here is straight mismatch to current syntax, so I hoped it could be fixed before delivering to release…

I know you don’t want to be disrespectful, but what you define as “straight mismatch to current syntax” or “gets overpopulated by inconsistency” may be viewed differently by others, so I encourage you to describe your ideas in a different way next time. What you may think is just “giving your opinion” may impact some people (involved in what you mentioned or otherwise), leading to burnt out and discouraging them to contribute again.

8

Huh, don’t even know what to say.
I’m disturbed that if there will be too much different symbols for any special case in Python, it would look like Perl or some regexp after some years.
It would be difficult to remember meaning all that symbols mean in different contexts.

And are there any plans to make some breaking changes in further ?

Huh, just expressed as I see it.
Sorry guys if somebody was offended by my post.

9

We take backwards compatibility very seriously in the core dev team, even more after we learned from the Python 2 to Python 3 story, so sadly we don’t envision the possibility for breaking changes in the future.

Is fine, it was just a friendly reminder to be mindful that the language is important and can have impact on people that one may not consider initially.

10

Python is nearly 30 years old. The syntax today of Python 3 is very,

very similar to the syntax of Python 1. Python did not turn into Perl in

its first 30 years, you don’t have to worry, it won’t turn into Perl in

the next 30 years.

There are no plans to make large breaking changes in the future, but as

the language continues to evolve, there may be small changes.

11

Huh well, thanks for answers.
I’m a little bit calmed down, but not much.

Think, this thread can be closed ?