A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2012-February/116451.html below:

[Python-Dev] Adding a maximum element count to parse_qs?

[Python-Dev] Adding a maximum element count to parse_qs?Antoine Pitrou solipsis at pitrou.net
Mon Feb 13 00:39:46 CET 2012
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.


More information about the Python-Dev mailing list

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