[Python-Dev] PEP 318 restrictions on elements (original) (raw)
[Python-Dev] PEP 318 - generality of list; restrictions on elements
Michael Chermside mcherm at mcherm.com
Wed Mar 10 07:48:57 EST 2004
- Previous message: [Python-Dev] calculator module
- Next message: [Python-Dev] os.rename() behavior
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Aahz writes:
On Monday 08 March 2004 03:32 pm, Aahz wrote:
If def foo() [w1, w2]: pass is valid, this must also always be valid: def foo() [w2]: pass [...] I'm not sure to what extent we can/should enforce this, but I'm -1 on any proposal for which this isn't the documented behavior.
When Python's "consenting adults" philosophy is raised, he replies:
I'd be one of the last people to claim that philosophy should be abandoned, but that doesn't mean I think that Python should permit every possible perversion.
I'd like to defend the idea of allowing arbitrary expressions. If there is a rule that only identifiers are allowed, or only things which simply apply decoration and then return a similar function are allowed... no matter what the rule is, people still have one more rule to memorize. If anything is allowed, then people need memorize no special rules and they will get errors when they misuse things.
- Complex is better than complicated. *
- Special cases aren't special enough to break the rules. *
Also, I would argue that sometimes people will find a use for things which the original designers would never have considered. I would venture a guess (perhaps I'm wrong) that when Guido originally designed classes, he intended each instance to have its own dict. I doubt that he thought (at the time) that it would be a good idea to CHANGE that dict or for it not to be unique to the instance. Yet Alex Martelli's Borg pattern is a brilliant little hack which turns out to work quite nicely. There are probably hundreds of ways that modifying dict could be abused which are NOT brilliant little hacks, but instead are confusing, obfuscating messes. We don't use those. The idea that each "decorator" is simply applied (in order) after the function (or class) is built is a simple, clear idea, and if users choose to do things more peculiar than mere decoration, it is at their own peril.
- Simple is better than complex. *
- If the implementation is easy to explain, it may be a good idea. *
-- Michael Chermside
- Previous message: [Python-Dev] calculator module
- Next message: [Python-Dev] os.rename() behavior
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]