[issue9418] Move _formatter_* methods from string type into _string module
Eric Smith e...@trueblade.com added the comment: 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. -- resolution: - accepted stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9418] Move _formatter_* methods from string type into _string module
Georg Brandl ge...@python.org added the comment: Okay, committed as 85456. I'll leave it to you how to proceed from here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9418] Move _formatter_* methods from string type into _string module
Changes by Éric Araujo mer...@netwok.org: -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9418] Move _formatter_* methods from string type into _string module
Eric Smith e...@trueblade.com added the comment: 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 string.py 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9418] Move _formatter_* methods from string type into _string module
Eric Smith e...@trueblade.com added the comment: 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9418] Move _formatter_* methods from string type into _string module
Eric Smith e...@trueblade.com added the comment: 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 string.py is already tested and will fail if the module is moved. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9418] Move _formatter_* methods from string type into _string module
Changes by Florent Xicluna florent.xicl...@gmail.com: -- nosy: +flox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9418] Move _formatter_* methods from string type into _string module
Terry J. Reedy tjre...@udel.edu added the comment: 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. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9418] Move _formatter_* methods from string type into _string module
Mark Dickinson dicki...@gmail.com 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? Is the _string module only used by the string module? -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9418] Move _formatter_* methods from string type into _string module
Marc-Andre Lemburg m...@egenix.com added the comment: Mark Dickinson wrote: Mark Dickinson dicki...@gmail.com 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. -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9418] Move _formatter_* methods from string type into _string module
New submission from Georg Brandl ge...@python.org: 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. -- assignee: eric.smith components: Extension Modules, Library (Lib) files: add_string_module.diff keywords: patch messages: 111948 nosy: eric.smith, georg.brandl priority: normal severity: normal stage: patch review status: open title: Move _formatter_* methods from string type into _string module type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file18253/add_string_module.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
