Package: wnpp Severity: wishlist Owner: Colin Watson <cjwat...@debian.org> X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name : multipart Version : 1.2.1 Upstream Contact: Marcel Hellkamp <m...@gsites.de> * URL : https://github.com/defnull/multipart * License : Expat Programming Lang: Python Description : Python multipart/form-data parser This module provides a fast incremental non-blocking parser for multipart/form-data (HTML5, RFC7578), as well as blocking alternatives for easier use in WSGI or CGI applications: * PushMultipartParser: Fast SansIO (incremental, non-blocking) parser suitable for ASGI, asyncio and other IO, time or memory constrained environments. * MultipartParser: Streaming parser that reads from a byte stream and yields memory- or disk-buffered MultipartPart instances. * WSGI Helper: High-level functions and containers for WSGI or CGI applications with support for both multipart and urlencoded form submissions. For background on this, please see https://bugs.debian.org/1085728. In short, there has historically been an unfortunate namespace collision between the multipart and python-multipart packages on PyPI which makes it difficult for both to exist in the same environment, and now that multipart is recommended as a replacement for parts of the old cgi module that was removed from the standard library in Python 3.13, this is a problem for some outlying parts of the addition of Python 3.13 to Debian. I'm aware that it's normally better to prefix "python-" to Python module source package names to avoid name conflicts with other packaging ecosystems. However, in https://bugs.debian.org/1085728 Sandro made it very clear that he didn't want to rename the existing python-multipart source package to allow for this, and since that bug report already got a bit more contentious than I'd have liked, I really don't want to turn this into a bigger argument. In the circumstances, just "multipart" seems tolerable and the least bad option. I plan to maintain this within the Debian Python Team. It can immediately be used to fix RC bugs in trac-customfieldadmin and trac-wysiwig, and to clean up some vendoring in wadllib; there may be others I haven't spotted yet. -- Colin Watson (he/him) [cjwat...@debian.org]
