Am 07.03.2006 um 11:49 schrieb Christian Boos:
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...
I think cStringIO is going to go away when we move to Unicode
anyway... Jonas?
Ok, now I'll try to "categorize" all the symbols we have in util.py:
=> algo (frozenset, reversed, sorted, embedded_numbers)
Most of those could be moved into a "trac.util.compat" module, cause
they only provide features that come builtin with Python 2.4.
=> date (pretty_timedelta, format_datetime, format_date, format_time,
get_datetime_format_hint, http_date, parse_date)
=> trac (TracError)
Is going to move to trac.core (you can - and should - already import
it from there right now)
=> 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.
Yeah, I'd keep most of the others directly in __init__.py for now...
they can still be split out later.
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev