Return MultipartPart in any case

[defnull]

There is no real (technical or logical) difference between files and forms but a 'filename' attribute. Both can be larger than mem_limit and contain binary data. The parser should return MultipartPart() instances in any case, even if the data was url-encoded, so the user knows what he gets and what to check for.

[wobsta]

forms already contains the decoded values, e.g. (unicode) strings. This is a major difference ... at least right now. I suggest to keep this difference (MultipartPart instance for files and unicode strings for other form fields) and the separation between the two types of return values by the files and forms dicts.

[defnull]

What I do not like at the current implementation is that large forms do raise an exception and there is no way to say "I know this is gonna be big, give me a file object instead".

Think of a forum where an author tries to paste an entire novel into a form field or a scientific application where a biologist pastes a giant genome file into a (this is actually quite common).</p> <p>My idea is that MultipartPart() doubles as a string (<strong>str</strong>), unicode (<strong>unicode</strong>) and file-like object. The first two have a size limit and raise exceptions, but the user can fallback on a sequential .read() if he still wants the data in that form.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/wobsta"><img src="https://avatars.githubusercontent.com/u/274488?v=4" />wobsta</a> commented <strong> 14 years ago</strong> </div> <div class="markdown-body"> <p>Suppose there is a huge field and some other (possibly later) small fields. The memory will be exceeded while reading the huge field. There is no easy way to recover from this situation other than the user telling <em>in</em> <em>advance</em>, that a certain text field should not be load in memory, i.e. becoming part of the forms multidict, but being returned as part of the files multidict. (We should avoid any magic for dropping certain fields from in-memory-handling automatically.) By that the programmer can also prepare his code to properly handle such a field differently. Hence we might add a "not-to-be-loaded" list of field names to <code>parse_form_data</code>.</p> <blockquote> <p>My idea is that MultipartPart() doubles as a string (<strong>str</strong>), unicode (<strong>unicode</strong>) and file-like object.</p> </blockquote> <p>Why do you differentiate between <strong>str</strong> and <strong>unicode</strong>? Multipart is already able to handle the bare data and to return the decoded value. There is a value method with a size limit to fetch the decoded value, which is a unicode string on Python 2.x and a string on Python 3.x. Why should we add a method for loading the encoded value available by the read method anyway? We could also add a possibility to read the decoded value in chunks, but I rarely see a need for that. It can be implemented "cross-plattform" by codecs.lookup(<encoding>).streamreader(<encodedstream>), i.e. this will properly work on Python 2.x and 3.x.</p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>