[Python-Dev] Update PEP 292

Barry Warsaw barry at python.org
Fri Aug 20 01:17:06 CEST 2004


On Thu, 2004-08-12 at 17:12, Raymond Hettinger wrote:

> After more thought, I would like to voice a strong -1 on the packaging
> of string.

Since few people have commented either way, and taking myself out of the
picture, it comes down to a battle royale between you and Brett. :)

Seriously, I'm willing to drop this non-PEP'd suggestion, since it just
makes my life easier, however see below.

> At the outset, I felt that it introduced unnecessary complexity.  Adding
> a new directory, an __init__.py, and two modules just to add a few lines
> of code is overkill.  Package logic should be reserved for organizing
> voluminous code like the email package.  Arguably, the logging package
> should have been just a single module -- putting it in a package just
> made it more difficult to read and maintain.

I think that logging would have been much more readable if more stuff
were taken out of its __init__.py and put into sub-package modules.  I
happen to like the way email does it, and I've come to believe that
package authors should strive for minimal __init__.py's, at most
exposing the public interface for the package but keeping code to a
minimum.  That's besides the point though.

> To test the existing sandbox code, I moved it into the library and found
> a circular import issue:  importing the string package, causes
> template.py to be imported, which in turn imports re which uses
> sre_parse.py, needs to import string.  So, the whole thing fails.

Something's wacky with either your, or my setup then:

Python 2.4a2 (#1, Aug 18 2004, 00:08:12)
[GCC 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)] on
linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from string import Template
[25426 refs]

I'd like to know if anybody else has tried to wedge the sandbox
implementation into their Python tree, and whether it worked or not.  If
you do, don't forget to remove your old string.py and string.pyc files.

> My recommendation:  Create a stringtools module with the new template
> stuff in it and with room for growth.  Leave string.py alone and let it
> die in peace.

As I told Raymond in pvt email, I'm really not happy with creating
another string module.  I hate stringlib.py and stringtools.py seems too
contrived.  I'm putting this as an open issue in the PEP's next rev, but
to me the most logical place to put the Template and SafeTemplate
classes is in the string module.  So if we /don't/ reorganize string,
then I propose to just drop these two classes in string.py.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040819/59098ad9/attachment.pgp


More information about the Python-Dev mailing list