Hi, That's just a flaming-sword thread but I want to mention it nonetheless :-) Basically I propose getting rid of __future__._Feature.getMandatoryRelease() in favour of __future__._Feature.mandatory. That's backwards compatibile and much more pythonic. Getters/Setters are considered unpythonic and the getting rid of all that Java-like naming sounds like a good idea to me :) If threading/processing gets a pep8ified API with 2.6, why not __future__? Proposed patch: http://paste.pocoo.org/show/64512/ Regards, Armin
I don't see it the same way; this is a terribly unimportant API, so let's not mess with it. threading.py is worth fixing (a) because it's so popular, and (b) because some folks insisted that the new multiprocessing module have an API that is as similar as possible to threading. IOW The general moratorium on pep8ifying remains; we made a specific exception for threading.py for very specific reasons. --Guido On Sat, Jun 7, 2008 at 2:10 PM, Armin Ronacher <armin.ronacher@active-4.com> wrote:
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
We're also only *adding* the PEP 8 compliant API to threading, and leaving the old API in-place indefinitely in the 2.x series. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
I don't see it the same way; this is a terribly unimportant API, so let's not mess with it. threading.py is worth fixing (a) because it's so popular, and (b) because some folks insisted that the new multiprocessing module have an API that is as similar as possible to threading. IOW The general moratorium on pep8ifying remains; we made a specific exception for threading.py for very specific reasons. --Guido On Sat, Jun 7, 2008 at 2:10 PM, Armin Ronacher <armin.ronacher@active-4.com> wrote:
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
We're also only *adding* the PEP 8 compliant API to threading, and leaving the old API in-place indefinitely in the 2.x series. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
participants (3)
-
Armin Ronacher -
Guido van Rossum -
Nick Coghlan