[Python-Dev] pep8ity future (original) (raw)
Guido van Rossum guido at python.org
Wed Jun 11 05:12:48 CEST 2008
- Previous message: [Python-Dev] pep8ity __future__
- Next message: [Python-Dev] pep8ity __future__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 at active-4.com> wrote:
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
Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] pep8ity __future__
- Next message: [Python-Dev] pep8ity __future__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]