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

Question: Why java-style getters & setters #5487

Closed
Ablesius opened this issue May 22, 2020 · 3 comments
Closed

Question: Why java-style getters & setters #5487

Ablesius opened this issue May 22, 2020 · 3 comments
Labels
meta Meta topics, e.g. repo organisation and issue management

Comments

@Ablesius
Copy link

Hi explosion team,

while browsing the spacy API documentation I found some examples of java-style setters & getters, e. g. here and in this issue comment. I was wondering whether you do this on purpose? I ask because Python Anti-Patterns defines this as unpythonic, and recommends using @property decorators instead. My question is totally open to reasoning, I'm curious whether this is something you'd be interested to change or whether you made a conscious decision to do it, and if so why :)

Cheers,
Alex

@svlandeg svlandeg added the meta Meta topics, e.g. repo organisation and issue management label May 25, 2020
@honnibal
Copy link
Member

Actually we do a fair bit with properties, but that method in particular takes a list, so it's a different interface. Also setters allow keyword arguments, where attribute assignment does not. Setters are also more transparent in some issues.

In general rules-of-thumb will only go so far in any problem that comes down to balancing multiple trade-offs. I must say I took exception to your comment: it came across as condescending and presumptuous. You're asking "Have you thought about the decisions behind your API", and the answer is...well, yes! And no we're not open to discussing changes to it on the basis of reference to generic rules of thumb.

@Ablesius
Copy link
Author

I must say I took exception to your comment: it came across as condescending and presumptuous.

I'm sorry you took it that way. As I said, that was not my intention. I'm trying to understand how and why things are done in order to learn. I don't assume to know better; I assume you had a good reason, and I was trying to ask what that reason was, so that I can learn why my "counter example" is not a good idea or not applicable for that case.

You're asking "Have you thought about the decisions behind your API"

That is actually not what I meant to ask, but I can see now why it came across as such. I'm sorry for this misunderstanding. I assumed that you know very well what you are doing, and I'm not pointing out something you would have overlooked. I rather thought "I know of decorators, and here I see something different, why is this solution better than decorators? There must be a reason".

Thank your for your explanation. I will try to understand it in detail.

Best regards,
Alex

@github-actions
Copy link
Contributor

github-actions bot commented Nov 5, 2021

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
meta Meta topics, e.g. repo organisation and issue management
Projects
None yet
Development

No branches or pull requests

3 participants