On 2005-11-29, Mike Meyer <[EMAIL PROTECTED]> wrote: > Antoon Pardon <[EMAIL PROTECTED]> writes: >>> You see, you can make languages more powerful by *removing* things >>> from it. >> You cast this in way to general terms. The logic conclusion >> from this statements is that the most powerfull language >> is the empty language. > > The only way you reach that conclusion is if you read the statement as > saying that removing things *always* makes a langauge more > powerful. That's not what I said,
I would say it is the common interpretation for such a sentence. > and that's as false as the belief > that adding things always makes a language more powerful. > >>> 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. >> Then C-extentions shouldn't be allowed. > > C-extensions aren't part of Python. As far as I understand, if you implement a class with a C-extension, then that class is understood to be part of Python. So if you think there should be no way to produce a segmentation fault in python you shouldn't allow such classes. >>> 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. >> Do you mean people have asked for the possibility that a buffer >> overflow would overwrite other variables? > > Buffer overflows don't have to overwrite variables. They just asked > how you create buffer overflows in Python. I do wonder what they mean with a buffer overflow. Would the following classify: buf = range(10) buf[10] = 10 >>> 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? >> That is a highly subjective question, answering it says more about >> the person then about the proposal. > > True. But whether or not a language is good is a highly subjective > question. Since the goal - keeping python good to the people who > already consider it good - is subjective, it's only natural that part > of the evaluation process be sujectie. > >>> Is it prone to abuse? >> I don't see why this is always brought up, given the number of >> features that can be abused in python. > > Just because Python isn't perfect is no reason to make it worse. Why is it worse. You seem to think that if one has a toolbox, which lacks a hammer, that the fact that the hammer can be abused makes your toolbox less usefull if you add a hammer to it. We have a toolbox, full of equipment that can be abused, yet that something else can be abused too, seems to be a mayor stumbling block for adding it. >>> 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. >> I don't mind that a proposal is worked on and that counter-proposals >> can be made. But some people just seem to counter any new proposal, >> while other are more interrested in searching for ways to make >> the new proposal fit the language. Now sometimes a proposal can't >> be fitted and gets rejected, so be it. But maybe more could be >> fitted in the langauge if more people were willing to look for >> ways to fit something, instead of rejecting it simply because >> the current proposal doesn't fit properly yet. > > The only way this would be good is if "more features" were inherently > better. That's simply not true. So the change in behavior you're > looking for isn't clearly good. No, this is good while there are still possible features that could make python a better language -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
