[Python-3000] Looking for advice on PEP 3101 implementation details

[Guido van Rossum]

On 8/17/07, Eric Smith <eric+python-dev at trueblade.com> wrote:
> I'm refactoring the sandbox implementation, and I need to add the code
> that parses the standard format specifiers to py3k.  Since strings,
> ints, and floats share same format specifiers, I want to have only a
> single parser.

Really? Strings support only a tiny subset of the numeric
mini-language (only [-]N[.N]).

> My first question is:  where should this parser code live?  Should I
> create a file Python/format.c, or is there a better place?  Should the
> .h file be Include/format.h?

Is it only callable from C? Or is it also callable from Python? If so,
how would Python access it?

> I also need to have C code that is called by both str.format, and that
> is also used by the Formatter implementation.
>
> So my second question is:  should I create a Module/_format.c for this
> code?  And why do some of these modules have leading underscores?  Is it
> a problem if str.format uses code in Module/_format.c?  Where would the
> .h file for this code go, if str.format (implemented in unicodeobject.c)
> needs to get access to it?
>
> Thanks for your help, and ongoing patience with a Python internals
> newbie (but C/C++ veteran).

Unless the plan is for it to be importable from Python, it should not
live in Modules. Modules with an underscore are typically imported
only by a "wrapper" .py module (e.g. _hashlib.c vs. hashlib.py).
Modules without an underscore are for direct import (though there are
a few legacy exceptions, e.g. socket.c should really be _socket.c).

Putting it in Modules makes it harder to access from C, as those
modules are dynamically loaded. If you can't put it in floatobject.c,
and it's not for import, you could create a new file under Python/.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)