I was fooling around with Python 3.1 today, and I found this little nugget:
import __future__ dir(__future__) ['CO_FUTURE_ABSOLUTE_IMPORT', 'CO_FUTURE_BARRY_AS_BDFL', 'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION', 'CO_FUTURE_UNICODE_LITERALS', 'CO_FUTURE_WITH_STATEMENT', 'CO_GENERATOR_ALLOWED', 'CO_NESTED', '_Feature', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', 'absolute_import', 'all_feature_names', 'barry_as_FLUFL', 'division', 'generators', 'nested_scopes', 'print_function', 'unicode_literals', 'with_statement']
hmm... BARRY_AS_BDFL and barry_as_FLUFL
from __future__ import barry_as_FLUFL
nothing noticable happened. I googled the latter, and found that it's an April Fools (of 2009!) checkin that was never reverted. http://mail.python.org/pipermail/python-checkins/2009-April/080796.html
On Wed, Aug 4, 2010 at 3:48 PM, Jasper St. Pierre
I was fooling around with Python 3.1 today, and I found this little nugget:
import __future__ dir(__future__) ['CO_FUTURE_ABSOLUTE_IMPORT', 'CO_FUTURE_BARRY_AS_BDFL', 'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION', 'CO_FUTURE_UNICODE_LITERALS', 'CO_FUTURE_WITH_STATEMENT', 'CO_GENERATOR_ALLOWED', 'CO_NESTED', '_Feature', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', 'absolute_import', 'all_feature_names', 'barry_as_FLUFL', 'division', 'generators', 'nested_scopes', 'print_function', 'unicode_literals', 'with_statement']
hmm... BARRY_AS_BDFL and barry_as_FLUFL
from __future__ import barry_as_FLUFL
nothing noticable happened. I googled the latter, and found that it's an April Fools (of 2009!) checkin that was never reverted.
We don't revert our April Fool's checkins. Easter eggs are forever! -- --Guido van Rossum (python.org/~guido)
Hello
hmm... BARRY_AS_BDFL and barry_as_FLUFL
Oh, bad consistency. Should have been BARRY_AS_FLUFL and barry_as_flufl.
from __future__ import barry_as_FLUFL nothing noticable happened.
I made some tests about that and found that the behavior didn’t match the PEP; I have to redo experiments and eventually report bugs.
I googled the latter, and found that it's an April Fools (of 2009!) checkin that was never reverted.
Why should it be reverted? It causes no harm. Regards P.S. from __future__ import braces
Barry Warsaw
On Aug 04, 2010, at 06:48 PM, Jasper St. Pierre wrote:
hmm... BARRY_AS_BDFL and barry_as_FLUFL [...]
nothing noticable happened. I googled the latter, and found that it's an April Fools (of 2009!) checkin that was never reverted.
Wait. It's a joke?!
That doesn't mean it's not true :-) this-hacker-for-one-welcomes-our-great-FLUFL-'ly yrs, -- \ “… Nature … is seen to do all things Herself and through | `\ herself of own accord, rid of all gods.” —Titus Lucretius | _o__) Carus, c. 40 BCE | Ben Finney
Hi,
I just read an interesting article (interview with Fred Brooks).
See: http://www.informit.com/articles/article.aspx?p=1600886
Eoin: The book contains a lot of explicit and implicit advice for those
who must manage design projects. What would your top three pieces
of advice for such managers be?
Fred:
1. Choose a chief designer separate from the manager and give him
authority over the design and your trust.
2. Plan for the iterative discovery and screening of requirements.
3. Prototype (or simulate with models, etc.) early and get real user
feedback on real use scenarios early and often.
I immediately thought of the Python "process" as a real life example
of this working! Fortunately too, the "crop" of "manager"s is also
growing!
Congratulations to all that have been part of this process!!
Cheers,
--ldl
On Thu, Aug 5, 2010 at 4:22 AM, Greg Ewing
Barry Warsaw wrote:
Wait. It's a joke?!
Probably, but it's also useful behaviour -- I hope it stays!
(Not that I would ever presume to use it in any code inflicted on anyone else, but it's nice to know I have a choice in the privacy of my own computer.)
Heil-the-FLUFl-ly, Greg _______________________________________________ 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/ldlandis%40gmail.com
-- --- NOTE: If it is important CALL ME - I may miss email, which I do NOT normally check on weekends nor on a regular basis during any other day. --- LD Landis - N0YRQ - de la tierra del encanto 3960 Schooner Loop, Las Cruces, NM 88012 575-448-1763 N32 21'48.28" W106 46'5.80"
On Fri, Aug 6, 2010 at 2:25 AM, LD 'Gus' Landis
Hi,
I just read an interesting article (interview with Fred Brooks). See: http://www.informit.com/articles/article.aspx?p=1600886
Eoin: The book contains a lot of explicit and implicit advice for those who must manage design projects. What would your top three pieces of advice for such managers be?
Fred: 1. Choose a chief designer separate from the manager and give him authority over the design and your trust. 2. Plan for the iterative discovery and screening of requirements. 3. Prototype (or simulate with models, etc.) early and get real user feedback on real use scenarios early and often.
I immediately thought of the Python "process" as a real life example of this working! Fortunately too, the "crop" of "manager"s is also growing!
There's actually quite a lot open source and proprietary development in general can learn from each other, but the fact that so many open source developers *aren'* getting paid means that garbage that is tolerated in a proprietary setting doesn't happen as much in open source. One random thing: the knowledge that your commits are going to be broadcast immediately to anyone that is interested, as well as archived permanently on the world wide web is a powerful incentive to: a) write good code b) comment anything that is hackish/tremendously complicated c) write decent checkin messages Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (8)
-
Barry Warsaw -
Ben Finney -
Greg Ewing -
Guido van Rossum -
Jasper St. Pierre -
LD 'Gus' Landis -
Nick Coghlan -
Éric Araujo