R. David Murray added the comment:
Thank you for working on the patches, Claudiu, but...
The backward compatibility concern is valid.
Furthermore, I did a bunch of googling looking for examples. I did not turn up
any examples of APIs that were documented to use parameters without '='...all
the cases I looked at that mentioned "parameter without a value" specified the
"xxx=" form.
Given that, and thinking about it further, it appears to me that a parameter
with no '=' should be treated the same as one that has an '=' but no
value...that is, the same as using an empty string. It would be *logical* for
it to be a "nul" value, but in fact the http RFCs have no concept of a "nul"
value, so it is in fact out of place.
Sorry to have sent people down the wrong path here.
So I'm back to saying that one should not use None in an application to
represent no value for a query parameter, but rather the empty string. The url
parsing code should turn a parameter without an '=' into an empty string, I
think, but again there are backward compatibility concerns there. There may be
code that unintentionally depends on them being discarded.
So, I *think* we could, and should, make them not ignored, but turned into
empty strings, in 3.4, following the first part in Postel's law ("be generous
in what you accept"). But following the second half of Postel's law ("be
strict in what you generate") we really shouldn't generate parameters without
even an '=', given that they are not RFC compliant.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
