Summary

Implement .github/worfklows to do the following:

• Lint with our linter of choice (pylint, black, etc)
• Run unit tests
• Confirm build and installation on windows, mac and linux

Implementing basic checks early in the development process and provide needed velocity as this port matures.

Considerations

• The choice of linter: pylint and black are good starting points
• How to orchestrate workflows

Other

I am a long time user of countrycode since my time in graduate school and am very excited to see a Python port!

Summary

Packages sometimes employ custom templates for features and / or bugs. A minimally viable template would include the following:

• Description of feature / problem
• Checklist of items to remind the user to check their code prior to merging.

Considerations

• I'll defer to @vincentarelbundock if this is needed for a package of this scope. If a template is not needed I can close the issue.

Thanks! :)

@Nadjim10 could you please convert all the R tests at these links into Python tests in the present repository?

https://github.com/vincentarelbundock/countrycode/blob/main/tests/testthat/test-corner-cases.R
https://github.com/vincentarelbundock/countrycode/blob/main/tests/testthat/test-known-name-variations.R
https://github.com/vincentarelbundock/countrycode/blob/main/tests/testthat/data-known-name-variations.R

Summary

We can use the hypothesis package to make unit testing more robust. Property-based testing will allow us to generate examples and edge cases either through random strings or strategies that can be based on codelist.

For example the test_invalid_iso3c_to_country_name function in tests/test_basic.py could be rewritten as follows:

1. Build a strategy to generate any three letter uppercase string that does not appear in codelist's iso3c column.
2. Assert that the result of countrycode(code, "iso3c", "country.name") is always None for all inputs generated with the above strategy

Considerations

• Property based testing does not need to be implemented at once or for every use case. Given the fairly rigid input and outputs needed in this package this approach can be useful to highlight potential problems in testing.

References

• In praise of property-based testing
• Getting Started With Property-Based Testing in Python With Hypothesis and Pytest

Other

As someone raised with Legos, specifically Lego Star Wars, I appreciate your profile picture on GitHub and Twitter.

Summary

As of the most recent commit CI formatting checks are failing. The linting failures prevent tests from being run. On my local fork test suites such as test_regex_internal fail due to missing the polars import. While this behavior is expected as a result of making both polars and pandas optional the tests must be updated in a manner that allows for such dependencies to be optional.

Work Needed

1. Update package formatting to pass the linting CI steps
2. Update all tests to pass when polars and pandas are not installed

Considerations

• The current approach within countrycode.py can be mirrored in the test suite to handle optional imports. I find myself falling back on the conventions laid out in a 2014 stackoverflow answer
• The version of the package can be a patch version, namely a bump from 0.4.0 to 0.4.1 .

I can jump on the first to-do item within the next day and have time to devote to the second item later in the week.

Summary

One of the most compelling features of the R package countrycode is the ability to manually manipulate the codelist Dataframe for use in other projects. As presently constructed the codelist variable exported from countrycode does not integrate with pandas or numpy. More specifically the following script will fail when countrycode is installed via pip:

from countrycode import codelist

codelist.to_pandas()
codelist.to_numpy()

Potential Fixes

1. Do not update dependencies and update documentation to indicate that numpy and pandas functionality requires installation of those packages
2. Update primary project dependencies in pyproject.toml to include pandas and numpy.
3. Add a data dependencies section that includes numpy and pandas. With this approach a user can optionally install the additional packages:

pip install countrycode[data]

4. Convert codelist to a pandas.DataFrame and remove substitute polars for pandas

Of the potential options I am partial to 3 and 4. Option 3 leaves the structure of the package untouched and shifts the choice to install additional dependencies to the user if they wish to use the codelist data in a pandas or numpy environment. My predilection for option 4 stems from python's reliance on pandas to manipulate data.

Considerations

• Options 1-3 do not require updates to the source code itself and would be lighter lifts to implement than option 4

Other

Your statement in the last issue about "real work" resonated with me.