Re: Python as Guido Intended
On 2005-11-30, Dave Hansen [EMAIL PROTECTED] wrote: On 30 Nov 2005 10:57:04 GMT in comp.lang.python, Antoon Pardon [EMAIL PROTECTED] wrote: 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. I hope no one ever tells you that you'd be healthier if you ate less and exercised more. (Perhaps it's not true in your case, but it certainly is in mine.) But that is IMO not a good analogy. A better analogy would be: You can make persons healthier by making them eat less and execise more. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
On 2005-11-30, Mike Meyer [EMAIL PROTECTED] wrote: Antoon Pardon [EMAIL PROTECTED] writes: 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. You'd be wrong. Can denotes a possibility, not a certainty. You didn't write: Removing things can make a language more powerfull. You wrote: You can make a language more powerfull by removing things. In the first case can describes a possible outcome of removing things. In the second case can describes that this is a decision you are allowed and able to make. Not the possibility of the outcomes should you make the decision. What your sentence states is that you can make this decision and that if you do so, removing things will accomplish this goal If I'd say You *will* make languages more powerful by removing features, then you'd be right. But that isn't what I said. No this states that I don't have a choice in removing features or not. Anyway that is how I read those sentences. I just want to add that I'm not interrested in whether your interpretation is the right one or mine. I understand now what you meant and that is enough for meu. The above should be considered as an explanation of how understood, not as a correction of how yuo should have wrote it. 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 Well, you'd have to ask them. Personsally, I wouldn't count that, because no data outside the scope of buf got written to. I find this odd. You seem to argue that you don't want bufferoverflows allowed in python, but then you don't seem to know what is meant by it. If you don't know what they mean, how can you decide you don't want it. And I seem to remember people asking about the possibility of overflow in Python, but I never understood those inquiries in the sense they would want it, but more in a sense of how python protects against it. So I have a bit of a problem understanding the relevance here. 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. Look again. I never said it would make Python less useful, I said it would make it worse. Those aren't the same thing. It's possible to make a language both more useful and worse at the same time. For instance, Python would clearly be more useful if it could interpret perl 6 scripts. I disagree. Having more possibilities doesn't imply more usefull. One of my nefews has this kind of army swiss knife with tons of possibilities. But I find the few tools I have that total less possibilities more usefull. Now adding a extra possibilty to the army swiss knife may make it worse, less usefull. Putting an extra tool in my toolbox doesn't make it worse or less usefull, since I can just ignore the tools I don't use. Personally, I think adding the features required to do that would make the language (much, much) worse. Oddly enough, I think adding the features to Perl so it could interpret Python scripts would make it better as well as more useful :-). We have a toolbox, full of equipment that can be abused, yet that
Re: Python as Guido Intended
Antoon Pardon [EMAIL PROTECTED] wrote: On 2005-11-30, Mike Meyer [EMAIL PROTECTED] wrote: You'd be wrong. Can denotes a possibility, not a certainty. You didn't write: Removing things can make a language more powerfull. You wrote: You can make a language more powerfull by removing things. In the first case can describes a possible outcome of removing things. In the second case can describes that this is a decision you are allowed and able to make. Not the possibility of the outcomes should you make the decision. That's a distinction that exists. I don't see how it's significant here. Do you believe that these two statements are contradictory? You can make X more powerful by removing things. You can make X less powerful by removing things. How about these two, do you think they're contradictory? You can make X more powerful by removing things. You can make X more powerful by adding things. In fact, neither of those pairs are contradictory. All of them can be truthful about the same X simultaneously. What your sentence states is that you can make this decision and that if you do so, removing things will accomplish this goal No. The statement says nothing about *which* things need to be removed to meet the goal. It doesn't say that removing *any* thing from the language will make it more powerful. I think this is an understandably subtle linguistic point for someone who doesn't have English as a first language; it's ambiguous enough that even native speakers could twist it to read more that it actually says. Now that you understand what Mike was trying to say, and Mike has clarified what his statement meant, can we move on to another argument? I just want to add that I'm not interrested in whether your interpretation is the right one or mine. I understand now what you meant and that is enough for meu. The above should be considered as an explanation of how understood, not as a correction of how yuo should have wrote it. An object lesson in taking programmers at their word :-) -- \ I went to San Francisco. I found someone's heart. -- Steven | `\Wright | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Antoon Pardon [EMAIL PROTECTED] writes: 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 Well, you'd have to ask them. Personsally, I wouldn't count that, because no data outside the scope of buf got written to. I find this odd. You seem to argue that you don't want bufferoverflows allowed in python, but then you don't seem to know what is meant by it. If you don't know what they mean, how can you decide you don't want it. I know what *I* mean by it, and I don't want to allow that. You asked what someone else meant by it - I don't know that. The best I can do is give you my take on it. So I have a bit of a problem understanding the relevance here. It's one of the list of things people ask about an extensions. FWIW, that list is meant to be examples, not a definition. There are *lots* of other things to check. 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. Look again. I never said it would make Python less useful, I said it would make it worse. Those aren't the same thing. It's possible to make a language both more useful and worse at the same time. For instance, Python would clearly be more useful if it could interpret perl 6 scripts. I disagree. Having more possibilities doesn't imply more usefull. You're right. But I didn't say that. Now adding a extra possibilty to the army swiss knife may make it worse, less usefull. Putting an extra tool in my toolbox doesn't make it worse or less usefull, since I can just ignore the tools I don't use. Not true. If I put enough extra tools in your toolbox, it will eventually get to heavy to lift. A single tool, poorly chosen - like a band saw - could have the same effect. Personally, I think adding the features required to do that would make the language (much, much) worse. Oddly enough, I think adding the features to Perl so it could interpret Python scripts would make it better as well as more useful :-). 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. Major is your word, not mine. That is the impression I get from the emphasis that is always put on abuse possibilities of a proposed addition in this group. Well, if they're bad enough to bring up, they probalby are major. I just listed it as something to consider. It may be there's an obscure corner case that's really abusive, but chances are no one would ever stumble over it. That's not a major problem. On the other hand, if there's an obvious and attractive use that's abusive, that's a reason for looking for another way to add that functionality. Well you said it, that's a reason for looking for another way to add that functionality. My impression is that few people look at it that way, but instead seem to think it a reason to simply reject the functionality. So? If they don't need the functionality, why should they look for another way to add it? In fact, there's a fair chance they aren't really qualified to evaluate a proposed solution in terms of adding the proper functionality. Like I said before (or elsewhere), most people won't bother with that, but a few language wonks will. If you want another feature, it's up to you to propose an acceptable mechanism to add it - or convince someone else to do it for you. If you expect people to do work for you gratis on a regular basis, I'm afraid you're in for a lot of dissapointment. mike -- Mike Meyer [EMAIL PROTECTED]
Re: Python as Guido Intended
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
Re: Python as Guido Intended
On 30 Nov 2005 10:57:04 GMT in comp.lang.python, Antoon Pardon [EMAIL PROTECTED] wrote: 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. I hope no one ever tells you that you'd be healthier if you ate less and exercised more. (Perhaps it's not true in your case, but it certainly is in mine.) Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Antoon Pardon [EMAIL PROTECTED] wrote: On 2005-11-29, Mike Meyer [EMAIL PROTECTED] wrote: Antoon Pardon [EMAIL PROTECTED] writes: Mike Meyer wrote: 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. You'd be wrong. you can do X by doing foo does not exclude you can do the opposite of X by doing foo. Stating you can make a lot of money by investing in the stock market does not imply that is the only possible outcome, nor even the most likely. 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. I see Mike arguing that the debate before adding the hammer is a good thing. It ensures that only the *really* good tools -- the ones that are so beneficial that they outweigh complicating the toolset -- actually get added; and only when they are in a form that they overcome many objections. 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 Then let's subject those possible features -- with their real use cases and implementations -- to harsh scrutiny, over an extended time, before deciding they'll be a net benefit. -- \ Unix is an operating system, OS/2 is half an operating system, | `\ Windows is a shell, and DOS is a boot partition virus. -- | _o__) Peter H. Coffin | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Antoon Pardon [EMAIL PROTECTED] writes: 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. You'd be wrong. Can denotes a possibility, not a certainty. If I'd say You *will* make languages more powerful by removing features, then you'd be right. But that isn't what I said. 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. You understand wrong. 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 Well, you'd have to ask them. Personsally, I wouldn't count that, because no data outside the scope of buf got written to. 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. Look again. I never said it would make Python less useful, I said it would make it worse. Those aren't the same thing. It's possible to make a language both more useful and worse at the same time. For instance, Python would clearly be more useful if it could interpret perl 6 scripts. Personally, I think adding the features required to do that would make the language (much, much) worse. Oddly enough, I think adding the features to Perl so it could interpret Python scripts would make it better as well as more useful :-). 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. Major is your word, not mine. I just listed it as something to consider. It may be there's an obscure corner case that's really abusive, but chances are no one would ever stumble over it. That's not a major problem. On the other hand, if there's an obvious and attractive use that's abusive, that's a reason for looking for another way to add that functionality. 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
Re: Python as Guido Intended
On 2005-11-28, Mike Meyer [EMAIL PROTECTED] wrote: 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. I don't beleif this. What I do believe is, that it is better to produce more good with those who think likewise than to prevent those who think differently, from doing what you think is bad. Falsehood #2) Adding things makes a language better. I don't believe this either. 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. You cast this in way to general terms. The logic conclusion from this statements is that the most powerfull language is the empty language. Removing static typing leaves you with dynamic typing or duck typing, both of which are more powerful than static typing. Static typing allows for some things that dynamic typing can't do. At least not as python uses it. 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. Well if you call eliminating restrictions, removing something from the language I guess you can say that removing things can make a language more powerfull. But eliminating restrictions IMO is adding things to the language, those things that were formerly unallowed because of the restrictions, not removing things from the language. 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. Then C-extentions shouldn't be allowed. 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? 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
Re: Python as Guido Intended
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, 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. 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 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. 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 there should be one obvious way to do things. That there are lots of unobvious way to do the same thing thus shouldn't count against a proposal that introduces an obvious way to do it. Obvious is also a subjective statement, so adding *any* other way to do things is a minus. 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. Further, if someone doesn't have a need, trying to make someone elses need fit is largely a waste of their time, though some people - language wonks - will do it anyway. On the other hand, pointing out that something is bad is *not* a waste of their time, as it protects something good. So basically, you're asking that people waste their time on something of dubious value. Not a request that's likely to be get very far. 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
Re: Python as Guido Intended
Op 2005-11-25, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: Op 2005-11-24, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: The usual response is That's not the Python way. That's not calling someone dumb, just pointing out that they don't yet fully understand the Python way. That is not the Python way, is just saying Python doesn't have it in other words. So it can't be the answer to why python can't have something. No, it isn't. At least, it isn't when I use it. A language is more than just an accumulation of features. Well, a good language is more than just an accumulation of features - there's a philosophy underlying the language, that guides what features are added and what features aren't. Other languages have other philosophies, and wind up being good for other things. But how this philosophy influences design is not straight forward. The ternary operator was thought of to go against the philosopy, By who? I would guess in the first place by Guido. Just look at the history of how it finaly came to be present and IMO the only conclusion is that Guido doesn't like a ternary operator. Then there were those who always argued against the ternary operator. I'm sure you can dig up some names if you go through google groups. and now seems to be at least compatible with the philosophy. So when someone asks why it is not in python, saying It is not the python way still doesn't answer the question, because the person would probably still like to know what in his proposal is against the python philosophy and why. Sometimes, such things are easy to explain, and they'll generally get that explanation. Sometimes they aren't, Well maybe that are not that easy to explain because they aren't. so you're reduced to pointing out similar - but more obvious - things that aren't in the language, and import this, and suggesting that they try it for a while and see how it works My vision isn't perfect - I've changed my mind about things: I used to want real macros, and I initially disliked list comprehensions. My vision doesn't agree with the developers - notably including Guido's - a lot of the time. On the other hand, they haven't done anything that strikes me as so wrong that I want to spend the time required working on Python rather than in Python to allow me to get it fixed. I see nothing wrong with that. But I would apreciate it, should you be more open about something being your personal vision. To me something like: That is not the python way comes accross as: You just don't understand about python, if you ask/propose something like that That's essentially true. In some cases, the reasons can be explained without understanding about python. In some cases, they can't. Which IMO makes python like a cult. The characteristic of certain things only explainable to those who have seen the light, makes for a view that never needs to fear being contradicted. Well I'm sorry that I can't explain it to you, but you just don't understand Python. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
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. 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. 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. 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. 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. I think we should accept such a proposal. It seems you and a lot of others seem to think such proposals should be rejected. By enabling that part of Python's philosphy, you're automatically limiting python to not allow other - specifically non-pythonic - ways to do the same thing. No it doesn't. Supose someone proposes a change that will introduce one obvious way, to solve a particular problem. However it introduces a second non pythonic way to solve an other problem. I don't think there is something wrong with accepting this change. However it seems you do. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Op 2005-11-28, Serge Orlov schreef [EMAIL PROTECTED]: Antoon Pardon wrote: No it wasn't. From what I have picked up, the ternary operator was finaly introduced after one of the developers tripped over the commonly used idiom to simulate a ternary operator, which can fail in certain cases. Anyway, when I was arguing for a ternary operator in python, those who opposed me, certainly gave me the impression that they thought I wanted to mangle the language, the mere idea of a ternary operator was against the spirit of python. When I argued for a more general loop construct similar objections were made and the proposal was fiercely fought. Someone even started a PEP, with the intention to bury the idea. (That can be from before I argued for it) Now I have read about both that they will be introduced in Python 2.5 without a whisper of protest. Protesting BDFL is absolutely useless by definition even if you disagree. Tim Peters wanted generators for 10 years http://mail.python.org/pipermail/python-list/2001-June/050146.html and he has much more power of convincing Guido than you. Why do you think your proposal should be immediately accepted? I don't think that. I was just illustrating that using: That is unpythonic isn't really an argument, because things that were thought unpythonic before are now accepted as the pythonic way. By the way, I don't see the features you mentioned neither in http://svn.python.org/view/python/trunk/Doc/whatsnew/whatsnew25.tex?rev=39802view=auto nor among PEPs. Perhaps they are not final? There were people who annouced these features in this newsgroup for version 2.5 with a rather clear titles and those from the dev-list that frequent this newsgroup didn't protest. Among the PEP's I see that at least PEP 308 is accepted. So although it may not be implemented for version 2.5 a ternary operator is now an accepted as being pythonic. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Op 2005-11-25, EP schreef [EMAIL PROTECTED]: What is the philosophy? I'm not the one to answer that, but I do use import this for reference, and it seems to answer some of the points in this thread: import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! No, it doesn't answer anything. My impression is that the Zen of Python gets used a lot by the python people like the bible is used by the christions: You can always find a verse/Koan that supports your view. If someone comes with a pratical proposal that breaks a rule, the proponents will cite: practical beats purity and the opponents will cite: Special cases aren't special enough to break the rules: And each will be convince that his view is the pythonic one. I'm even of the impression that what is considered pythonic or not is more related to who proposes it that to what the proposal is and that after one has so decided the right rules are selected to defend that decision. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
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,
RE: Python as Guido Intended
Bryan wrote: i agree with you... pyrex should be part of the python distribution :) And this has been discussed on python-dev. Greg has stated though that he doesn't feel it's ready (there are other factors, but this one is overriding). There were also discussions about the fact that to get maximum performance out of pyrex, it's necessary to produce very non-pythonic code. FWIW, I'm strongly in favour of Pyrex eventually becoming part of the Python distribution. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Antoon Pardon wrote: No it wasn't. From what I have picked up, the ternary operator was finaly introduced after one of the developers tripped over the commonly used idiom to simulate a ternary operator, which can fail in certain cases. Anyway, when I was arguing for a ternary operator in python, those who opposed me, certainly gave me the impression that they thought I wanted to mangle the language, the mere idea of a ternary operator was against the spirit of python. When I argued for a more general loop construct similar objections were made and the proposal was fiercely fought. Someone even started a PEP, with the intention to bury the idea. (That can be from before I argued for it) Now I have read about both that they will be introduced in Python 2.5 without a whisper of protest. Protesting BDFL is absolutely useless by definition even if you disagree. Tim Peters wanted generators for 10 years http://mail.python.org/pipermail/python-list/2001-June/050146.html and he has much more power of convincing Guido than you. Why do you think your proposal should be immediately accepted? By the way, I don't see the features you mentioned neither in http://svn.python.org/view/python/trunk/Doc/whatsnew/whatsnew25.tex?rev=39802view=auto nor among PEPs. Perhaps they are not final? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Mike Meyer [EMAIL PROTECTED] writes: Those two statements say the same thing. Part of the Python philosphy, from import this, is that there should only be one obvious way to do it. By enabling that part of Python's philosphy, you're automatically limiting python to not allow other - specifically non-pythonic - ways to do the same thing. Sometimes there are zero obvious ways to do it, or an obvious way that doesn't work, so if you want to do it at all, you have to find a contorted way. At that point it's normal to ask why there isn't an obvious way that works. All too often, the answer is that would be un-Pythonic. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Paul Rubin http://[EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: Those two statements say the same thing. Part of the Python philosphy, from import this, is that there should only be one obvious way to do it. By enabling that part of Python's philosphy, you're automatically limiting python to not allow other - specifically non-pythonic - ways to do the same thing. Sometimes there are zero obvious ways to do it, or an obvious way that doesn't work, so if you want to do it at all, you have to find a contorted way. At that point it's normal to ask why there isn't an obvious way that works. All too often, the answer is that would be un-Pythonic. Examples? 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
Re: Python as Guido Intended
Op 2005-11-24, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: The usual response is That's not the Python way. That's not calling someone dumb, just pointing out that they don't yet fully understand the Python way. That is not the Python way, is just saying Python doesn't have it in other words. So it can't be the answer to why python can't have something. No, it isn't. At least, it isn't when I use it. A language is more than just an accumulation of features. Well, a good language is more than just an accumulation of features - there's a philosophy underlying the language, that guides what features are added and what features aren't. Other languages have other philosophies, and wind up being good for other things. But how this philosophy influences design is not straight forward. The ternary operator was thought of to go against the philosopy, and now seems to be at least compatible with the philosophy. So when someone asks why it is not in python, saying It is not the python way still doesn't answer the question, because the person would probably still like to know what in his proposal is against the python philosophy and why. When I say That's not the Python way, I mean that such a feature runs counter to my vision of Python's underlying philosophy. Fine, but it would help if you could support this with arguments or at least give an explanation of why you think this is so. My vision isn't perfect - I've changed my mind about things: I used to want real macros, and I initially disliked list comprehensions. My vision doesn't agree with the developers - notably including Guido's - a lot of the time. On the other hand, they haven't done anything that strikes me as so wrong that I want to spend the time required working on Python rather than in Python to allow me to get it fixed. I see nothing wrong with that. But I would apreciate it, should you be more open about something being your personal vision. To me something like: That is not the python way comes accross as: You just don't understand about python, if you ask/propose something like that It gives me the feeling the person is saying something like: Python is like this, I like it this way, so nobody better suggests this changes. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Op 2005-11-24, Mike Meyer schreef [EMAIL PROTECTED]: [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: Different programming styles are appropriate for different tasks, different times and different places, different people. And like morality, government, or economics, I do not believe that one style of programming fits all situations. If I read you right, what you're saying is that hammmers aren't good at driving screws. I don't think anyone would argue about that. No, the analogy is more like this. Python is hammer that comes in green or blue. The hammer's developers say (perhaps with some reason) that cool colors like green and blue are the best colors because they promote calm when used. Calm hammerers are more productive and less violent. My work is repairing the inside of dark water tanks. It is hard to see blue and green hammers, and to find them if I put them down. I suggest that Python have the option of red hammers. So you're suggesting a fundamental change to the nature of Python. It's inherently a blue/green language. Making it available in Red violates the spirit and philosphy of the language, which is why: 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. Why did it take so long before a ternary operator was introduced? Because it was thought it could be too easily abused. The fact that there was also good use for a ternary operator within the spirit of Python was regarded as less important. The Python people respond with horror, pointing out the problems with red hammers. In other words, there are reasons that python doesn't come in red, and they will gladly tell you what they are. Regarding the differences between hammers and screwdrivers... When a screwdriver is appropriate I use a screwdriver. If I need to write code that does a large amount of CPU intensive number crunching, I use C, not Python. 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. One groups seems to think that python's spirit is not broken by allowing things that seem counter to it, as long as people can without much trouble, work within that spirit. An other group seems to think that any allowance to disgress from python's spirit is an assault on it. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Op 2005-11-24, Delaney, Timothy (Tim) schreef [EMAIL PROTECTED]: And this is the crux of it - the majority of such proposals come from people who apparently haven't actually used python that much, and are trying to impose things from other languages onto it. There's nothing wrong with bringing concepts across from other languages (look at the generators history), but you need to understand how it will fit with python before proposing it as a new feature. Why? To propose generators in Python (before they were present) would seem to me a valuable suggestion even if the proposer didn't understand how it will fit. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Antoon Pardon wrote: Op 2005-11-24, Mike Meyer schreef [EMAIL PROTECTED]: [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: Different programming styles are appropriate for different tasks, different times and different places, different people. And like morality, government, or economics, I do not believe that one style of programming fits all situations. If I read you right, what you're saying is that hammmers aren't good at driving screws. I don't think anyone would argue about that. No, the analogy is more like this. Python is hammer that comes in green or blue. The hammer's developers say (perhaps with some reason) that cool colors like green and blue are the best colors because they promote calm when used. Calm hammerers are more productive and less violent. My work is repairing the inside of dark water tanks. It is hard to see blue and green hammers, and to find them if I put them down. I suggest that Python have the option of red hammers. So you're suggesting a fundamental change to the nature of Python. It's inherently a blue/green language. Making it available in Red violates the spirit and philosphy of the language, which is why: 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. Why did it take so long before a ternary operator was introduced? Because it was thought it could be too easily abused. The fact that there was also good use for a ternary operator within the spirit of Python was regarded as less important. The Python people respond with horror, pointing out the problems with red hammers. In other words, there are reasons that python doesn't come in red, and they will gladly tell you what they are. Regarding the differences between hammers and screwdrivers... When a screwdriver is appropriate I use a screwdriver. If I need to write code that does a large amount of CPU intensive number crunching, I use C, not Python. 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. One groups seems to think that python's spirit is not broken by allowing things that seem counter to it, as long as people can without much trouble, work within that spirit. An other group seems to think that any allowance to disgress from python's spirit is an assault on it. And exactly what is python's spirit/philosophy ? It seems to me that they are often used in a liberal way, just to support one's argument that whatever is not in the CURRENT python should not be there. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Delaney, Timothy (Tim) wrote: It is without a doubt though incumbent on anyone proposing new *features* to have a solid understanding of what they are proposing, what it would affect, any backwards incompatibilities, and whether it fits into the python philosophy (import this). Sure. However, I wasn't just thinking about feature suggestions, but about times when people are asking about the best algorithm to use or why Python doesn't have something they used to rely upon in another language. And this is the crux of it - the majority of such proposals come from people who apparently haven't actually used python that much, and are trying to impose things from other languages onto it. The problem you get, is that the only people who are ever likely to need to ask questions, are those who don't fully understand Python, by definition. Often the answer they get is unintuitive to anyone not familiar with Python, but occasionally you are additionally treated as if you should have known and that thinking otherwise is a bit stupid, which is a bit unfair. In some cases, the question is quite valid, but the Python community has ossified around their own particular approach, which is not necessarily optimal but seems to be enough for all concerned. (eg. the proliferation of web frameworks that holds Python back as a platform in that area.) -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Ben Sizer wrote: The problem you get, is that the only people who are ever likely to need to ask questions, are those who don't fully understand Python, by definition. really? I'd say that most people that ask questions on comp.lang.python do understand Python pretty well, and just needs help with some esoteric detail, or some part of a library that they haven't used before. And the most common response is oh, that's cool. thanks. The I'm personally offended by the very design of the feature you just pointed me to kind of person is not very common; most people don't have that kind of ego pro- blem, and even those who do usually don't have time for that kind of crap. Fact is, most people see Python as a tool, use it where it fits, and focus on the problems they need the tool for. And yes, most Python users never gets anywhere near comp.lang.python. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
[EMAIL PROTECTED] wrote: And exactly what is python's spirit/philosophy ? It seems to me that they are often used in a liberal way, just to support one's argument that whatever is not in the CURRENT python should not be there. Yes, those contentious terms pythonic and unpythonic which, as someone recently pointed out, appear to be convenient tools to respectively label one's own work as acceptable and someone else's work as deficient. I certainly don't have much time for people who, after the most cursory inspection of Python, proclaim that it is substandard for not having static typing or for employing indentation to organise source code, but I do believe that people shouldn't be given the brush-off on more subtle topics by some Zen of Python remark (probably not even supported by the classic Tim Peters text). It should be noted that Zope eventually experienced something of a backlash by encouraging such a culture of obscure wisdom, and sometimes Python risks experiencing some of the same. More documentation, explanation and objective discussion help to bring the newcomer to understanding, rather than alienating them with some kind of opaque, elitist retort which gives them no clue as to how they may reach such understanding. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Should the priority be to enable python's philosophy or should it be the priority to limit python to only allow it's philosophy. One groups seems to think that python's spirit is not broken by allowing things that seem counter to it, as long as people can without much trouble, work within that spirit. An other group seems to think that any allowance to disgress from python's spirit is an assault on it. This seems to assume a background philosophy of TMTOWTDI versus YWKTMTOWTDIBIPFCEMS = .join([Yes we know,TMTOWTDI,But in Python fewer choices equals more simplicity) There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Maybe what makes Python most different is its philosophy; I would not argue it is the ultimate philosophy --- I could not embrace a government which held such views --- it is nothing like Democratic --- but the people in Pythonia tend to be fairly nice, and the tax rate is outstandingly low. Of course that's silly, Python is a tool, not a country. Python's philosophy, however, seems to run counter to adding a phillips head, flat head, and hex head screwdriver blade to its hammer. In life and society I hope we embrace a great multiplicity of perspectives and lifestyles. This, however, is not that. What is the philosophy? I'm not the one to answer that, but I do use import this for reference, and it seems to answer some of the points in this thread: import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! EP Criminy, I didn't realize that drat ternary operator was going to creep in. Ugh. Drat, drat, drat! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
But suppose someone came up with a Python compiler. It would compile any Python program but there would be no speed benefit unless you carefully wrote the code to not use many of Python's dynamic features, so that either by type inferencing or programmer supplied static declarations, the compiler could generate efficient native machine code that executes at near C speeds. Obviously this would require changes (mostly additions?) to the Python language, though these changes would still allow today's style dynamic code to be written and run (though just as slow as today's runs). The payout would be that things written as C-extensions today, would be writable in (a restricted form of) Python. Would the Python orthodoxy favor such a development? Or would that be turning Python into a screwdriver? i agree with you... pyrex should be part of the python distribution :) bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Antoon Pardon [EMAIL PROTECTED] writes: Op 2005-11-24, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: The usual response is That's not the Python way. That's not calling someone dumb, just pointing out that they don't yet fully understand the Python way. That is not the Python way, is just saying Python doesn't have it in other words. So it can't be the answer to why python can't have something. No, it isn't. At least, it isn't when I use it. A language is more than just an accumulation of features. Well, a good language is more than just an accumulation of features - there's a philosophy underlying the language, that guides what features are added and what features aren't. Other languages have other philosophies, and wind up being good for other things. But how this philosophy influences design is not straight forward. The ternary operator was thought of to go against the philosopy, By who? and now seems to be at least compatible with the philosophy. So when someone asks why it is not in python, saying It is not the python way still doesn't answer the question, because the person would probably still like to know what in his proposal is against the python philosophy and why. Sometimes, such things are easy to explain, and they'll generally get that explanation. Sometimes they aren't, so you're reduced to pointing out similar - but more obvious - things that aren't in the language, and import this, and suggesting that they try it for a while and see how it works My vision isn't perfect - I've changed my mind about things: I used to want real macros, and I initially disliked list comprehensions. My vision doesn't agree with the developers - notably including Guido's - a lot of the time. On the other hand, they haven't done anything that strikes me as so wrong that I want to spend the time required working on Python rather than in Python to allow me to get it fixed. I see nothing wrong with that. But I would apreciate it, should you be more open about something being your personal vision. To me something like: That is not the python way comes accross as: You just don't understand about python, if you ask/propose something like that That's essentially true. In some cases, the reasons can be explained without understanding about python. In some cases, they can't. It gives me the feeling the person is saying something like: Python is like this, I like it this way, so nobody better suggests this changes. You're carrying things a step to far, going from explaining an overly brief statement to imagining a motive for said statement. 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
Re: Python as Guido Intended
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? 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. Part of the Python philosphy, from import this, is that there should only be one obvious way to do it. By enabling that part of Python's philosphy, you're automatically limiting python to not allow other - specifically non-pythonic - ways to do the same thing. 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
Re: Python as Guido Intended
[EMAIL PROTECTED] wrote: Steve Holden wrote: I agree that sometimes those who shoot such proposals down in flames might be more considerate of the feelings of the proposers, but life is short and we are all imperfect. Well, no one is obliged to be considerate about other's feeling, that is a personal choice. But doing it the high handed way is usually counter-productive and never get the message across, which to me is a failure. I agree with you that sometimes, the responses here can come across as a bit condescending. I don't think this is intentional, as everybody seems friendly enough, but I do see a pattern of people replying to a query and implying that the original poster should know better than to ask for whatever they asked, despite the Pythonic solutions suggested often differing algorithmically from the best solution in other languages. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Op 2005-11-23, [EMAIL PROTECTED] schreef [EMAIL PROTECTED]: My own experience with adapting to Guido's design-view relates to tuples and lists. To Guido, tuples are for records and lists are for iteration. My own inclination is to view tuples as immutable lists. Accordingly, it seems obvious to me that tuples should have count() and index() methods for better substitutability. However, I've learned that adapting to Guido's world-view leads to happiness because Python's function signatures tend to reflect his design view. So, when I'm thinking the Guido way, my code comes together seamlessly. When I persist with a conflicting viewpoint, I find myself having to make conversions, write work-arounds, or create more helper functions than otherwise needed. But only Guido, thinks like Guido and then even Guido may now think differently than he thought before. And what if Guido had a bad day when he came up with something, should we just adopt to what he had in mind without questioning them. Sure, when you have a particular job to finish, you better adapt to how the language actually works. But when the argument is about how the language could be better, in whatever way you want to fill that in, just arguing that one should adapt to Guido style, is not an argument. Maybe an other approach could work better. Since I have been working with python I have seen the following changes not in a particular order: augmented arithmetic operators. generators. iterators. nested scopes. descriptors (and properties) list comprehension generator comprehension f(*sequence) calls new style classes unifictation of longs and ints sets decorators I wonder how much of these would have come about if everybody would just have adapted to the langauge as it was, instead of wondering how things could be improved. For all changes one could argue that those who wanted something from this list before it came about, that they were fighting the language. When we notice that people are fighting the language, sometimes the best approach is to change the language so that there is less reason to fight the language. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
On 24 Nov 2005 10:21:51 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: But only Guido, thinks like Guido and then even Guido may now think differently than he thought before. And what if Guido had a bad day when he came up with something, should we just adopt to what he had in mind without questioning them. No one is suggesting that Guido is perfect. But he's consistently a better judge of language design than I am, and in all likelihood better than you, too. If you like Python, it's 'cos you like the decisions he's made over many years. Where my first impulse is to think that one of decisions is wrong, nine times out of ten in time I'll come to find that I was wrong and he was right. -- Cheers, Simon B, [EMAIL PROTECTED], http://www.brunningonline.net/simon/blog/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Op 2005-11-24, Mike Meyer schreef [EMAIL PROTECTED]: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Mike Meyer wrote: I do think that the Python development community believes they do, or more accurately, that if someone wants to use a different style, they can go use something else. In other words, they believe that you should use a screwdriver to drive screws, and not a hammer. You apparently disagree with them. That is the kind of argument I see all the time on this thread. It is more appropriate to say that I don't believe it is a screw, but something else and don't want to use a screw driver with it. Whatever it is, trying to turn Python into a tool for dealing with it isn't the right thing to do. I think that it is possible to include in Python, things that are non-Pythonic (such as a return value from sort()) that allow users more stylistic freedom, without degrading the ability of those who don't want to use such features, to write in a pure Pythonic manner. So you think we can turn a hammer into a screwdriver without degrading the ability to use the hammer to drive nails. The problem is, doing this means you have a bigger, heavier hammer - which almost certainly degrades the ability to use it as a hammer. And it follows through, first said it is a screw and since you disagree, you are trying to do screwing with a hammer. You're the one that wants to use the hammer to do whatever it is, not me. I don't believe in silver bullets. Python is good at what it does. If I need a different tool, I use a different tool, rather than try and mangle a good tool into something it's not. Why do you use the word mangle here? I'll come to this again later. Such attempts are pretty much doomed. They nearly inevitably producej a tool that's not as good at what the original did as the original, and not as good at whatever new task it's being mangledd to do as a tool that was designed for that in the first place. Now, I'm not against changing the language per se. But most language changes have deeper implications than are obvious at first glance. Even when they don't, I'd prefer that you get cases that make for significantly cleaner code without having major negative connotations. The first is why people ask for use cases: they want to see a real-world example where the proposed change would make things cleaner or more readable, or otherwise better in some way. At the same time, the new feature should provide an abuse that's hard to read, or lead to code that is easily misinterpreted. I am just curious that if the should we have ternary back then creates similar arguments. By the results of the vote, most people wanted ternary. The use cases for it are well know. From what I recall, the debate was over which of the many proposals should be adopted. No it wasn't. From what I have picked up, the ternary operator was finaly introduced after one of the developers tripped over the commonly used idiom to simulate a ternary operator, which can fail in certain cases. Anyway, when I was arguing for a ternary operator in python, those who opposed me, certainly gave me the impression that they thought I wanted to mangle the language, the mere idea of a ternary operator was against the spirit of python. When I argued for a more general loop construct similar objections were made and the proposal was fiercely fought. Someone even started a PEP, with the intention to bury the idea. (That can be from before I argued for it) Now I have read about both that they will be introduced in Python 2.5 without a whisper of protest. Based on what I have read for this few period of time on this group, it is actually not people coming in complain loudly that why can't Python have this kind of post, it usually was a neutral question because either they come from another background, or they for whatever reason expect things to work certain way, or they enjoy certain style. But many times, the responses are toned in a way of you dumb, you didn't know that is the wrong way of doing it?, without explain why or with convincing reasons. The usual response is That's not the Python way. That's not calling someone dumb, just pointing out that they don't yet fully understand the Python way. That is not the Python way, is just saying Python doesn't have it in other words. So it can't be the answer to why python can't have something. The Python way is not something you're going to grok by reading postings on usenet. You can have bits and pieces explained to you, and your understanding will increase. And that's the way it is for everyone but GvR. The python way is something that changes continuously. What is the python way now certainly wasn't the python way with version 1.5 (when I started). So That is not the python way doesn't answer the question why it couldn't be the python way. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Antoon Pardon wrote: When we notice that people are fighting the language, sometimes the best approach is to change the language so that there is less reason to fight the language. I think just don't disregard the other side without considering their rationale is enough, and I mean the other side both way. Which you are right, the keyword is sometimes :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Op 2005-11-24, Simon Brunning schreef [EMAIL PROTECTED]: On 24 Nov 2005 10:21:51 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: But only Guido, thinks like Guido and then even Guido may now think differently than he thought before. And what if Guido had a bad day when he came up with something, should we just adopt to what he had in mind without questioning them. No one is suggesting that Guido is perfect. I disagree. They may not do so directly, but if each time a language change is suggested, someone answer that this is not Guido thinks about it or something similar, then Guido is certainly presented as the standard with which to compare. Putting al those responses toghether suggests Guido is perfect. But he's consistently a better judge of language design than I am, and in all likelihood better than you, too. If you like Python, it's 'cos you like the decisions he's made over many years. So, that makes that about a lot of things we think alike. Remains the question about whose ideas are better about the things we disagree. Where my first impulse is to think that one of decisions is wrong, nine times out of ten in time I'll come to find that I was wrong and he was right. When I first came to python, I almost immediatly thought a number of things would improve the language. A number of them are already implemented or seem to be scheduled for 2.5. I'm not going to argue that that makes me a better language designer than Guido, but it does seem to be an indication I'm not that bad. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
On 24 Nov 2005 11:30:04 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: But he's consistently a better judge of language design than I am, and in all likelihood better than you, too. If you like Python, it's 'cos you like the decisions he's made over many years. So, that makes that about a lot of things we think alike. Remains the question about whose ideas are better about the things we disagree. It might remain for *you* to see the answer to that question. I susp ect that most of us have answered it to our own satisfaction long since. -- Cheers, Simon B, [EMAIL PROTECTED], http://www.brunningonline.net/simon/blog/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Op 2005-11-24, Simon Brunning schreef [EMAIL PROTECTED]: On 24 Nov 2005 11:30:04 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: But he's consistently a better judge of language design than I am, and in all likelihood better than you, too. If you like Python, it's 'cos you like the decisions he's made over many years. So, that makes that about a lot of things we think alike. Remains the question about whose ideas are better about the things we disagree. It might remain for *you* to see the answer to that question. I susp ect that most of us have answered it to our own satisfaction long since. Shrug There was a time that Guido and I disagreed about the ternary operator. I'm sure people then also answered the question who of us was wrong to their satisfaction. In the mean time Guido seems to have changed his mind. The way it looks to me right now, is that python is evolving the way I like it to evolve, even if newsgroup members in general oppose those ideas when I defend them in the newsgroup. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
On Thu, 24 Nov 2005 10:49:59 +, Simon Brunning [EMAIL PROTECTED] wrote: On 24 Nov 2005 10:21:51 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: But only Guido, thinks like Guido and then even Guido may now think differently than he thought before. And what if Guido had a bad day when he came up with something, should we just adopt to what he had in mind without questioning them. No one is suggesting that Guido is perfect. But he's consistently a better judge of language design than I am, and in all likelihood better than you, too. If you like Python, it's 'cos you like the decisions he's made over many years. Where my first impulse is to think that one of decisions is wrong, nine times out of ten in time I'll come to find that I was wrong and he was right. You have a reservation about that other 10% ? ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
On 24/11/05, Bengt Richter [EMAIL PROTECTED] wrote: Where my first impulse is to think that one of decisions is wrong, nine times out of ten in time I'll come to find that I was wrong and he was right. You have a reservation about that other 10% ? ;-) The other 10%, I've just not worked it out yet. -- Cheers, Simon B, [EMAIL PROTECTED], http://www.brunningonline.net/simon/blog/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Antoon Pardon [EMAIL PROTECTED] writes: The usual response is That's not the Python way. That's not calling someone dumb, just pointing out that they don't yet fully understand the Python way. That is not the Python way, is just saying Python doesn't have it in other words. So it can't be the answer to why python can't have something. No, it isn't. At least, it isn't when I use it. A language is more than just an accumulation of features. Well, a good language is more than just an accumulation of features - there's a philosophy underlying the language, that guides what features are added and what features aren't. Other languages have other philosophies, and wind up being good for other things. When I say That's not the Python way, I mean that such a feature runs counter to my vision of Python's underlying philosophy. My vision isn't perfect - I've changed my mind about things: I used to want real macros, and I initially disliked list comprehensions. My vision doesn't agree with the developers - notably including Guido's - a lot of the time. On the other hand, they haven't done anything that strikes me as so wrong that I want to spend the time required working on Python rather than in Python to allow me to get it fixed. 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
Re: Python as Guido Intended
Mike Meyer [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: Different programming styles are appropriate for different tasks, different times and different places, different people. And like morality, government, or economics, I do not believe that one style of programming fits all situations. If I read you right, what you're saying is that hammmers aren't good at driving screws. I don't think anyone would argue about that. No, the analogy is more like this. Python is hammer that comes in green or blue. The hammer's developers say (perhaps with some reason) that cool colors like green and blue are the best colors because they promote calm when used. Calm hammerers are more productive and less violent. My work is repairing the inside of dark water tanks. It is hard to see blue and green hammers, and to find them if I put them down. I suggest that Python have the option of red hammers. The Python people respond with horror, pointing out the problems with red hammers. I say that I am a calm person already, that I know how to use red hammers safely, but of course the Python people don't want anything to do with the idea. What will happen if your red hammer falls into the hands of a beginner? they ask. (I note that although the hammer does have a lot of safety features, it is still easy to poke an eye out with the nail remover if one is not careful.) They also point out that adding a third color will cost time and effort. And the problems of deciding if the hammer should really be red, or maybe orange would be better. So they tell me to go use a red screwdriver. Regarding the differences between hammers and screwdrivers... When a screwdriver is appropriate I use a screwdriver. If I need to write code that does a large amount of CPU intensive number crunching, I use C, not Python. But suppose someone came up with a Python compiler. It would compile any Python program but there would be no speed benefit unless you carefully wrote the code to not use many of Python's dynamic features, so that either by type inferencing or programmer supplied static declarations, the compiler could generate efficient native machine code that executes at near C speeds. Obviously this would require changes (mostly additions?) to the Python language, though these changes would still allow today's style dynamic code to be written and run (though just as slow as today's runs). The payout would be that things written as C-extensions today, would be writable in (a restricted form of) Python. Would the Python orthodoxy favor such a development? Or would that be turning Python into a screwdriver? To me, it would be better because I can now do with a hammer, many of the things I used to do with a screw- driver. I can spend more time becoming a better hammerer, and less time learning the intricacies of screwdrivers. My life is better. This has the benefit of attracting more people to Python. And why is this a benefit? More eyeballs to find bugs. More hands to make improvements. More minds to make suggestions. More hearts to share the joy. :-) -- http://mail.python.org/mailman/listinfo/python-list
RE: Python as Guido Intended
Ben Sizer wrote: I agree with you that sometimes, the responses here can come across as a bit condescending. I don't think this is intentional, as everybody seems friendly enough, but I do see a pattern of people replying to a query and implying that the original poster should know better than to ask for whatever they asked, despite the Pythonic solutions suggested often differing algorithmically from the best solution in other languages. http://www.catb.org/~esr/faqs/smart-questions.html This is a technical newsgroup, and pretty much everything there applies. Fortunately for people who don't know better, comp.lang.python (aka python-list) is much friendlier and less condescending than most other technical forums (I've been involved in quite a few, and c.l.py is easily the best). It is without a doubt though incumbent on anyone proposing new *features* to have a solid understanding of what they are proposing, what it would affect, any backwards incompatibilities, and whether it fits into the python philosophy (import this). Failure to have considered all of these is likely to be shot down in flames. New syntax is especially likely to have unintended consequences that many of us will think should have been obvious if you've used python much. And this is the crux of it - the majority of such proposals come from people who apparently haven't actually used python that much, and are trying to impose things from other languages onto it. There's nothing wrong with bringing concepts across from other languages (look at the generators history), but you need to understand how it will fit with python before proposing it as a new feature. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
[EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: Different programming styles are appropriate for different tasks, different times and different places, different people. And like morality, government, or economics, I do not believe that one style of programming fits all situations. If I read you right, what you're saying is that hammmers aren't good at driving screws. I don't think anyone would argue about that. No, the analogy is more like this. Python is hammer that comes in green or blue. The hammer's developers say (perhaps with some reason) that cool colors like green and blue are the best colors because they promote calm when used. Calm hammerers are more productive and less violent. My work is repairing the inside of dark water tanks. It is hard to see blue and green hammers, and to find them if I put them down. I suggest that Python have the option of red hammers. So you're suggesting a fundamental change to the nature of Python. It's inherently a blue/green language. Making it available in Red violates the spirit and philosphy of the language, which is why: The Python people respond with horror, pointing out the problems with red hammers. In other words, there are reasons that python doesn't come in red, and they will gladly tell you what they are. Regarding the differences between hammers and screwdrivers... When a screwdriver is appropriate I use a screwdriver. If I need to write code that does a large amount of CPU intensive number crunching, I use C, not Python. 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. This has the benefit of attracting more people to Python. And why is this a benefit? More eyeballs to find bugs. More hands to make improvements. More minds to make suggestions. More hearts to share the joy. :-) More people to try and turn the hammer into a screwdriver, more people to insist that the bike shed be red, etc. If popularity were inherently a good thing, I'd be writing VB on Windows. 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
Python as Guido Intended
[EMAIL PROTECTED] wrote: it seems that quite some people don't see the language as the creator or wants them to see it. Here's my two cents on this recurring theme. While nothing forces a particular programming style, there is some merit to swimming with the current rather than against it. Observing five years of newsgroup posts, I've observed that many who struggle with language or get angry about some part of it are fighting the language rather than using it as intended/designed. IMO, following designer intent leads to happiness because Guido's philosophies so thoroughly pervade the language. So, when you accept his viewpoints, you'll find that all the parts of the language tend to fit together neatly and easily. Conversely, fighting the language tends to result in one struggle after the next. For example, there is a person currently working on a new proposal for a container freezing protocol. In order to overcome all the fundamental difficulties (like what to do with mutable values when freezing a dictionary), the proponent is finding that he has to suggest pervasive changes to the language (including mutable strings, recursive freezing protocols, mutation notifications, etc). I suspect that he is fighting the language. It is not so much that his idea is wrong, it is just that he is effectively creating another language that is not Python. My own experience with adapting to Guido's design-view relates to tuples and lists. To Guido, tuples are for records and lists are for iteration. My own inclination is to view tuples as immutable lists. Accordingly, it seems obvious to me that tuples should have count() and index() methods for better substitutability. However, I've learned that adapting to Guido's world-view leads to happiness because Python's function signatures tend to reflect his design view. So, when I'm thinking the Guido way, my code comes together seamlessly. When I persist with a conflicting viewpoint, I find myself having to make conversions, write work-arounds, or create more helper functions than otherwise needed. Keep this in mind when finding yourself madder than heck about mylist.sort() returning None or zip(it,it) intentionally not documenting its implementation quirks. IMO, using the tools as given leads to easily-written, clean, maintainable, beautiful code. Learn to love what makes Python great. Pounding a square object into a round hole should be a cue that you're doing things the hard way ;-) respectfully submitted, Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: it seems that quite some people don't see the language as the creator or wants them to see it. Here's my two cents on this recurring theme. While nothing forces a particular programming style, there is some merit to swimming with the current rather than against it. Observing five years of newsgroup posts, I've observed that many who struggle with language or get angry about some part of it are fighting the language rather than using it as intended/designed. IMO, following designer intent leads to happiness because Guido's philosophies so thoroughly pervade the language. So, when you accept his viewpoints, you'll find that all the parts of the language tend to fit together neatly and easily. Conversely, fighting the language tends to result in one struggle after the next. For example, there is a person currently working on a new proposal for a container freezing protocol. In order to overcome all the fundamental difficulties (like what to do with mutable values when freezing a dictionary), the proponent is finding that he has to suggest pervasive changes to the language (including mutable strings, recursive freezing protocols, mutation notifications, etc). I suspect that he is fighting the language. It is not so much that his idea is wrong, it is just that he is effectively creating another language that is not Python. My own experience with adapting to Guido's design-view relates to tuples and lists. To Guido, tuples are for records and lists are for iteration. My own inclination is to view tuples as immutable lists. Accordingly, it seems obvious to me that tuples should have count() and index() methods for better substitutability. However, I've learned that adapting to Guido's world-view leads to happiness because Python's function signatures tend to reflect his design view. So, when I'm thinking the Guido way, my code comes together seamlessly. When I persist with a conflicting viewpoint, I find myself having to make conversions, write work-arounds, or create more helper functions than otherwise needed. Keep this in mind when finding yourself madder than heck about mylist.sort() returning None or zip(it,it) intentionally not documenting its implementation quirks. IMO, using the tools as given leads to easily-written, clean, maintainable, beautiful code. Learn to love what makes Python great. Pounding a square object into a round hole should be a cue that you're doing things the hard way ;-) I don't disagree with your points and in reality mostly follow them. I have found out that it is easier to work with Python than against it. And the overall results are on the plus side of the scale (because I still use it.) You are describing the way Python is, and saying a small change in my attitude will make using Python easier. I am saying that a small change in the view of Python's developer's will make Python a better and more versatile language. I want two things from a language - 1. Effectiveness - I want to be able to solve my programming tasks quickly. This means good language design, rich and powerful datatypes and language features, wide coverage library, good documentation, etc. 2. Generality - to be able to use it in a wide range of environments and satisfy a wide range of needs: interactive calculator, one-off quickie programs, small task programs, large systems, gui and command line programs, OS code,... this is a very long list. Python is pretty good at number 1. It is good, but less good at #2. (The biggest limitation in #2 is it's slow runtime performance but that is a different subject.) Different programming styles are appropriate for different tasks, different times and different places, different people. And like morality, government, or economics, I do not believe that one style of programming fits all situations. But I do not think (and reading c.l.p convinces me) that GvR and Python's developers know a coding style that works best in all situations. I do think that the Python development community believes they do, or more accurately, that if someone wants to use a different style, they can go use something else.The sense I have with Python is a little like I have seen in certain religious or very ideological political groups -- our way is the one true way. I just can't buy that. My reaction also results from my belief that supersetting is good. A language that allows for writing Pythonic code and additionally allows for writing in other styles, is better that one the enforces a Pythonic only style because it serves the needs of a wider audience. (Obviously it is possible to write non-Pythonic code in Python but I see the Python development community as trying their best to suppress this ability.) I think that it is possible to include in Python, things that are non-Pythonic (such as a return value from
Re: Python as Guido Intended
[EMAIL PROTECTED] writes: Different programming styles are appropriate for different tasks, different times and different places, different people. And like morality, government, or economics, I do not believe that one style of programming fits all situations. If I read you right, what you're saying is that hammmers aren't good at driving screws. I don't think anyone would argue about that. But I do not think (and reading c.l.p convinces me) that GvR and Python's developers know a coding style that works best in all situations. I don't think that GvR believes he knows such a coding style, either. I certainly don't believe it. I do think that the Python development community believes they do, or more accurately, that if someone wants to use a different style, they can go use something else. In other words, they believe that you should use a screwdriver to drive screws, and not a hammer. You apparently disagree with them. I think that it is possible to include in Python, things that are non-Pythonic (such as a return value from sort()) that allow users more stylistic freedom, without degrading the ability of those who don't want to use such features, to write in a pure Pythonic manner. So you think we can turn a hammer into a screwdriver without degrading the ability to use the hammer to drive nails. The problem is, doing this means you have a bigger, heavier hammer - which almost certainly degrades the ability to use it as a hammer. Adding features makes the language processor bigger. With Pythons strong commitment to backwards compatibility, these are hard to get rid of. Further, while those of us who like the Pythonic style may not have to use them, that won't prevent us from having to maintain code that uses them. Now, I'm not against changing the language per se. But most language changes have deeper implications than are obvious at first glance. Even when they don't, I'd prefer that you get cases that make for significantly cleaner code without having major negative connotations. The first is why people ask for use cases: they want to see a real-world example where the proposed change would make things cleaner or more readable, or otherwise better in some way. At the same time, the new feature should provide an abuse that's hard to read, or lead to code that is easily misinterpreted. This has the benefit of attracting more people to Python. And why is this a benefit? 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
Re: Python as Guido Intended
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Different programming styles are appropriate for different tasks, different times and different places, different people. And like morality, government, or economics, I do not believe that one style of programming fits all situations. But I do not think (and reading c.l.p convinces me) that GvR and Python's developers know a coding style that works best in all situations. I do think that the Python development community believes they do, or more accurately, that if someone wants to use a different style, they can go use something else.The sense I have with Python is a little like I have seen in certain religious or very ideological political groups -- our way is the one true way. I just can't buy that. Your third-to-last sentence is correct, but your second-to-last sentence is not. The reason Python people say to use something else is precisely because we don't believe that one-size-fits-all. Some people use other languages in addition to Python, and some people don't use Python at all. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you think it's expensive to hire a professional to do the job, wait until you hire an amateur. --Red Adair -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Mike Meyer wrote: I do think that the Python development community believes they do, or more accurately, that if someone wants to use a different style, they can go use something else. In other words, they believe that you should use a screwdriver to drive screws, and not a hammer. You apparently disagree with them. That is the kind of argument I see all the time on this thread. It is more appropriate to say that I don't believe it is a screw, but something else and don't want to use a screw driver with it. I think that it is possible to include in Python, things that are non-Pythonic (such as a return value from sort()) that allow users more stylistic freedom, without degrading the ability of those who don't want to use such features, to write in a pure Pythonic manner. So you think we can turn a hammer into a screwdriver without degrading the ability to use the hammer to drive nails. The problem is, doing this means you have a bigger, heavier hammer - which almost certainly degrades the ability to use it as a hammer. And it follows through, first said it is a screw and since you disagree, you are trying to do screwing with a hammer. Adding features makes the language processor bigger. With Pythons strong commitment to backwards compatibility, these are hard to get rid of. Further, while those of us who like the Pythonic style may not have to use them, that won't prevent us from having to maintain code that uses them. Now, I'm not against changing the language per se. But most language changes have deeper implications than are obvious at first glance. Even when they don't, I'd prefer that you get cases that make for significantly cleaner code without having major negative connotations. The first is why people ask for use cases: they want to see a real-world example where the proposed change would make things cleaner or more readable, or otherwise better in some way. At the same time, the new feature should provide an abuse that's hard to read, or lead to code that is easily misinterpreted. I am just curious that if the should we have ternary back then creates similar arguments. Based on what I have read for this few period of time on this group, it is actually not people coming in complain loudly that why can't Python have this kind of post, it usually was a neutral question because either they come from another background, or they for whatever reason expect things to work certain way, or they enjoy certain style. But many times, the responses are toned in a way of you dumb, you didn't know that is the wrong way of doing it?, without explain why or with convincing reasons. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: Mike Meyer wrote: I do think that the Python development community believes they do, or more accurately, that if someone wants to use a different style, they can go use something else. In other words, they believe that you should use a screwdriver to drive screws, and not a hammer. You apparently disagree with them. That is the kind of argument I see all the time on this thread. It is more appropriate to say that I don't believe it is a screw, but something else and don't want to use a screw driver with it. Whatever it is, trying to turn Python into a tool for dealing with it isn't the right thing to do. I think that it is possible to include in Python, things that are non-Pythonic (such as a return value from sort()) that allow users more stylistic freedom, without degrading the ability of those who don't want to use such features, to write in a pure Pythonic manner. So you think we can turn a hammer into a screwdriver without degrading the ability to use the hammer to drive nails. The problem is, doing this means you have a bigger, heavier hammer - which almost certainly degrades the ability to use it as a hammer. And it follows through, first said it is a screw and since you disagree, you are trying to do screwing with a hammer. You're the one that wants to use the hammer to do whatever it is, not me. I don't believe in silver bullets. Python is good at what it does. If I need a different tool, I use a different tool, rather than try and mangle a good tool into something it's not. Such attempts are pretty much doomed. They nearly inevitably producej a tool that's not as good at what the original did as the original, and not as good at whatever new task it's being mangledd to do as a tool that was designed for that in the first place. Now, I'm not against changing the language per se. But most language changes have deeper implications than are obvious at first glance. Even when they don't, I'd prefer that you get cases that make for significantly cleaner code without having major negative connotations. The first is why people ask for use cases: they want to see a real-world example where the proposed change would make things cleaner or more readable, or otherwise better in some way. At the same time, the new feature should provide an abuse that's hard to read, or lead to code that is easily misinterpreted. I am just curious that if the should we have ternary back then creates similar arguments. By the results of the vote, most people wanted ternary. The use cases for it are well know. From what I recall, the debate was over which of the many proposals should be adopted. Based on what I have read for this few period of time on this group, it is actually not people coming in complain loudly that why can't Python have this kind of post, it usually was a neutral question because either they come from another background, or they for whatever reason expect things to work certain way, or they enjoy certain style. But many times, the responses are toned in a way of you dumb, you didn't know that is the wrong way of doing it?, without explain why or with convincing reasons. The usual response is That's not the Python way. That's not calling someone dumb, just pointing out that they don't yet fully understand the Python way. The Python way is not something you're going to grok by reading postings on usenet. You can have bits and pieces explained to you, and your understanding will increase. And that's the way it is for everyone but GvR. 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
Re: Python as Guido Intended
Mike Meyer wrote: Whatever it is, trying to turn Python into a tool for dealing with it isn't the right thing to do. Still this tone, and logic. This statement alone is right except that it may not be what was about. I think that it is possible to include in Python, things that are non-Pythonic (such as a return value from sort()) that allow users more stylistic freedom, without degrading the ability of those who don't want to use such features, to write in a pure Pythonic manner. So you think we can turn a hammer into a screwdriver without degrading the ability to use the hammer to drive nails. The problem is, doing this means you have a bigger, heavier hammer - which almost certainly degrades the ability to use it as a hammer. And it follows through, first said it is a screw and since you disagree, you are trying to do screwing with a hammer. You're the one that wants to use the hammer to do whatever it is, not me. I don't believe in silver bullets. Python is good at what it does. If I need a different tool, I use a different tool, rather than try and mangle a good tool into something it's not. Such attempts are pretty much doomed. They nearly inevitably producej a tool that's not as good at what the original did as the original, and not as good at whatever new task it's being mangledd to do as a tool that was designed for that in the first place. And again. By the results of the vote, most people wanted ternary. The use cases for it are well know. From what I recall, the debate was over which of the many proposals should be adopted. That is not the impression I get on here. The impression I get lately is ternary is bad, is hard to read, can always be done better with if then else statement. The usual response is That's not the Python way. That's not calling someone dumb, just pointing out that they don't yet fully understand the Python way. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: You're the one that wants to use the hammer to do whatever it is, not me. I don't believe in silver bullets. Python is good at what it does. If I need a different tool, I use a different tool, rather than try and mangle a good tool into something it's not. Such attempts are pretty much doomed. They nearly inevitably produce a tool that's not as good at what the original did as the original, and not as good at whatever new task it's being mangled to do as a tool that was designed for that in the first place. And again. This isn't a Python thing, it's a believe about tools in general - that you should choose the right tool for the job. It isn't applied very often to hardware tools because they aren't as mallable as software tools, and have in general been around and improving for a long time. But it applies to programming languages, data formats, and similar more mallable things. Changes that make them better at what they do are welcome; changes that make the into what they aren't are viewed with great suspicion. Maybe Python attracts people who share that belief. After all, TRTFTJ is implies TSBOOWTDI, and vice versa. 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
Re: Python as Guido Intended
Mike Meyer wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: You're the one that wants to use the hammer to do whatever it is, not me. I don't believe in silver bullets. Python is good at what it does. If I need a different tool, I use a different tool, rather than try and mangle a good tool into something it's not. Such attempts are pretty much doomed. They nearly inevitably produce a tool that's not as good at what the original did as the original, and not as good at whatever new task it's being mangled to do as a tool that was designed for that in the first place. And again. This isn't a Python thing, it's a believe about tools in general - that you should choose the right tool for the job. It isn't applied very often to hardware tools because they aren't as mallable as software tools, and have in general been around and improving for a long time. But it applies to programming languages, data formats, and similar more mallable things. Changes that make them better at what they do are welcome; changes that make the into what they aren't are viewed with great suspicion. Maybe Python attracts people who share that belief. After all, TRTFTJ is implies TSBOOWTDI, and vice versa. I was not talking about the believe, I was talking about the way you presented it. You are setting up an imaginary me, which is not me. And that is the kind of arguments I saw, I believe this many times are done unconciously. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: Maybe Python attracts people who share that belief. After all, TRTFTJ is implies TSBOOWTDI, and vice versa. I was not talking about the believe, I was talking about the way you presented it. You are setting up an imaginary me, which is not me. And that is the kind of arguments I saw, I believe this many times are done unconciously. You're doing that yourself. But we don't have a real other person to work with - the best we can do is work with our model of that other person. That's life. 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
Re: Python as Guido Intended
Mike Meyer wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Maybe Python attracts people who share that belief. After all, TRTFTJ is implies TSBOOWTDI, and vice versa. I was not talking about the believe, I was talking about the way you presented it. You are setting up an imaginary me, which is not me. And that is the kind of arguments I saw, I believe this many times are done unconciously. You're doing that yourself. But we don't have a real other person to work with - the best we can do is work with our model of that other person. That's life. In what way am I doing it myself ? It could be unconciously too but I always welcome if it could be pointed out. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
[EMAIL PROTECTED] wrote: Mike Meyer wrote: [...] By the results of the vote, most people wanted ternary. The use cases for it are well know. From what I recall, the debate was over which of the many proposals should be adopted. That is not the impression I get on here. The impression I get lately is ternary is bad, is hard to read, can always be done better with if then else statement. Well I personally believe the main reason Guido resisted the introduction of the ternary operator for so long is precisely because he knows it will be abused (by which I mean used when its use will make a program's meaning less clear) to the detriment of program readability. Python's unusual virtue is its ability to make a programmer's intent clear from a reading of the code, and Guido tends to be fiercely protective of that characteristic. You should also bear in mind that many (though admittedly not all) suggestions for change are ill-thought-out at best and lamebrained at worst. One recent example (though I won't accord it a specific position on the scale) was the suggestion that user-defined operators could be introduced using a ]+[ syntax. The fact that this made y = [1,2,3]+[4,5,6] syntactically ambiguous had not been considered by the proposer. I agree that sometimes those who shoot such proposals down in flames might be more considerate of the feelings of the proposers, but life is short and we are all imperfect. The fact that naive expressions of opinion about such matters are traditionally accorded respect and answered politely is one of the reasons why so many people find this list a helpful place to discuss Python. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
[EMAIL PROTECTED] wrote: Mike Meyer wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Maybe Python attracts people who share that belief. After all, TRTFTJ is implies TSBOOWTDI, and vice versa. I was not talking about the believe, I was talking about the way you presented it. You are setting up an imaginary me, which is not me. And that is the kind of arguments I saw, I believe this many times are done unconciously. You're doing that yourself. But we don't have a real other person to work with - the best we can do is work with our model of that other person. That's life. In what way am I doing it myself ? It could be unconciously too but I always welcome if it could be pointed out. I think Mike (the Mike I imagine, anyway) merely intended to point out that since we can't live in each others' heads all communication is with an imaginary person, whose actual thoughts and feelings are unavailable to us. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Steve Holden wrote: [EMAIL PROTECTED] wrote: Mike Meyer wrote: [...] By the results of the vote, most people wanted ternary. The use cases for it are well know. From what I recall, the debate was over which of the many proposals should be adopted. That is not the impression I get on here. The impression I get lately is ternary is bad, is hard to read, can always be done better with if then else statement. Well I personally believe the main reason Guido resisted the introduction of the ternary operator for so long is precisely because he knows it will be abused (by which I mean used when its use will make a program's meaning less clear) to the detriment of program readability. Python's unusual virtue is its ability to make a programmer's intent clear from a reading of the code, and Guido tends to be fiercely protective of that characteristic. If it is expressed as this, there won't be long winding recurring threads about the same topic which usually go off-topic. I agree that sometimes those who shoot such proposals down in flames might be more considerate of the feelings of the proposers, but life is short and we are all imperfect. Well, no one is obliged to be considerate about other's feeling, that is a personal choice. But doing it the high handed way is usually counter-productive and never get the message across, which to me is a failure. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
Steve Holden wrote: [EMAIL PROTECTED] wrote: Mike Meyer wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Maybe Python attracts people who share that belief. After all, TRTFTJ is implies TSBOOWTDI, and vice versa. I was not talking about the believe, I was talking about the way you presented it. You are setting up an imaginary me, which is not me. And that is the kind of arguments I saw, I believe this many times are done unconciously. You're doing that yourself. But we don't have a real other person to work with - the best we can do is work with our model of that other person. That's life. In what way am I doing it myself ? It could be unconciously too but I always welcome if it could be pointed out. I think Mike (the Mike I imagine, anyway) merely intended to point out that since we can't live in each others' heads all communication is with an imaginary person, whose actual thoughts and feelings are unavailable to us. If that is the case, it is quite different from saying you are the one who wants to use a hammer on a screw, but without further clarification, I would leave it. -- http://mail.python.org/mailman/listinfo/python-list
