Open AlJohri opened 6 years ago
I've certainly found myself writing things like us.STATES + us.states.PR
or [s for s in us.STATES if s.abbr != 'DC']
as much as the next news/elections dev. I'm not sure whether a new collection is key here or if there's a better solution available; it'd probably help to hear more from @jcarbaugh about the decision behind making us.states.DC
a state instead of a territory in this package.
The original use case for this package was to make it easier to generate dropdown on web sites for the selection of a state. For that use, including DC as a state made it so no special handling was needed to get a list of places most people live. I also like the thought of it being a political statement, in which case including PR in us.STATES
also makes sense. Less concerned if it takes a couple extra lines of code (or us.STATES_ONLY
) to get the true, factual list of states.
I'd be easily swayed by the argument that the primary use case of this package is now for journalism and data analysis and that DC no longer belongs in us.STATES
.
It almost feels to me like removing DC from us.STATES
is a major breaking change. But I think it's the right move?
(What about a version 2 that includes this change, county support (https://github.com/unitedstates/python-us/pull/21), and database/pickling refactor/removal (https://github.com/unitedstates/python-us/issues/37)? I've got a bit of time to put in elbow grease.
Maybe get one more 1.x release out with that extra Python 2 support you added and then prep for a 2.0 breaking release?
can we add a STATES_ONLY variable with states minus DC? happy to submit PR