Joshua Johnston added the comment: While the RFC makes no mention of empty values either way, it has become standard practice to either omit the key-value completely or pass a key (optional = sign) by itself in these situations so I would consider that as standard behavior.
While I stand by my position that the function is broken in regards to None, I do not have the clout to make this change without support from the community so I will leave it at that. >>>Whether or not adding this feature would require a new keyword argument to >>>urlencode is a judgment call. >>>It might be an acceptable change in a feature release. I do believe that it should be changed in a future release and a new keyword argument would suffice except for when the abstraction level is high enough to shield you from being able to specify this new argument. >>I could imagine some programmer building an internal web service that >>turns the string 'None' back into a Python None value. The fact that it >>would have to be an internal thing would mean we'd never hear about >>it...until we broke it :) I was talking to someone about the same thing during lunch today. This whole bug report came about because I was finding 'None' string values in our app engine datastore because of optional parameters with None values being encoded as 'None'. ---------- _______________________________________ 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
