[Python-Dev] PEP 3148 ready for pronouncement (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed May 26 02:10:25 CEST 2010

On 23/05/10 21:56, Lennart Regebro wrote:

On Sun, May 23, 2010 at 13:29, Brian Quinlan<brian at sweetapp.com> wrote:

Parts of it, yes. Just like I can replace most operations in os.path and urlparse with a few lines of code. Yeah, but "parts of" is not the question. I've read the PEP, and I do not know how to implement it. That means it's not a trivial module, so that argument doesn't hold up here, even if we accept it as valid (which I actually don't). I don't think any module in the stdlib is entirely trivial. Yes, even parsing an URL is non-trivial, as shown by the fact that the urlparse module apparently has a bug in it for urls like svn+ssh://foo.bar/frotz. ;-)

In this case, the "trivial" refers to being able to write something that will get the job done for a specific task or application, but that isn't as solid from a reliability/maintainability/portability/scalability point of view.

By providing solid infrastructure in the standard library, we can remove that choice between "do it fast" vs "do it right", by providing ready-made robust infrastructure.

Those that say "just put it on PyPI" may not recognise the additional overhead that can be involved in identifying, obtaining approval to use and ongoing management of additional dependencies in a corporate environment that is actually performing appropriate due diligence in regards to IP licensing. This overhead can be especially significant (and, depending on licence and contract details, even a dealbreaker) for companies with specific IP licensing provisions in their contracts with their clients. It doesn't matter how easy we make it to download PyPI packages, we can't do anything about such company IP management policies (except for making it easier for programmers to violate them thoughtlessly, of course).

To use myself as an example, I have several utilities that I probably would have written differently if the futures module had been available in the standard library at the time I wrote them. As it is, they work well enough, but their usage of the threading module is fairly ad hoc (and migrating them to use multiprocessing would be a fairly complex task, and making that decision run-time selectable even more complicated).

In the near-term, backports of future standard library modules are much easier to get through a corporate review process as the licensing is typically similar to the PSF license (or is even the PSF license itself) and the modules come with a clear roadmap for eliminating the dependency (i.e. once the baseline Python version employed by the company includes the module in the standard library, the external dependency is no longer needed).

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list