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

Undeprecate cmp #773

Merged
merged 10 commits into from
Feb 28, 2021
Merged

Undeprecate cmp #773

merged 10 commits into from
Feb 28, 2021

Conversation

botant
Copy link
Contributor

@botant botant commented Feb 27, 2021

Pull Request Check List

This is just a friendly reminder about the most common mistakes. Please make sure that you tick all boxes. But please read our contribution guide at least once, it will save you unnecessary review cycles!

If an item doesn't apply to your pull request, check it anyway to make it apparent that there's nothing left to do. If your pull request is a documentation fix or a trivial typo, feel free to delete the whole thing.

  • Removed tests for cmp deprecation warning.
  • Updated documentation for changed code.
    • Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives. Find the appropriate next version in our __init__.py file.
  • Documentation in .rst files is written using semantic newlines.
  • Changes (and possible deprecations) have news fragments in changelog.d.

If you have any questions to any of the points above, just submit and ask! This checklist is here to help you, not to deter you from contributing!

@botant
Copy link
Contributor Author

botant commented Feb 27, 2021

Not sure which changelog file I should add. I thought it was 773, but there is already a 787.

"""
warnings.warn(_CMP_DEPRECATION, DeprecationWarning, stacklevel=2)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been thinking and I think we should keep this deprecation.

The behavior of cmp is rather muddy, because it's a derivation of eq and order.

Now cmp becomes the officially blessed way of setting eq and order but this attribute doesn't make sense to me.

Especially because it returns a bool, while eq and order can be callables.

Does that make sense to you?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see where you're coming from. We have three arguments: eq, order and cmp, so one of them is redundant for sure. At the same time, eq and order aren't entirely clean, because order requires eq.

My preference would be to undeprecate cmp to avoid attr.ib(eq='str.lower', order='eq.lower'). I think attr.ib(cmp='eq.lower') feels and looks a bit nicer.

For the record, in my applications I will use attr.ib(eq=key_func(... ), order=False). Very often order won't make sense with complex objects. In fact, I'm a lot more annoyed by order being True by default than I am by cmp vs eq.

Having said that, I completely understand that cmp deprecation has been on the cards for a long time, and that undeprecating it may feel like a regression. Happy to follow your lead.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think/hope we've misunderstood each other!

What I mean is that we should undeprecate cmp for attr.s/attr.attrs (and add it to attr.define for that matter, but that's a different PR) since it's syntactic sugar for setting eq/order and very useful.


But I want to remove it eventually from the Attribute class. That's why I've commented specifically on the change in the cmp property.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see, you want to keep the deprecation specifically in the cmp property of Attribute - not else where? Sorry, my bad. Would we keep it in Attribute's init?

Especially because it returns a bool, while eq and order can be callables.

eq and order are also booleans. The callables are stored under eq_key and order_key.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need a new deprecation text?

_CMP_DEPRECATION = (
    "The usage of `cmp` is deprecated and will be removed on or after "
    "2021-06-01.  Please use `eq` and `order` instead."
)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's not used, probably not?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would we keep it in Attribute's init?

You mean the deprecation? Yes. I would like to remove cmp from Attribute for good eventually. I want it only to be a syntactic sugar, nothing more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All done (I think). Apologies for the confusion.

@hynek
Copy link
Member

hynek commented Feb 28, 2021

Not sure which changelog file I should add. I thought it was 773, but there is already a 787.

I'm confused, what is about 787? :) Your correct issue number is 773 so make it 773.deprecation.rst

Don't spend too much time on it; I will edit it anyways because I need to add some apologies.

@botant
Copy link
Contributor Author

botant commented Feb 28, 2021

I'm confused, what is about 787? :) Your correct issue number is 773 so make it 773.deprecation.rst

Done.

@botant
Copy link
Contributor Author

botant commented Feb 28, 2021

Out of curiosity, what is keeping us from removing cmp from Attribute's init? As far as I understand, attributes are not supposed to be instantiated manually, and cmp is already not used there anyway.

How about the property? Is it even possible to quantity the amount of damage that would be caused if we removed it?

Just curious to understand how you manage breaking changes.

@hynek
Copy link
Member

hynek commented Feb 28, 2021

Out of curiosity, what is keeping us from removing cmp from Attribute's init? As far as I understand, attributes are not supposed to be instantiated manually, and cmp is already not used there anyway.

Yes, but people have historically done so nevertheless. :(

How about the property? Is it even possible to quantity the amount of damage that would be caused if we removed it?

It's not! Which is why SemVer is bullshit (blog post incoming) but I'm trying to be extra careful and diligent.

They're both gonna move on to a better place in June.

Just curious to understand how you manage breaking changes.

Poorly, but I'm trying my best. :)

@hynek hynek merged commit f580185 into python-attrs:main Feb 28, 2021
@hynek
Copy link
Member

hynek commented Feb 28, 2021

Thanks!

@botant botant deleted the cmp-docs branch February 28, 2021 12:22
@botant
Copy link
Contributor Author

botant commented Feb 28, 2021

I'll submit another PR with the helper function soon.

hynek added a commit that referenced this pull request Feb 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants