RE: [Python-Dev] Re: Subscribing to PEP updates
> Why not just subscribe to > python-checkins and filter out everything *but* nondist/peps? But there are lots of people who might be interested in following PEP updates but not other checkins. Pretty much anyone who considers themselves a "user" of Python not a developer. Perhaps they don't even know C. That's a lot to filter through for such people. (After all, I sure HOPE that only a small fraction of checkins are for PEPs not code.) I'm +0 on it... but I'll mention that if such a list were created I'd subscribe. So maybe that's +0.2 instead. -- Michael Chermside This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it. ___ 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] Re: PEP 246: LiskovViolation as a name
Phillip writes: > IMO, it's simpler to handle this use case by letting __conform__ return > None, since this allows people to follow the One Obvious Way to not conform > to a particular protocol. > > Then, there isn't a need to even worry about the exception name in the > first place, either... +1. Writing a default __conform__ for object is reasonable. Alex writes: > I'd rather not make a change to built-in ``object'' a prereq for PEP 246 Why not? Seems quite reasonable. Before __conform__ existed, there wasn't one for object; now that it exists, object needs one. -- Michael Chermside This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it. ___ 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] bytes.from_hex()
Ron Adam writes: > While playing around with the example bytes class I noticed code reads > much better when I use methods called tounicode and tostring. [...] > I'm not suggesting we start using to-type everywhere, just where it > might make things clearer over decode and encode. +1 I always find myself slightly confused by encode() and decode() despite the fact that I understand (I think) the reason for the choice of those names and by rights ought to have no trouble. I'm not arguing that it's worth the gratuitous code breakage (I don't have enough code using encode() and decode() for my opinion to count in that matter.) But I will say that if there were no legacy I'd prefer the tounicode() and tostring() (but shouldn't it be 'tobytes()' instead?) names for Python 3.0. -- Michael Chermside * This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it. * ___ 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
