Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

inconsistency with bare * in parameter list #46865

Closed
mark-summerfield mannequin opened this issue Apr 11, 2008 · 10 comments
Closed

inconsistency with bare * in parameter list #46865

mark-summerfield mannequin opened this issue Apr 11, 2008 · 10 comments
Assignees
@gvanrossum
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error

Comments

@mark-summerfield
Copy link
Mannequin

mark-summerfield mannequin commented Apr 11, 2008

BPO 2613
Nosy @gvanrossum, @terryjreedy, @pitrou, @mark-summerfield, @benjaminp

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 = 'https://github.com/gvanrossum'
closed_at = <Date 2008-05-27.17:08:55.492>
created_at = <Date 2008-04-11.08:42:49.061>
labels = ['interpreter-core', 'type-bug', 'invalid']
title = 'inconsistency with bare * in parameter list'
updated_at = <Date 2016-08-23.16:18:28.122>
user = 'https://github.com/mark-summerfield'

bugs.python.org fields:

activity = <Date 2016-08-23.16:18:28.122>
actor = 'gvanrossum'
assignee = 'gvanrossum'
closed = True
closed_date = <Date 2008-05-27.17:08:55.492>
closer = 'gvanrossum'
components = ['Interpreter Core']
creation = <Date 2008-04-11.08:42:49.061>
creator = 'mark'
dependencies = []
files = []
hgrepos = []
issue_num = 2613
keywords = []
message_count = 10.0
messages = ['65340', '67380', '67403', '67406', '67414', '67415', '67676', '67693', '273468', '273477']
nosy_count = 7.0
nosy_names = ['gvanrossum', 'terry.reedy', 'pitrou', 'mark', 'benjamin.peterson', 'bgolemon', 'vitorg']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue2613'
versions = ['Python 3.0']
@mark-summerfield
Copy link
Mannequin Author

mark-summerfield mannequin commented Apr 11, 2008

A bare * in a parameter list behaves differently depending on what
follows it:

Py30a4:

>> def f(*, a=1, b=2): return 1

>>> def g(*, **kwargs): return 1
SyntaxError: named arguments must follow bare * (<pyshell#10>, line 1)

I don't know if this is a bug or not but thought it worth querying. This
case does not seem to be mentioned in PEP-3102.

@mark-summerfield mark-summerfield mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error labels Apr 11, 2008
@bgolemon
Copy link
Mannequin

bgolemon mannequin commented May 26, 2008

It seems like f(a=1, b=2) and g(a=1, b=2) should be equivalent. Anyone
agree, disagree?

@benjaminp
Copy link
Contributor

Guido, what do you say?

@pitrou
Copy link
Member

pitrou commented May 27, 2008

Agreed with Buck and Mark, this looks like a bug. Or, rather, a
limitation, since a bare * just before a **kwargs should be useless if I
understand correctly.

@gvanrossum
Copy link
Member

I see it differently. The rule is simply that if you use a bare * you
*must* follow it with at least one argument (that's not **k). This
makes sense since otherwise the * is redundant. Think about it; there
is nothing different between

def g(*, **kwds): ...

and

def g(**kwds): ...

@bgolemon
Copy link
Mannequin

bgolemon mannequin commented May 27, 2008

If there's no difference then they should work the same?
I agree there's probably little value in 'fixing' it.

@terryjreedy
Copy link
Member

Rationale for banning f(*,**k): it could represent a bug (intended bare
name(s) omitted) that should be flagged, a lack of clear understanding
of the redundancy, or a somewhat unPythonic stylistic preference for
useless redundancy. I consider the first the most likely in practice,
though I also did not see the redundancy at first. Guido has used the
'likely a bug' rationale for other design decisions.

@bgolemon
Copy link
Mannequin

bgolemon mannequin commented Jun 4, 2008

/agree

@vitorg
Copy link
Mannequin

vitorg mannequin commented Aug 23, 2016 

Here is example where it's necessary, but still raising an error:
>>> def my_method(self, *, **kwargs):
...     pass
... 
  File "<stdin>", line 1
SyntaxError: named arguments must follow bare *

@gvanrossum
Copy link
Member

I promise you it's not necessary in that example. Leaving out the '*' has the same effect as what you intend there.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@gvanrossum gvanrossum

Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@benjaminp @pitrou @gvanrossum @terryjreedy