Antoon Pardon <[EMAIL PROTECTED]> writes: > Op 2005-11-25, Mike Meyer schreef <[EMAIL PROTECTED]>: >> Antoon Pardon <[EMAIL PROTECTED]> writes: >>> Well this is, is one thing I have a problem with. >>> The python people seem to be more concerned with fighting things >>> that could be used counter the python philosophy, than search for >>> things that enable working in the python philosophy. >> And what's wrong with that? > It seems a bit intollerant and contraproductive to me.
I suspect it seems that way because you belief two falsehoods: Falsehood #1) There's little or no value in protecting something good. Anyone who's seen a good thing vanish will tell you this isn't so. Falsehood #2) Adding things makes a language better. This simply isn't so. Anyone who's been around computers for any length of time has heard of featuritis. It afflicts programming languages as well. A language with 2n features is not inherently better than a language with n features - it's just got more features. The 2n language may actually be less powerful. You see, you can make languages more powerful by *removing* things from it. Removing static typing leaves you with dynamic typing or duck typing, both of which are more powerful than static typing. Removing the need to explicitly free things - even though explicit is better than implicit - means programmers don't have to worry about such, and pretty much eliminates several classes of bugs. Removing restriction on what you can do to an object - making them "first class" - results in some very powerful facilities that simply don't exist in languages where that hasn't happened. Since I've been writing Python, it's gotten more powerful because of such removals. > If thet would just concentrated on what they want, they could > have progressed further on that road, then where they are now, > because progress sometimes simple stops because other could > use something for what it was not intended. They know what they want. They want python to remain unbroken. Having seen languages that have been broken to appeal to a new user population, to appease a software vendor, and - in an extreme case - because a drunk developer thought it was amusing, I'm *glad* that new features are only added to Python after they've been beaten on and thought about and in general had the implications of adding them explored in depth by the community. >>>> Yes. And if you need a red hammmer, you should get a red hammer, not >>>> use red spray paint on one that wasn't designed to be red. Just >>>> because *you* don't see how providing a red option violates the >>>> philosophy of python doesn't mean that it doesn't do so. >>> Well this seems to be the main conflict between those who would >>> like Python to go a bit further and those that oppose it. >>> Should the priority be to enable python's philosophy or should >>> it be the priority to limit python to only allow it's philosophy. >> Those two statements say the same thing. > They are not. Yes, they are. >> Part of the Python philosphy, >> from "import this", is that there should only be one obvious way to do >> it. > It doesn't say that. It says: > There should be one-- and preferably only one --obvious way to do it. > Here you see the difference on emphasis. You are focussing on the > only one, while the original Python Koan seems to focus on the > there should be one. Wrong. There are some thing which there should *not* be a way to do. For instance, there should not be a way to produce a segmentation fault - which means certain features common to other languages will never be added. We don't talk much about how you produce buffer overfows in Python, but people have asked for that as well. Adding ways to write hard-to-read code is frowned upon. And so on. > So supose someone proposes a change that will introduce one > obvious way, to solve a particular problem. However it > introduces a second obvious way to solve an other problem > too. In other words, they propose a change and come up with a use case, which is SOP. > I think we should accept such a proposal. It seems you and > a lot of others seem to think such proposals should be > rejected. I won't speak for others, but I wouldn't reject it out of hand. You haven't provided enough information. Accepting it just because it adds a way to do something is wrong. First, you have to ask whether or not that something is something we want in Python at all. Then you consider whether how the way proposed fits with the language: is it ugly? Is it prone to abuse? Etc. These could cause a specific proposal to be rejected, even if the proposed facility acceptable. Then you have to consider how it affects the rest of the language. Adding another way to do something isn't reason to reject it out of hand, but it's a minus. Consider whether the same end can be achieved in another way - preferably without changing the language (Python is *very* powerful, a you can do quite a bit with it that isn't obvious), but see if there's some way to do this without negative side effects. Finally, you have to consider the implementation: can it be implemented efficiently and in such a way that it won't be confusing? Features have been rejected at this stage - meaning if the answer changes, they'll show up. In summary, the design philosophy is that it's better to do without some facility than to add it in a way that doesn't fit with the language, and the process reflects that. This process has worked well so far, and there's no obvious reason to think that things would improve if it changed. Python isn't the only language that has that kind of philosophy underlying it, and I find languages built with this philosophy to in general be languages I enjoy writing in, even if they have nothing else in common. <mike -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list