FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

chore: deprecate public-facing camelCase functions by SYMSCAE · Pull Request #168 · diffpy/diffpy.pdffit2 · GitHub

  1. diffpy
  2. diffpy.pdffit2

Repository navigation

chore: deprecate public-facing camelCase functions - #168

Merged
sbillinge merged 6 commits into
diffpy:mainfrom
SYMSCAE:no_camel
Aug 12, 2026
ConversationCommits (6)ChecksFiles changed
Merged

chore: deprecate public-facing camelCase functions#168
sbillinge merged 6 commits into
diffpy:mainfrom
SYMSCAE:no_camel

Conversation

SYMSCAE commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

This PR updates pre-commit dependencies, replaced internal camelCase functions with snake_case and deprecated public facing camelCase functions.

SYMSCAE commented Aug 8, 2026

Copy link
Copy Markdown
Contributor Author

@stevenhua0320 PR ready for review. Also are c++ functions involved in the scope of deprecation?

sbillinge commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

We don't have to deprecate c++. Only the python API.

sbillinge reviewed Aug 8, 2026
View reviewed changes

sbillinge left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Please can you check that both versions of the functions, camelCase and snake_case, are tested. The camelCase test will just call the snake_case test, something like that.

sbillinge commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

I will wait for a more careful review from @stevenhua0320 but modulo my comments (I didn't check in detail) it looks great.

stevenhua0320 commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

@SYMSCAE It also looks good to me, sorry for the late response. @sbillinge ready for the workflow checking.

SYMSCAE commented Aug 9, 2026

Copy link
Copy Markdown
Contributor Author

@sbillinge new tests added.

sbillinge commented Aug 9, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

I don't think these tests are quite right. What are they testing? I mean I know which function they are testing but what behavior? We have a more or less standard way of doing these deprecations tests so the best is if you can refer to some of Caden's work, for example in diffpy.structure

SYMSCAE commented Aug 9, 2026

Copy link
Copy Markdown
Contributor Author

I don't think these tests are quite right. What are they testing? I mean I know which function they are testing but what behavior? We have a more or less standard way of doing these deprecations tests so the best is if you can refer to some of Caden's work, for example in diffpy.structure

They are testing if a deprecation warning is thrown and if the function call is redirected to the new function and delivers the same result. Sure, I will refer to his work and standardize it.

SYMSCAE commented Aug 10, 2026
View reviewed changes
Comment thread tests/test_pdffit.py
return

#
# def test_selectAtomType(self):

SYMSCAE Aug 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

@sbillinge After examination, non of these deprecated functions is covered in previous tests separately. They're simply commented out placeholders, do we still need such tests?

sbillinge Aug 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Please look at what @cadenmyers13 did in diffpy.utils and diffpy.srfit and diffpy.structure for ways to model this. I liked what he came up with and we want to basically conform to a standard to ease maintenance. But basically, if I remember correctly, we change the name of the actual test that tests the function so that it tests the new name, then we hard code a test function for the old name that simply is a lightweight wrapper that runs the other test. Thus the old name and the new name are being tested in the API but we don't duplicate code.

On your test too, as a general rule, we should always be susupicious about our test or our design when we have to mock in a test. Occasionaly it is necessary, but if can generally be avoided (Claude loves this kind of solution, I guess there is a ton of bad tests on the internet) and when not, it can indicate that we have a bad design and should look carefully at how we coded something. Finally, when we do mock, as a group standard, we like to use the pytest.mock (or pytest.mocker, I don't quite remember) interface so that all our code is consistent. Check other tests to figure out the standard.

Thanks so much!

SYMSCAE commented Aug 11, 2026

Copy link
Copy Markdown
Contributor Author

@sbillinge Please see if this is what we want. By the way, do we have a targeted release version that we will remove these functions? If so we can use the deprecator so the code style is synchronized.

cadenmyers13 commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

@SYMSCAE Usually a major bump (the first number of X.X.X) because that signifies API breaking changes

sbillinge commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

@SYMSCAE Usually a major bump (the first number of X.X.X) because that signifies API breaking changes

Your. I am on my phone so can't check but whatever the next major bump is with .0.0, so if we are at 3.something then use 4.0.0

sbillinge commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Thanks, that's the ticket

codecov Bot commented Aug 12, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.01%. Comparing base (bb19f61) to head (94f5617).

Additional details and impacted files 
@@            Coverage Diff             @@
##             main     #168      +/-   ##
==========================================
+ Coverage   98.97%   99.01%   +0.03%     
==========================================
  Files           6        6              
  Lines        1270     1321      +51     
==========================================
+ Hits         1257     1308      +51     
  Misses         13       13
Files with missing lines Coverage Δ
tests/test_exceptions.py 99.80% <100.00%> (ø)
tests/test_pdffit.py 99.78% <100.00%> (+0.02%) ⬆️
tests/test_shape_factors.py 99.53% <100.00%> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

sbillinge merged commit bcee486 into diffpy:main Aug 12, 2026
7 checks passed

sbillinge commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

congrats and thanks @SYMSCAE ! Great job getting that finalized.

SYMSCAE deleted the no_camel branch August 12, 2026 07:55
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Show hidden characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

sbillinge sbillinge left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

Back | FazBrowse Home | New Git URL