[Python-Dev] PEP 3148 ready for pronouncement

[Glyph Lefkowitz]

On May 26, 2010, at 3:37 AM, Paul Moore wrote:

> On 26 May 2010 08:11, Lennart Regebro <regebro at gmail.com> wrote:
>> On Wed, May 26, 2010 at 06:22, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> - download a futures module from PyPI and live with the additional
>>> dependency
>> 
>> Why would that be a problem?
> 
> That has been hashed out repeatedly on this and other lists. Can it
> please be stipulated that for *some* people, in *some* cases, it is a
> problem?

Sure, but I for one fully support Lennart asking the question, because while in the short term this *is* a problem with packaging tools in the Python ecosystem, in the long term (as you do note) it's an organizational dysfunction that can be addressed with better tools.

I think it would be bad to ever concede the point that sane factoring of dependencies and code re-use aren't worth it because some jerk in Accounting or System Operations wants you to fill out a requisition form for a software component that's free and liberally licensed anyway.

To support the unfortunate reality that such jerks in such departments really do in fact exist, there should be simple tools to glom a set of small, nicely factored dependencies into a giant monolithic ball of crud that installs all at once, and slap a sticker on the side of it that says "I am only filling out your stupid form once, okay".  This should be as distant as possible from the actual decision to package things in sensibly-sized chunks.

In other words, while I kinda-sorta buy Brian's argument that having this module in easy reach will motivate more people to use a standard, tested idiom for parallelization, I *don't* think that the stdlib should be expanded simply to accommodate those who just don't want to install additional packages for anything.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100526/1f600358/attachment.html>