> I think this was based on the assumption that *existing* namespace > package approaches would break under the new scheme. Since that is not > the case, I suspect those previous objections were overstated (and all > packaging related code manages to cope well enough with modules where > the file name doesn't match the package name)
I just drafted a message rebutting Phillip's objection, when I then found that you disagree as well :-) One elaboration: > The downsides, however, are also plentiful. If a package starts > its life as a normal package, it must be renamed when it becomes > a namespace, with the implied consequences for revision control > tools. If a package starts out as a regular (P/__init__.py) package (possibly with __init__.py being empty), then making it a namespace package actually requires no change at all - that single __init__.py could continue to exist. Developers may decide to still delete __init__.py and rename the package to .pyp (with VCS consequences), but that would be their choice deciding whether purity beats practicality in their case (where I think most developers actually would rename the directory once they can drop support for pre-3.3 releases). Regards, Martin _______________________________________________ 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
