On Mon, 13 Feb 2012 00:32:07 +0100 martin at v.loewis.de wrote: > >> No, you are missing my point. I assume you proposed (even though you > >> didn't say so explicitly) that parse_qs gets an opt-in API change to > >> limit the number of parameters. If that is added, it will have no > >> effect on any existing applications, as they will all currently not > >> pass that parameter. > > > > No, I said it would include a default value of (say) 1000 parameters. > > That default value would be applied to anyone doesn't use the new API. > > (the reason I'm proposing a new API is to allow people to change or > > disable the limit, in case they really want to pass a large number of > > parameters) > > I see. -1 on that proposal, then: there are certainly applications that will > break with that. I don't find 1000 POST parameters a lot, and I'm sure that > people use that in a programmatic fashion (e.g. to mass-upload stuff). > > If you really think that kind of change is necessary, develop a separate patch > that people who are worried can apply. Fair enough. Actually, people can simply call parse_qsl and check the len() of the returned list before stuffing the params into a dict. That said, we can still do the change (without any limiting default value) for 3.3. Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4