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'.