Remove unicode_format.h from stringlib

[ericvsmith]

BPO	24939
Nosy	@ericvsmith, @tonybaloney
PRs	bpo-24939: move stringlib/unicode_format.h to unicodeobject.c #13137

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/ericvsmith'
closed_at = None
created_at = <Date 2015-08-25.21:30:11.293>
labels = ['interpreter-core', '3.8']
title = 'Remove unicode_format.h from stringlib'
updated_at = <Date 2019-05-06.20:42:20.692>
user = 'https://github.com/ericvsmith'

bugs.python.org fields:

activity = <Date 2019-05-06.20:42:20.692>
actor = 'anthonypjshaw'
assignee = 'eric.smith'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2015-08-25.21:30:11.293>
creator = 'eric.smith'
dependencies = []
files = []
hgrepos = []
issue_num = 24939
keywords = ['patch']
message_count = 6.0
messages = ['249160', '249212', '341626', '341627', '341632', '341642']
nosy_count = 2.0
nosy_names = ['eric.smith', 'anthonypjshaw']
pr_nums = ['13137']
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue24939'
versions = ['Python 3.8']

[ericvsmith]

Objects/stringlib/unicode_format.h does not belong in stringlib. Back when it was originally written for 2.x, it used stringlib to provide the str and unicode versions of str.format, str.__format__, int.__format__, etc.

However, in 3.x, and especially with PEP-393 (Flexible String Representation), not only is the stringlib functionality no longer needed, it's not used at all.

My suggestion is to just copy the source into Objects/unicodeobject.c, which is the only place it's used. Then delete the stringlib file.

The only downside of including it in unicodeobject.c is that it makes our largest C file about 8% larger:

wc -l says:
1284 Objects/stringlib/unicode_format.h
15414 Objects/unicodeobject.c

There's some argument to be made to separate out the int.__format__, float.__format__ etc. code, and move them to some other library. I don't think they're a huge part of unicode_format.h. And to separate them out would require creating some _Py_* functions to do their work. But it's probably the right thing to do. I'll investigate.

[ericvsmith]

Actually, int.__format__, etc. are not in this file. So that's good.

The things that are in this file but are unrelated to unicodeobject.c are the support routines for implementing string.Formatter. I think I'll move those elsewhere, as a first step.

[tonybaloney]

Eric, there have been further changes to Objects/stringlib/unicode_format.h since this original note, I've raised a PR with the intent of your note from 2015.

There also hasn't been any change to the situation, unicode_format.h is only used in unicodeobject.c stil.

[tonybaloney]

The things that are in this file but are unrelated to unicodeobject.c
are the support routines for implementing string.Formatter.

I'm not sure which functions that relates to, if you could let me know I'd be happy to add those to the PR.

[ericvsmith]

I think I meant things like PyFieldNameIter_Type, but it would require some analysis.

[tonybaloney]

The code is mostly:

FieldNameIterator * related functions
FormatterIterator * related functions
MarkupIterator * related functions

There are a few other utility methods in there as well