us.states.lookup("Wyoming") returns no output.

us.states.lookup("WY") returns the correct output.

It would be helpful for cases such as SQLAlchemy integration to have this data exposed as an enum in some way.

Hello, I attempted to install the us package in my Python 3.12.1 environment using Poetry 1.7.0 and the install failed to build the jellyfish 0.11.2 package. This is a known issue in jellyfish that was resolved as of 1.0.3, can we get a new build of us with the updated dependency?

jamesturk/jellyfish#199 (comment)

Also I see that someone has created a PR to do this very thing #74

Basically here's the deal (looking up "Utah" or "utah" returns None, but looking up with "UT" or "uta" returns the proper state object):

>>> us.states.lookup(u'UT')
<State:Utah>
>>> us.states.lookup(u'uta')
<State:Utah>
>>> us.states.lookup(u'Utah')
>>> us.states.lookup(u'utah')
>>> us.states.lookup(u'New Mexico')
<State:New Mexico>

This is with 0.9.1.

When doing a Lookup if u'Illinois' the Metaphone value that comes back from Jellyfish metaphone is 'LNS'. The Data says that it should be 'ILNS' do the lookup does not return a value.

I don't find any mention of dropping python 2 support in the changelog for 2.0.0, but installing with pip fails due to the jellyfish==0.7.2 requirement.

Could you either document that you're dropping support or fix this dependency issue?

> pip install us==2.0.0
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
Collecting us==2.0.0
  Downloading us-2.0.0.tar.gz (13 kB)
ERROR: Could not find a version that satisfies the requirement jellyfish==0.7.2 (from us==2.0.0) (from versions: 0.1, 0.1.1, 0.1.2, 0.2.0, 0.2.1, 0.2.2, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.4.0, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5, 0.5.6, 0.6.0, 0.6.1)
ERROR: No matching distribution found for jellyfish==0.7.2 (from us==2.0.0)

In mapping a pandas DataFrame's numeric fips index to state name, I currently have to do this:

state['state'] = pd.Series(state.index).apply(
    lambda x: us.states.lookup(str(x).zfill(2)).name).tolist()

There are a couple things going on here that could be other issues*, but might also be nice to have the vectorization built-in for pandas. e.g. I'd like to be able to just do:
state['state'] = us.states.lookup(state.index)

* This one was verbose because things like us.states.lookup(1) and us.states.lookup('1') fail.

Using this package for just the state to timezone(s) info, it seems there are missing and incorrect timezones.

Some that I have found:

• IN: Missing America/Chicago and America/New_York. Just outdated overall.
• KY: Missing America/Chicago. Unnecessary America/Louisville (has America/Kentucky/Louisville)
• NM: Should be America/Denver, not America/Chicago.

These are only a few, so there must be more inconsistencies around with other state timezone(s).

Should return D.C. I tried with DC_STATEHOOD also, which didn't make a difference. Could a proxy "state" to D.C. be a solution?

Version: '1.0.0'

Like the package a lot!

It would be nice if there is a method to return GeoJSON urls instead of .zip.

But I didn't find any resources to attach here and not sure if the Census API even supports returning GeoJSON.

How can we help cut the 3.0 release so we can push for 3.9 and 3.10 support?

Would there be interest in adding a zipcode lookup functionality for this package? That would mean extending the data beyond just state level and return city, state, county, timezone, lat/long for a given zipcode.

I'd be open to submitting a PR if that would be welcome.

I'd be happy to help with this effort if you were open to the expansion of the library.

Hello! I love, and indeed have always loved, this package.

2.0.2 has an old jellyfish dependency, however, and I see that 3 has been pushed with a jellyfish upgrade.

I could install from github but was wondering if you intend to push to pypi soon-- if so, I can hold on.

Thanks!

Due to ease of merging and other issues, I'm thinking the sqlite + pkl file no longer makes sense. The original intention was to have easier modification of data, but merging multiple changes to the database is pretty much impossible without manual intervention.

I'm thinking it's time to just convert it all to Python with a class for each state. Any thoughts @mileswwatkins?

FIPS code 74
Abbreviation UM

https://en.wikipedia.org/wiki/Federal_Information_Processing_Standard_state_code

I think this is the only thing preventing mapping from state FIPS codes to county FIPS codes here.

If there is an interest, I'll volunteer to put together a PR for this.

Noting this as an issue because us.states.DC still exists, so there's no reason us.states.lookup should have broken.

Just ran into this case and wondering if it might be useful to others -

It might be handy to add a borders method on the state object that returns a list of states that border the state, e.g. <State:California>.borders (or another more appropriate method name) would return [<State:Nevada>, <State:Oregon>, <State:Arizona>]. For now I'll have to do a geospatial query to find the bordering states but it might be computationally expensive

Arizona's capital timezone is recorded as 'America/Denver'.
see us.states.mapping('name', 'time_zones')['Arizona']

Arizona does not do daylight savings time, but 'America/Denver' does. Arizona is always on MST (aka 'America/Phoenix')

us.states.lookup(u'Utah') in version 0.9.1 returns nothing, while every other state seems to work fine.

can we add a STATES_ONLY variable with states minus DC? happy to submit PR

It seems like it ought to return NY. In general, looking up 'XXX State' (or phonetic/misspelled equivalents?) should probably work for any of the 50 states, though I think it's far more common for New York State and Washington State than any others (to distinguish them from the cities).

But I actually do run into "New York State" as a state name in reasonably well curated data sets, so that one seems particularly important to include.

Am I experiencing a load error related to 2.7, or something else?

Admins-iMac-2:data patsplat$ sudo pip install us --upgrade
Requirement already up-to-date: us in /Library/Python/2.7/site-packages/us-0.7-py2.7.egg
Requirement already up-to-date: jellyfish==0.2.0 in /Library/Python/2.7/site-packages/jellyfish-0.2.0-py2.7-macosx-10.9-intel.egg (from us)
Cleaning up...
Admins-iMac-2:data patsplat$ python
Python 2.7.5 (default, Aug 25 2013, 00:04:04) 
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import us
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.macosx-10.9-intel/egg/us/__init__.py", line 1, in <module>
  File "build/bdist.macosx-10.9-intel/egg/us/states.py", line 117, in <module>
  File "build/bdist.macosx-10.9-intel/egg/us/states.py", line 51, in load_states
AttributeError: __exit__
>>> 

I see you guys added support for Python 3.8 in version 2.0.0, but still got this error in conda today (after solving the base environment for an age):

UnsatisfiableError: The following specifications were found
to be incompatible with the existing python installation in your environment:

Specifications:

• us -> python[version='2.7.|3.5.|3.6.|3.4.']

Your python: python=3.8

If python is on the left-most side of the chain, that's the version you've asked for.
When python appears to the right, that indicates that the thing on the left is somehow
not available for the python version you are constrained to. Note that conda will not
change your python version to a different minor version unless you explicitly specify
that.

I'm running conda 4.8.4 and tried both conda install us and conda -c conda-forge us since I saw a bug suggesting I might need to specify the channel. Same message both times.

Not sure if this is something on your side or conda-forge not using the latest version. I succeeded in 2 seconds with pip install us. Let me know if I should be reporting this to conda instead.

Update: looks like conda-forge is still trying to use 1.0.0, no wonder:

Can we add type hints for this library? Currently mypy complains: error: Skipping analyzing "us": module is installed, but missing library stubs or py.typed marker [import-untyped]

I often find it useful in my projects to have a hash/associative array of state abbreviations and names. What do you think about adding this to the package?

Please add a git tag for 0.9.1.

Add the three associated states of the USA which are lists as Marshall Islands, Micronesia, and Palau here

Not sure if this is intentional, but it is odd behavior.

set(us.states.STATES_AND_TERRITORIES) == set(us.states.STATES + us.states.TERRITORIES + us.states.OBSOLETE)

I would expect STATES_AND_TERRITORIES to be just STATES + TERRITORIES

Based on: https://simple.wikipedia.org/wiki/U.S._postal_abbreviations

EXTRA_STATES = {
	'Armed Forces Americas': 'AA',
	'Armed Forces Europe': 'AE',
	'Armed Forces Canada': 'AE',
	'Armed Forces Middle East': 'AE',
	'Armed Forces Africa': 'AE',
	'Armed Forces Pacific': 'AP',
	'Federated States Of Micronesia': 'FM',
	'Marshall Islands': 'MH',
	'Palau': 'PW',
}

3.9 has been the latest stable Python release since October 2020

On Python 3.10.1, a fresh pip install us yields this TypeError:

Python 3.10.1 (main, Dec 22 2021, 05:19:12) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import us
>>> us.states.lookup('maryland')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/max/.pyenv/versions/3.10.1/lib/python3.10/site-packages/us/states.py", line 86, in lookup
    val = jellyfish.metaphone(val)
TypeError: str argument expected

This is the output of pip freeze:

$ pip freeze
jellyfish==0.6.1
us==2.0.2

Is this a known issue?

Fails to find state Kentucky when using all caps.

import us
>>> us.states.lookup('KENTUCKY')
>>> us.states.lookup('kentucky')
<State:Kentucky>

Lawl.

Thanks @shanear!

Thinking that we could completely drop Dakota, Orleans, and the Philippines from the version 2.0 release @jcarbaugh. Special-casing them presents problems regarding:

• neighboring
• capital
• time_zones, since official time zones, much less IANA ones, may not have even been invented; eg, Orleans was admitted to the union as the State of Louisiana about 70 years before US time zones were implemented
• abbr and ap_abbr, for similar timeline reasons

What are the core user stories that would support keeping these obsolete territories around? Seems like the headache of keeping them around wouldn't be worth it, but very happy to have my mind changed!

As per subject

Hi.
For the cache to work, it may be necessary to refine the code.
Maybe after this line is required else or return matched_state :)