On 30 March 2014 17:03, Gregory P. Smith
Okay I see where you're going with this. So long as we limit this to APIs specifically surrounding bytes and bytearray I guess I'm "fine" with it (given the status quo and existing mess of never knowing which behaviors will be allowed where).
Other APIs that accept numbers outside of bytes() and bytearray() related methods should *never* accept a bytes() of any length as valid numeric input.
Yeah, agreed. I've also reworked the relevant section of the PEP to give the examples I posted in my reply to you - I think they do a good job of showing why the current behaviour is problematic, and why "accept both" is the most plausible backwards compatible remedy available to us.
Thanks for exploring all of the APIs, we do have quite a mess that can be made better.
Thank Brandon Rhodes, too - he recently pointed me to bytes.replace() not accepting integers as a specific example of the current behaviour being confusing for users, and after I started down that rabbithole... well, this thread and the PEP were the end result :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia