Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Fri, Apr 12, 2013 at 7:21 PM, Russell E. Owen wrote: > Using intEnum is certainly doable, but that opens up the door to > comparing values from different Enums, which is not something I'd want > to allow. I agree. Comparing values from different Enums could cause a lot of hard to find bugs. On the other hand, simply checking in `__cmp__` what Enum both values belong to (since they do have a `enum` attribute) should allow us to avoid cross-comparing instead of just raising a TypeError. It's not very intuitive behavior IMHO. Just my 2 cents. -- Fábio Santos ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
Using decode() and encode() would break that predictability. But someone suggested the use of transform() and untransform() instead. That would clarify that the transformation is bytes > bytes and Unicode string > Unicode string. On 23 Apr 2013 05:50, "Lennart Regebro" wrote: > On Tue, Apr 23, 2013 at 4:04 AM, Steven D'Aprano > wrote: > > As others have pointed out in the past, repeatedly, the codec system is > > completely general and can transform bytes->bytes and text->text just as > > easily as bytes<->text. > > Yes, but the encode()/decode() methods are not, and the fact that you > now know what goes in and what comes out means that people get much > fewer Decode/EncodeErrors. Which is a good thing. > > //Lennart > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fabiosantosart%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tightening up the specification for locals()
> Like it or not, people rely on this behavior. I don't think CPython > (or PyPy) can actually afford to change it. If so, documenting it > sounds like a better idea than leaving it undocumented only known to > the "inner shrine" > +1. I am relying on this. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
