Christopher Lenz wrote:
Hey folks,
trac.util is becoming a dropbox for all sorts of (more or less)
reusable code. Before its size gets out of hand, I'd like to make it a
package (instead of a module), and split off some functionality (such
as the date formatting or the Markup class) into separate modules
inside that package.
A lot of the functions will remain in trac/util/__init__.py, and
whatever gets moved out should be made available at the package level
(through an import in __init__.py) as to not break
backward-compatibility.
What do you think?
Yes, that's a good idea.
I was also thinking about putting some more stuff in util,
like defining a trac.util.StringIO that would factor out the
try: from cStringIO ... catch: stuff we have everywhere...
Ok, now I'll try to "categorize" all the symbols we have in util.py:
=> algo (frozenset, reversed, sorted, embedded_numbers)
=> date (pretty_timedelta, format_datetime, format_date, format_time,
get_datetime_format_hint, http_date, parse_date)
=> trac (TracError)
=> trac.web (get_reporter_id)
=> os (NaivePopen, create_unique_file)
=> text (to_utf8, shorten_line, pretty_size, wrap)
=> sys (safe__import__)
=> html (Markup, escape, unescape, rss_title, Deuglifier)
=> crypt (hex_entropy, md5crypt)
As you proposed, we should probably separate in new files
the html and date (datetime?) stuff.
The rest should be rearranged in groups, e.g.
# -- Algorithmic utilities
# -- OS utilites
...
Also, maybe the get_reporter_id can be moved in trac.web.api?
And what about moving TracError directly in the trac package?
-- Christian
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
