Hacker News new | past | comments | ask | show | jobs | submit login

Great post, though this bit stuck out for me:

   current_zip = meta.IntegerField(max_length=5, blank=True)
You should not store zip data as an integer as they can start with 0. Zip codes use numbers, but aren't actually numbers themselves (leading zeros, no arithmetic, etc). Plus, someday you'll want to ship something to Canada.



The 'meta' there indicates that you're looking at something properly ancient. The ORM stuff in 'meta' is from the Django 0.9x era, meaning 2006.

If you want to store a US zip code today, use the 'localflavor' add-on:

https://django-localflavor.readthedocs.io/en/latest/

Which provides model and form fields and validation for various country-specific data types. It includes a US zip code field.


Even full canonical US zip-codes are 10 characters, right? XXXXX-YYYY or something

Edit: I think it's a typo and meant to be a CharField. There's no such thing as IntegerField max_length.


It's even worse: zip codes can contain letters and spaces in United Kingdom: https://en.wikipedia.org/wiki/Postcodes_in_the_United_Kingdo...


Falsehoods programmers believe about this HN thread: it links to Django's documentation.

It linked to a 13-year-old unmaintained community wiki page, and people apparently didn't look too closely at it. I stuck a big honkin' warning at the top of the page to clarify that.

If you want to handle US zip codes, UK postcodes, or other country-specific data types in Django, may I suggest this, which formerly was bundled with Django and now is maintained as a separate add-on:

https://django-localflavor.readthedocs.io/en/latest/

It includes such things as a correct dedicated US zip code field, and a correct dedicated UK postcode field.


And they are not called zip codes.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: