On 8/17/07, Eric Smith <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > On 8/17/07, Eric Smith <[EMAIL PROTECTED]> 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]). > > I think strings are: > [[fill]align][width][.precision][type]
The fill doesn't do anything in 2.x. > ints are: > [[fill]align][sign][width][type] I thought the sign came first. But it appears both orders are accepted. > floats are the full thing: > [[fill]align][sign][width][.precision][type] > > They seem similar enough that a single parser would make sense. Is it > acceptable to put this parse in unicodeobject.c, and have it callable by > floatobject.c and longobject.c? I'm okay with that, I just want to make > sure I'm not violating some convention that objects don't call into each > other's implementation files. Sure, that's fine. > >> 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 think the parser only needs to be callable from C. Great. > >> 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). > > The PEP calls for a string.Formatter class, that is subclassable in > Python code. I was originally thinking that this class would be written > in Python, but now I'm not so sure. Let me digest your answers here and > I'll re-read the PEP, and see where it takes me. Also talk to Talin, we had long discussions about this at some point. I think the Formatter class can be written in Python, because none of the C code involved in the built-in format() needs it. > > 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/. > > Okay. Thanks for the help. You're welcome. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
