This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Move _formatter_* methods from string type into _string module
Type: behavior Stage: resolved
Components: Extension Modules, Library (Lib) Versions: Python 3.2
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: eric.smith Nosy List: eric.araujo, eric.smith, flox, georg.brandl, lemburg, mark.dickinson, terry.reedy
Priority: normal Keywords: patch

Created on 2010-07-29 15:21 by georg.brandl, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
add_string_module.diff georg.brandl, 2010-07-29 15:21 review
Messages (9)
msg111948 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-07-29 15:21
Currently, the string type has two single-underscore methods, _formatter_parser and _formatter_field_name_split, that expose details of the new string formatting implementation to Python, so that it can be used by the string.Formatter class.

This patch removes these methods and puts them into their own "_string" module.
msg113129 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-08-06 19:52
If I understand, the point is to better hide two functions that must be exposed for the benefit of .Formatter but which users really should not use. It would also slightly declutter dir(str) and help(str) which are already unusually 'big'. Sounds reasonable.
msg113131 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-08-06 19:55
The idea seems fine to me.  Hiding the _string module in Objects/unicodeobject.c is a little odd, though:  why not a new Modules/_string.c file?

Is the _string module only used by the string module?
msg113143 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2010-08-06 23:22
Mark Dickinson wrote:
> > 
> > Mark Dickinson <> added the comment:
> > 
> > The idea seems fine to me.  Hiding the _string module in Objects/unicodeobject.c is a little odd, though:  why not a new Modules/_string.c file?
Agreed. Please create a new module C file for this.
msg117282 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-09-24 13:25
My only concern with this is that it would cause other implementations to do the same thing. I assume it's not hard for them, but it is work. I know that IronPython implemented the _formatter_* methods so that they could use as-is.

But that's a small concern, I think this is a good idea in general. I agree it should be its own C module _string.
msg117286 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-09-24 14:27
Now that I start this, I see that it's complicated by the fact that the functions actually being wrapped are in stringlib/string_format.h. That's because in 2.x they compile as both unicode and str. Before the _string module is created, the code should really be moved out of stringlib (possibly into _string). But that's a much more involved task.

I guess it depends if we want to have a bytes version of format(). If we do, it's best to leave the code in stringlib so it can be shared between the implementations. If we never want that, it can be removed from stringlib and put somewhere else, removing the ability to call it both ways. I'll have to give that some thought.
msg117319 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-09-24 18:07
The more I think about this, the more sense it makes to leave the module in unicodeobject.c. Certainly all the code it's likely to ever contain would already be in unicodeobject.c.

While I agree there's some conceptual clarity to be had by having the code in a new Modules/_stringmodule.c (and indeed, that's the first place I'd go if I were looking for it), I think that practically it might make sense to leave it in unicodeobject.c.

On the other hand, there are no modules defined in Objects/*.c, so this is clearly an unusual and unexpected practice.

Maybe a first step would be to commit Georg's patch as-is. Later I'll get rid of stringlib (at least for format()), then at that point rethink where any module should live.

I note that Georg's code doesn't need any tests because the affected code in is already tested and will fail if the module is moved.
msg118628 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-10-14 07:04
Okay, committed as 85456.  I'll leave it to you how to proceed from here.
msg127403 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2011-01-29 11:32
No further action required. I'm not going to remove format() and friends from stringlib as long as there's chatter about adding a .format() for bytes.
Date User Action Args
2022-04-11 14:57:04adminsetgithub: 53664
2011-01-29 11:32:01eric.smithsetstatus: open -> closed
nosy: lemburg, georg.brandl, terry.reedy, mark.dickinson, eric.smith, eric.araujo, flox
messages: + msg127403

resolution: accepted
stage: patch review -> resolved
2010-10-14 21:27:34eric.araujosetnosy: + eric.araujo
2010-10-14 07:04:23georg.brandlsetmessages: + msg118628
2010-09-24 18:07:45eric.smithsetmessages: + msg117319
2010-09-24 14:27:06eric.smithsetmessages: + msg117286
2010-09-24 13:25:21eric.smithsetmessages: + msg117282
2010-09-09 19:17:03floxsetnosy: + flox
2010-08-06 23:22:55lemburgsetnosy: + lemburg
messages: + msg113143
2010-08-06 19:55:35mark.dickinsonsetnosy: + mark.dickinson
messages: + msg113131
2010-08-06 19:52:22terry.reedysetnosy: + terry.reedy
messages: + msg113129
2010-07-29 15:21:37georg.brandlcreate