phone_number should support different formats

[sshishov]

Currently usage of phone_number factory is useless as every time it generates completely different format which is not compatible with third party libraries you want to include it in.

I would recommend to add the format or any other key with pre-defined literals and based on this return the proper format.
I guess the main formats can be like here: https://django-phonenumber-field.readthedocs.io/en/latest/reference.html#phone-number-format-choices

For backward compatibility we can have the format=None as default and fallback to unsorted return value, otherwise all generated phone number fields should be based on some format rule

[fcurella]

I'm confused, phone_number does support different formats. See the en_US localization for example.

Are you setting the locale when you instantiate Faker?

[fcurella]

After reading your comment on #1588 (comment), I think I see what you're saying.

I'm ok with adding the parameter. Feel free to submit a Pull Request and I'll be happy to review it!

[parsariyahi]

What If we add another method like local_phone_number() where you have the flag like local or just you said format?

[stefan6419846]

Why would we need another method? A format parameter for the existing method is backwards-compatible as well.

[parsariyahi]

The thing is some countries have more that just one format, so we have local and we have format
So let's say I want a number in specific local but the format does not matter.
In this situation just using a format param should work just fine like you said.
But now I want a local phone number with specific format, in here we should use another param with this solution.

One side is, should we have format when we have all localizations handled separately.
But if we say you can use a general phone_number method with a local or country
It's better to handle formats too.