This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients Claudiu.Popa, Joshua.Johnston, ezio.melotti, orsenthil, r.david.murray
Date 2013-09-16.01:13:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1379294015.75.0.840709350602.issue18857@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2013-09-16 01:13:35r.david.murraysetrecipients: + r.david.murray, orsenthil, ezio.melotti, Claudiu.Popa, Joshua.Johnston
2013-09-16 01:13:35r.david.murraysetmessageid: <1379294015.75.0.840709350602.issue18857@psf.upfronthosting.co.za>
2013-09-16 01:13:35r.david.murraylinkissue18857 messages
2013-09-16 01:13:33r.david.murraycreate