2012/10/22 Victor Stinner <victor.stin...@gmail.com>: > Hi, > > I forked CPython repository to work on my "split unicodeobject.c" project: > http://hg.python.org/sandbox/split-unicodeobject.c > > The result is 10 files (included the existing unicodeobject.c): > > 1176 Objects/unicodecharmap.c > 1678 Objects/unicodecodecs.c > 1362 Objects/unicodeformat.c > 253 Objects/unicodeimpl.h > 733 Objects/unicodelegacy.c > 1836 Objects/unicodenew.c > 2777 Objects/unicodeobject.c > 2421 Objects/unicodeoperators.c > 1235 Objects/unicodeoscodecs.c > 1288 Objects/unicodeutfcodecs.c > 14759 total > > This is just a proposition (and work in progress). Everything can be changed > :-) > > "unicodenew.c" is not a good name. Content of this file may be moved > somewhere else. > > Some files may be merged again if the separation is not justified. > > I don't like the "unicode" prefix for filenames, I would prefer a new > directory. > > -- > > Shorter files are easier to review and maintain. The compilation is > faster if only one file is modified. > > The MBCS codec requires windows.h. The whole unicodeobject.c includes > it just for this codec. With the split, only unicodeoscodecs.c > includes this file. > > The MBCS codec needs also a "winver" variable. This variable is > defined between the BLOOM filter and the unicode_result_unchanged() > function. How can you explain how these things are sorted? Where > should I add a new function or variable? With the split, the variable > is now defined very close to where is it used. You don't have to > scroll 7000 lines to see where it is used. > > If you would like to work on a specific function, you don't have to > use the search function of your editor to skip thousands to lines. For > example, the 18 functions and 2 types related to the charmap codec are > now grouped into one unique and short C file. > > It was already possible to extend and maintain unicodeobject.c (some > people proved it!), but it should now be much simpler with shorter > files.
I would like to repeat my opposition to splitting unicodeobject.c. I don't think the benefits of such a split have been well justified, certainly not to the point that the claim about "much simpler" maintenance is true. -- Regards, Benjamin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
