There's a third possibility, too. It might not be necessary to mention, because I think it's a typical case. It's good to be sure that everyone considers it, though. I think it's best if a module can be developed as a standalone module, first, and incorporated into the standard library after its matured. It's not unusual for substantial user experience to influence the design and implementation of the module. So it's better to wait until after that experience has been achieved to include it in the standard library. A few examples come to mind. I'm sure there are others: asyncore & asynchat, unittest, and xmlrpclib. One possible result of that user experience is that the module isn't right. The problem needs to be solved in a different way, or there are very few people who use the module. In those cases, we're not saddled with a module that we don't want. One example here might by linuxaudiodev. After using this module and doing some maintenance, I'd prefer to see a pure Python version that provided a clearer API to the OSS interface. And the name is bad, too :-). It works on platforms other than Linux. I don't object to using the sandbox, particularly if other resources aren't available. But I'd also be happy to have new modules developed in their own homes. Jeremy
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