GSoC 2025 - Django Proposal: Phone Field

Django Internals Mentorship
1

Hello Django community !
Here is a gist containing my GSoC proposal. If you share the same idea or find it valuable, please don’t hesitate to show your support!

gist: GSoC 2025 - Django Proposal: Phone Field

I’m currently looking for a mentor for this idea – if you’re interested, please feel free to reach out!

GSoC 2025 - Django Proposal: Phone Field

Project Overview

1. Project Title

  • Title: Add PhoneNumberField/PhoneField to Django Core
  • Difficulty: Medium
  • Size: Estimated hour for scope - 350hrs
  • Potential Mentors: —
  • Key Skills: Django Models, Django Core, Fields, Django Forms etc.

1.1 Abstract

  • This project proposes the addition of a new PhoneNumberField to Django’s model field options. The goal is to provide a built-in, flexible and internationalized solution for phone number storage, validation, and rendering, reducing reliance on external packages for a common use case.

1.2 Which Category ?

  • Work on Django itself ( ORM, forms, etc,)
  • Work on libraries that supplement or add new features to Django to ease development

1.3 Related third party libs

2. Motivation

In modern web development, phone numbers have become a first-class citizen in user models — often standing alongside or even replacing email addresses in authentication, communication, and user verification workflows.

While Django offers an EmailField out of the box, there is currently no built-in PhoneNumberField, despite the clear and growing demand from the developer community.

Key reasons why this feature is needed:
• Phone numbers are increasingly used in account creation, password reset, and login flows.
• Applications today often require SMS-based two-factor authentication, phone call verifications, or integrations with messaging platforms like WhatsApp.
• A PhoneNumberField is as essential as an EmailField in many modern user models.

Evidence of strong community demand:
• Third-party packages like django-phonenumber-field have 1.5K+ stars and wide adoption.
• Developers frequently request this feature in forums and issues.
• Existing solutions are helpful, but introducing this natively into Django would:
• Reduce dependency on external libraries
• Improve consistency and developer experience
• Align with Django’s “batteries included” philosophy

By adding a robust PhoneNumberField to Django core, we provide a feature that:
• Fulfills a common and practical need,
• Helps thousands of developers avoid boilerplate or third-party workarounds,
• And supports more secure and flexible user identity models.

3. Related Issues

I would also like to list the issues opened regarding this project on different platforms below:

4. Proposal

The general goal is to add a built-in phone number field to the Django core. The phone number field should handle input and validation in compliance with international standards. At this point, integration can be implemented in line with Google’s libphonenumber library and its Python port, python-phonenumbers, similar to what the django-phonenumber-field package does.

However, this proposal does not goal to directly full integrate the django-phonenumber-field package into Django core. Instead, it aims for a clean and well-integrated implementation, taking into account the open issues and limitations of the existing third-party package.

  • Also this new field can be added to the built-in “AbstractBaseUser”

5. Example usage (Goal)

from django.db import models
from django.contrib.auth.models import AbstractBaseUser

class User(AbstractBaseUser):
    
    phone = models.PhoneField() # sample: 1
    phone = models.PhoneNumberField() # sample: 2

6. About Me

I hold a Bachelor’s degree in Electrical and Electronics Engineering and have been actively working in the software industry for around six years. During most of this time, I have worked as a backend developer, with Django being one of the primary technologies I’ve used. Software development is not just my profession but also my passion. I’m eager to contribute to open-source platforms like Django, which have provided me with both professional growth and income opportunities, in order to help them grow stronger and continue empowering developers like myself.

Emre MENTEŞE

2

Hi @emrementese — thanks for the proposal here.

I have to say, I’m not sure that a Phone Number is a good candidate for inclusion in Django itself. It seems like the perfect fit of a third-party package…

There’s no reason it couldn’t be a GSoC project for a third-party package, if suitably motivated. :thinking:

Who are the maintainers of the current packages? Can you find a willing mentor there? Do they agree there’s a case for a project? (What needs updating, if anything? etc)

(This isn’t my area at all! :grimacing: — I’m hoping to mentor a project on template-partials, if we get a good proposal for that.)

Sorry if that’s not more help.

1 Like
3

Hi again,

First of all, thank you very much for your quick and constitutive feedback.

I didn’t know that a mentor could advise on more than one project. So even though I’m aware that you’ll be working on the template-partials project, I still wanted to reach out in case this proposal might catch your interest :slight_smile: I think my idea isn’t too bad! Looks like I’ll need to look for another mentor though :frowning:

  • Also, taking your advice into consideration, I will look for a mentor at the library and see if there is anything that can be done there. Thanks again.
4

Dear @KenWhitesell,

How does this idea look to you?
I saw that you had previously responded to related topics on the forum.
Would you consider mentoring this project, or possibly pointing me to someone who might be interested?

5

Since you pinged me directly for an opinion, I will reply.

First, to address your root question, I’m not a suitable mentor for a GSoC project. (Multiple reasons - all on my end.) Nor do I know anyone well enough to identify them for such a role.

<opinion>
Now, regarding the proposal itself, I’m not sure it needs to be in core.

If I were drawing the line in this area between what should be in core and what should be in a third-party module, I would say that all data types supported natively by the supported database engines, should be in core, and data types natively implemented by a subset of engines should be supported by a custom module for those engines. (e.g. django.contrib.postgres.fields)

I’m actually one of those that think that Django would be better served by being smaller, not larger, and that more emphasis should be put on external packages rather than continuing to add to core.

(Note, this would also assume more focus by the docs on “approved”, “recognized”, or “prioritized” third-party apps - perhaps even defining them as “core-suppored” - but that raises a number of other issues that would need to be resolved, many of which have been identified here in other threads. It’s also my understanding that this type of situation was originally the intent of the “contrib” module.)

</opinion>

2 Likes
6

First of all, thank you for your response. The reason I tagged you was because I value your opinions and believe you are knowledgeable on the subject.

I’m sorry to hear about the mentorship situation. Regarding your perspective—yes, keeping the core minimal and supporting third-party packages externally is an approach I also agree with. However, the fact that EmailField inherits from CharField in the core suggests that there are already similar patterns to what I am trying to do. While I agree with your reasoning, I’m still not fully convinced that this doesn’t belong in the core.

Due to time constraints, I’ll proceed with this proposal for GSoC 2025 this year. I don’t think it’s likely, but I hope a mentor takes interest.

2 Likes