On 23/05/10 21:56, Lennart Regebro wrote:
On Sun, May 23, 2010 at 13:29, Brian Quinlan<br...@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 | ncogh...@gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
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
