Showing content from http://mail.python.org/pipermail/python-dev/attachments/20060427/0dfbd77a/attachment.htm below:
On 4/26/06, <b class="gmail_sendername">Guido van Rossum</b> <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br><div><span class="gmail_quote">[...]<br></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So I have a very simple proposal: keep the __init__.py requirement for<br>top-level pacakages, but drop it for subpackages. This should be a<br>small change. I'm hesitant to propose *anything* new for Python 2.5,<br>so I'm proposing it for
2.6; if Neal and Anthony think this would be<br>okay to add to 2.5, they can do so.</blockquote><div><br> Damn these threads are so quick they are born and die off in 24 hours and don't give enough time for people to comment :(
<br><br> I'm a bit late in the thread, but I'm +1 (for 2.5) for the following reason. There are mainly two use cases for having a couple of modules foo.bar, and foo.zbr:<br><br> 1. foo.bar and foo.zbr are both part of the same _package_, and are distributed together;
<br><br> 2. foo.bar and foo.zbr are two independent modules, distributed separately, but which share a common 'foo' _namespace_, to denote affiliation with a project.<br><br> The use case #1 is arguably more common, but use case #2 is also very relevant. It happens for a lot of GNOME python bindings, for example, where we used to have gnome,
gnome.ui, gnome.vfs, gnome.applet, etc.<br><br> Now the problem. Suppose you have the source package python-foo-bar, which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This would make a module called "
foo.bar" available. Likewise, you can have the source package python-foo-zbr, which installs
$pythondir/foo/__init__.py and $pythondir/foo/zbr.py. This would make
a module called "foo.zbr" available.<br><br> The two packages above install the file $pythondir/foo/__init__.py. If one of them adds some content to __init__.py, the other one will overwrite it. Packaging these two packages for
e.g. debian would be extremely difficult, because no two .deb packages are allowed to intall the same file.<br><br> One solution is to generate the __init__.py file with post-install hooks and shell scripts. Another solution would be for example to have only python-foo-bar install the __init__.py file, but then python-foo-zbr would have to depend on python-foo-bar, while they're not really related.
<br><br> I hope I made the problem clear enough, and I hope people find this a compelling argument in favour of eliminating the need for __init__.py.<br><br><br> Regards,<br><br>Gustavo Carneiro.<br></div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4