Open Okohedeki opened 2 years ago
Hi,
Thanks for bringing this to my attention. I take backward compatibility seriously and do not want to needlessly cause people grief.
It sounds like there are two distinct issues/requests here:
Allow lookup using non-accented versions of the current name. This would be a new feature (and is related to #28). Unaccented queries for countries with an accented name have never been supported.
Allow lookup using historical names. Disruption like this must have also occurred when "Czech Republic" was replaced by "Czechia" - and the same modification would have helped then.
An initial, scoped, implementation might only allow queries using names that have at one point been part of this library.
I think both of these changes would be improvements - and they seem quite safe. However, they do represent their own opportunity for backwards compatibility issues:
Someone using country lookup to "validate" a country name would see different behavior.
Someone unpacking the Country object into a tuple might need to update their implementation.
My initial inclination is to add these changes and then push the package to pypi as pre-release version 3.0.0b1 while gathering some feedback here. Would that help your situation?
I agree with adding it to the pre-release version at first. This package seems to be used quite frequently so there's a bit of a cat and mouse game going on. If you did that I would see if it would be possible to test using the pre-release version and seeing that fixes the current issues we are having.
Hello,
With a current update to iso3166 multiple communities are having issues due to looking up country codes with special characters:
For example Åland Islands, Türkiye. While we could just use the alphacode it would be nice to still be able to pass into non-accented English spellings of the country (Aland Islands, Turkey) as an alpha4 in the tuple to allow for backward compatibility. I can get a PR going for this if you need it.