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.

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

Allow keyword-only attributes before positional attributes #448

Closed
oakkitten opened this issue Sep 30, 2018 · 4 comments
Closed

Allow keyword-only attributes before positional attributes #448

oakkitten opened this issue Sep 30, 2018 · 4 comments
Labels

Comments

@oakkitten
Copy link

I want to be able to write both Message("message", timestamp=time.time()) and Message("message"), where timestamp is an attribute of a base class. Currently the following code:

@attrs
class Base:
    timestamp = attrib(kw_only=True, default=None)


@attrs
class Message(Base):
    message = attrib()

produces the following error:

ValueError: Non keyword-only attributes are not allowed after a keyword-only attribute.

As timestamp is keyword-only, it, as far as I understand, does not pose an ordering issue.

(In my particular use-case, I have a bunch of Messages that are convenient to create using positional arguments, but the timestamp field is not always meaningful, e.g. for outgoing messages)

@hynek
Copy link
Member

hynek commented Oct 27, 2018

it’s indeed weird that we don’t allow kw_only attributes anywhere. Someone should research why we chose that route. they are a lot more useful if you can sprinkle them anywhere.

@wsanchez
Copy link

wsanchez commented Oct 29, 2018

I suspect that "Non keyword-only attributes are not allowed after a keyword-only attribute" because that's an existing constraint in function argument ordering.

One problem is allowing them anywhere is that the ordering of arguments to __init__ becomes a bit less obvious, since you need to mentally sort the attributes to account for the kw_only attributes. That's not horrible, but also not nothing. It could be helped by doc generators that figured that out for you, though.

@trianta2
Copy link

trianta2 commented Mar 5, 2019

Agreed this type of functionality would be useful. I'm curious what a current best-practice workaround would look like.

@hynek
Copy link
Member

hynek commented Aug 21, 2019

This has been fixed by #559

@hynek hynek closed this as completed Aug 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants