Re: Does Python really follow its philosophy of Readability counts?
Russ P. a écrit : On Jan 26, 1:07 am, Bruno Desthuilliers bruno. 42.desthuilli...@websiteburo.invalid wrote: No. I can change the *team's* code. Please *read*. team's ownership, ok ? Or do I have to spell it out loud ? TEAM'S OWNERSHIP. Uh. You get the message, now ? Team ownership doesn't necessarily mean that you can just change code at will. Nope, but it surely means that I'm *not* changing someone else's code. In industry, teams usually have a leader that you need to check with before you can change an interface. This is totally unrelated. Would you give all those developers your password to get into the system? No? Wait a minute ... you mean you wouldn't trust them with your password? But what about openness? Are you some sort of fascist or what? Goodwin point. You loose. Good bye again, Mr P. You missed the point once again. In asking if you are a fascist, I was *parodying* your attitude that languages with enforced access restrictions are for fascists who don't trust their co-workers or employees. [I don't recall if you actually used that word I did not, and you should know better. or if it was someone else, but you did use BD, which carries the same general impression.] Can't you tell the difference, really ? So I parodied your hyperbole, Still not. But it's interesting to note that you consider everyone disagreeing with you as basically the same person. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Tuesday 27 January 2009 04:39:02 am Bruno Desthuilliers wrote: Still not. But it's interesting to note that you consider everyone disagreeing with you as basically the same person. Hehe. At the beginning of this thread, I also thought that Russ P. and Paul Robin were the same person. I have serious problems with names. [My apologies to both of you, if I said something that made you notice my confusion]. P.S: Just to be clear, I'm neither Russ P. nor Paul Robin :D -- Luis Zarrabeitia (aka Kyrie) Fac. de Matemática y Computación, UH. http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Luis Zarrabeitia k@uh.cu wrote: 8 Hehe. At the beginning of this thread, I also thought that Russ P. and Paul Robin were the same person. I have serious problems with names. *nods in agreement, because the man's surname is Rubin, not Robin* :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 21, 2:11 am, Mark Wooding m...@distorted.org.uk wrote: CLOS is much more complex and dynamic than Python's object system; but it can be compiled very aggressively. I agree that CLOS is complex and that it can be compiled very aggressively, but I do not think that it is more dynamic than Python. What feature are you alluding to? Multimethods? There are many Python implementations of them, they are just not in the standard library. Or are you referring to interactive facilities, such as the one discussed in this recipe http://code.activestate.com/recipes/160164 ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 26, 6:09 am, Steve Holden st...@holdenweb.com wrote: Quite. Python is a language for consenting adults. It has perceived deficiencies for certain software engineering environments. Can we drop the subject now? This horse was flogged to death long ago, and it's pointless and cruel to keep on beating the remains. Judging from this thread, not everyone got the memo yet. At least three or four people on this thread alone have argued that enforced data hiding is of no value whatsoever for any application or domain. And more than one of them has argued that Python is perfectly appropriate for even the largest and most safety-critical projects. We are moving into an era of increasing dependence on computers and software for safety-critical, mission-critical, and financial systems. If people who do not understand the principles necessary for ultra-reliable software get in charge of developing these systems, we will have serious problems that could have been avoided. I suggested that maybe -- maybe! -- the versatility of Python could be enhanced with enforced data hiding. I was careful to say several times that I don't know if that can even be done in Python (with all its introspection and so forth). And it would always be optional, of course (as far as I know, no language forces anyone to declare anything private). Several people here seem to take that suggestion as an assault on Python and, by projection, an assault on their worldview. We all know that Python is a fantastic language for many purposes, but it is only a language, and failing to recognize and address its limitations serves no useful purpose. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Tuesday 27 January 2009 02:13:50 pm Russ P. wrote: I suggested that maybe -- maybe! -- the versatility of Python could be enhanced with enforced data hiding. I was careful to say several times that I don't know if that can even be done in Python (with all its introspection and so forth). And it would always be optional, of course (as far as I know, no language forces anyone to declare anything private). I think you still fail to see that what we are objecting is not that the original writer can optionally use the enforced data hiding (which, as someone pointed out before me, can be done with tools like pylint). The objection is about the _user_ of the library. If you don't force it into the _user_, how is it different from the current situation? And if you do force it, how can you say that it is optional? -- Luis Zarrabeitia (aka Kyrie) Fac. de Matemática y Computación, UH. http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 27, 11:40 am, Luis Zarrabeitia ky...@uh.cu wrote: I think you still fail to see that what we are objecting is not that the original writer can optionally use the enforced data hiding (which, as someone pointed out before me, can be done with tools like pylint). The objection is about the _user_ of the library. If you don't force it into the _user_, how is it different from the current situation? And if you do force it, how can you say that it is optional? As I have pointed out several times, the user cannot be forced to respect data hiding if he has access to the source code (and the right to modify it). If Python had a private keyword (or equivalent), for example, the user would only need to delete it wherever necessary to gain the desired access. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
[No, my email address doesn't begin `m...@'. Fixed.] Michele Simionato michele.simion...@gmail.com writes: On Jan 21, 2:11 am, Mark Wooding m...@distorted.org.uk wrote: CLOS is much more complex and dynamic than Python's object system; but it can be compiled very aggressively. I agree that CLOS is complex and that it can be compiled very aggressively, but I do not think that it is more dynamic than Python. What feature are you alluding to? Multimethods? There are many Python implementations of them, they are just not in the standard library. Or are you referring to interactive facilities, such as the one discussed in this recipe http://code.activestate.com/recipes/160164 ? I'm referring to a number of features: * Redefinition of classes, yes. Interactive development is very frustrating without this. Thanks for that link, by the way! * CHANGE-CLASS to change the class of instances. This is more than just assigning to mumble.__class__, since it correctly initializes the slots present in the new class which were absent in the old. * And all of the fancy MOP tricks you can play: inventing new slot classes; messing with class-precedence-list orderings (Python's MRO). It's a shorter list than I'd hoped! Still, these features kind of multiply up. You can redefine a class using a new metaclass and slot options, and all the instances are updated, for example. Anyway, I think I exaggerated when I said that CLOS was `much more dynamic', but it is /somewhat/ more dynamic, and still amenable to optimization; since my point was that dynamism in a language isn't necessarily antithetical to compilation, that's still sufficient. Thanks for keeping me honest! -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 27, 12:13 pm, Russ P. russ.paie...@gmail.com wrote: On Jan 26, 6:09 am, Steve Holden st...@holdenweb.com wrote: Quite. Python is a language for consenting adults. It has perceived deficiencies for certain software engineering environments. Can we drop the subject now? This horse was flogged to death long ago, and it's pointless and cruel to keep on beating the remains. Judging from this thread, not everyone got the memo yet. At least three or four people on this thread alone have argued that enforced data hiding is of no value whatsoever for any application or domain. And more than one of them has argued that Python is perfectly appropriate for even the largest and most safety-critical projects. We are moving into an era of increasing dependence on computers and software for safety-critical, mission-critical, and financial systems. If people who do not understand the principles necessary for ultra-reliable software get in charge of developing these systems, we will have serious problems that could have been avoided. I suggested that maybe -- maybe! -- the versatility of Python could be enhanced with enforced data hiding. I was careful to say several times that I don't know if that can even be done in Python (with all its introspection and so forth). And it would always be optional, of course (as far as I know, no language forces anyone to declare anything private). Several people here seem to take that suggestion as an assault on Python and, by projection, an assault on their worldview. We all know that Python is a fantastic language for many purposes, but it is only a language, and failing to recognize and address its limitations serves no useful purpose. What you need is a middle ground. Something that can be *easily* circumvented for debugging, unit tests, and friend functions/modules/ class. Without suggesting a middle ground people are left assuming C++-style privates/protected, which would be a significant burden on everybody. The only way it wouldn't is if nobody actually uses it, except in specialized high-assurance software, but at that point you might as well fork python (or use metaclass trickery). -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Paul Rubin wrote: Scott David Daniels scott.dani...@acm.org writes: But, the research on the language Self shows that even in the face of a language with more dynamism than Smalltalk (or Python), performance can be obtained using compiler technology I'd be interested in seeing any publications about that Self research, which I remember someone else mentioning in another thread as well. Sorry this was sitting in drafts. Search for David Ungar and/or Randall Smith and Self. --Scott David Daniels scott.dani...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Russ P. russ.paie...@gmail.com writes: If Python had a private keyword (or equivalent), for example, the user would only need to delete it wherever necessary to gain the desired access. And you obviously weren't listening when we said that having to make source code changes to upstream modules was a serious maintenance and distribution headache: 87ab9f8dp1.fsf@metalzone.distorted.org.uk -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Tuesday 27 January 2009 02:56:51 pm Russ P. wrote: On Jan 27, 11:40 am, Luis Zarrabeitia ky...@uh.cu wrote: I think you still fail to see that what we are objecting is not that the original writer can optionally use the enforced data hiding (which, as someone pointed out before me, can be done with tools like pylint). The objection is about the _user_ of the library. If you don't force it into the _user_, how is it different from the current situation? And if you do force it, how can you say that it is optional? As I have pointed out several times, the user cannot be forced to respect data hiding if he has access to the source code (and the right to modify it). If Python had a private keyword (or equivalent), for example, the user would only need to delete it wherever necessary to gain the desired access. And, as others and I have pointed out several times, that would mean to maintain a fork. Would you say that current C++ has optional enforced data hiding for the user? After all, you can just fork the module (and if you don't have the source, you could mess with pointers until you find it). Also, I once pointed out that access to the source code and right to modify it is not a given. What you are proposing is not optional at all. You want the power to control what others do - and while it may be your legal right, it's also everyone else's right not go our of our ways to help you have it. -- Luis Zarrabeitia (aka Kyrie) Fac. de Matemática y Computación, UH. http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 27, 9:13 pm, Mark Wooding m...@distorted.org.uk wrote: I'm referring to a number of features: * Redefinition of classes, yes. Interactive development is very frustrating without this. Thanks for that link, by the way! * CHANGE-CLASS to change the class of instances. This is more than just assigning to mumble.__class__, since it correctly initializes the slots present in the new class which were absent in the old. * And all of the fancy MOP tricks you can play: inventing new slot classes; messing with class-precedence-list orderings (Python's MRO). It's a shorter list than I'd hoped! Still, these features kind of multiply up. You can redefine a class using a new metaclass and slot options, and all the instances are updated, for example. Anyway, I think I exaggerated when I said that CLOS was `much more dynamic', but it is /somewhat/ more dynamic, and still amenable to optimization; since my point was that dynamism in a language isn't necessarily antithetical to compilation, that's still sufficient. Thanks for keeping me honest! Fair enough. My view is that even if apparently CLOS has some additional feature over the standard Python object model, in practice you can implement the same features in Python with some metaclass trick, *without the need to change the language at the C level*. This is why I think the Python object model is at least as dynamic as CLOS. In particular, a metaclass can implement the functionality CHANGE- CLASS, can mess with the __bases__ and with the MRO, etc. If you want to see an example of how much the Python object model can be perverted, you may be interested in this module of mine: http://pypi.python.org/pypi/strait The module changes the standard object system from a multiple inheritance one to a single inheritance one plus traits. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Russ P. a écrit : On Jan 23, 4:57 am, Bruno Desthuilliers bruno. 42.desthuilli...@websiteburo.invalid wrote: Russ P. a écrit : As I said before, if you have the source code you can always change private attributes to public in a pinch if the language enforces encapsulation. And then have to maintain a fork. No, thanks. For crying out loud, how many private attributes do you need to access? May I remind you that this is an hypothetical use case ? If it's a dozen, then you and your library developer are obviously not on the same page. If it's one or two, then it's hardly a fork. Just take note of the one or two places where you needed to remove the access restriction and you're done. Yeah, fine. And doing it each and any release. A fork is a fork is a fork... But if you are working on a team project, you can't change the code that another member of a team checks in. Why on earth couldn't I change the code of another member of my team if that code needs changes ? The code is the whole team's ownership. OK, fine, you can change the code of another member of the team. No. I can change the *team's* code. Please *read*. team's ownership, ok ? Or do I have to spell it out loud ? TEAM'S OWNERSHIP. Uh. You get the message, now ? Are you going to check with him first, or just do it? despairI give up./despair (snip) My my my. If you don't trust your programmers, then indeed, don't use Python. What can I say (and what do I care ?). But once again, relying on the language's access restriction to manage *security* is, well, kind of funny, you know ? Are you seriously saying that if you were managing the production of a major financial software package with hundreds of developers, you would just trust them all to have free access to the most sensitive and critical parts of the program? Now *that's*, well, kind of funny, you know? A remote web service - for example - is a far better blackbox when it comes to this kind of sensitive and critical parts. If I can't trust someone wrt/ this part of the code, then he won't even have it as a binary package. Period. Would you give all those developers your password to get into the system? No? Wait a minute ... you mean you wouldn't trust them with your password? But what about openness? Are you some sort of fascist or what? Goodwin point. You loose. Good bye again, Mr P. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Russ P. a écrit : On Jan 23, 6:36 pm, Luis Zarrabeitia ky...@uh.cu wrote: Makes *no* sense? There's *no* good reason *at all* for the original author to hide or protect internals? My bad, sorry. It makes sense... if the original author is an egotist who believes he must control how I use that library. If the original author provides you with the source code and the right to modify it, he cannot possibly control how you use the library. You can trivially disable any access controls. But for some reason that's not enough for you. Has it occurred to you that some users might actually *want* access controls? Then they'll have to choose a language which provides it. Maybe some users want to actually use the library as the author intended it to be used. And ? Strange enough, that's usually what happens - using the official, documented API. Strange enough, it seems that Python programmers are mostly wise enough to not break encapsulation (nor abuse any of the highly dynamic features of Python) without pretty good reasons, lots of thought and attention, clear documentation of the fact, and possibly exchanges with the library author (or maintainer) to discuss the problem. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Bruno Desthuilliers wrote: Russ P. a écrit : On Jan 23, 6:36 pm, Luis Zarrabeitia ky...@uh.cu wrote: Makes *no* sense? There's *no* good reason *at all* for the original author to hide or protect internals? My bad, sorry. It makes sense... if the original author is an egotist who believes he must control how I use that library. If the original author provides you with the source code and the right to modify it, he cannot possibly control how you use the library. You can trivially disable any access controls. But for some reason that's not enough for you. Has it occurred to you that some users might actually *want* access controls? Then they'll have to choose a language which provides it. Maybe some users want to actually use the library as the author intended it to be used. And ? Strange enough, that's usually what happens - using the official, documented API. Strange enough, it seems that Python programmers are mostly wise enough to not break encapsulation (nor abuse any of the highly dynamic features of Python) without pretty good reasons, lots of thought and attention, clear documentation of the fact, and possibly exchanges with the library author (or maintainer) to discuss the problem. Quite. Python is a language for consenting adults. It has perceived deficiencies for certain software engineering environments. Can we drop the subject now? This horse was flogged to death long ago, and it's pointless and cruel to keep on beating the remains. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steve Holden st...@holdenweb.com writes: Quite. Python is a language for consenting adults. Shouldn't such a language allow consenting adults to enter a BDSM scene without being moralized at, if that's what they want to do? ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
2009/1/26 Paul Rubin http://phr.cx@nospam.invalid: Steve Holden st...@holdenweb.com writes: Quite. Python is a language for consenting adults. Shouldn't such a language allow consenting adults to enter a BDSM scene without being moralized at, if that's what they want to do? ;-) The language doesn't stop you. You can shift all of your code over to Ada if you want to, and although /some/ Pythonistas might shake their heads in bewilderment, I don't think there would be any moralising. The question is whether Python has to /provide/ the BDSM scene for you. I don't think it's realistic for a language to provide every possible degree of BDSM from BCPL to Ada, Eiffel and beyond. A language has to be positioned somewhere on the scale, and deciding whether that's the right point on the scale for you and your project is part of what being a grown-up programmer is about. One size does not fit all, one language is not ideal for all applications. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Paul Rubin wrote: Steve Holden st...@holdenweb.com writes: Quite. Python is a language for consenting adults. Shouldn't such a language allow consenting adults to enter a BDSM scene without being moralized at, if that's what they want to do? ;-) Yes, but you know what moralizers are like ... regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Russ P. a écrit : (snip) You are trying to dictate that the library implementer not be allowed to use enforced access restriction. And, in the larger sense, you are trying to dictate that access restrictions not be enforced in Python. FWIW, it's actually *you* who are trying to dictate that access restrictions should be enforced in Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 26, 1:07 am, Bruno Desthuilliers bruno. 42.desthuilli...@websiteburo.invalid wrote: No. I can change the *team's* code. Please *read*. team's ownership, ok ? Or do I have to spell it out loud ? TEAM'S OWNERSHIP. Uh. You get the message, now ? Team ownership doesn't necessarily mean that you can just change code at will. In industry, teams usually have a leader that you need to check with before you can change an interface. A language with enforced access restriction merely provides language support for such coordination. That was my only point. Would you give all those developers your password to get into the system? No? Wait a minute ... you mean you wouldn't trust them with your password? But what about openness? Are you some sort of fascist or what? Goodwin point. You loose. Good bye again, Mr P. You missed the point once again. In asking if you are a fascist, I was *parodying* your attitude that languages with enforced access restrictions are for fascists who don't trust their co-workers or employees. [I don't recall if you actually used that word or if it was someone else, but you did use BD, which carries the same general impression.] So I parodied your hyperbole, and you dismiss me for it. Without realizing it, you just dismissed yourself, sir. Thanks for saving me the trouble. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Quoting Russ P. russ.paie...@gmail.com: On Jan 24, 9:54 pm, Luis Zarrabeitia ky...@uh.cu wrote: Quoting Russ P. russ.paie...@gmail.com: It is. For starters, I'd lose the information of this attribute was intended to be internal and I'm accessing it anyway. Not really. When you get a new version of the library and try to use it, you will quickly get a reminder about the change (assuming your tests provide sufficient converage, and also assuming that the attribute is not made public in the new version). So you don't really even need to keep track of the change. See? With every new version that doesn't change the behaviour, I have to modify the source just to see if the tests run. That _is_ a fork. And that's assuming the bright case where I have the source. No. I am not dictating _anything_. The beauty of it, you don't have to do _anything_ for this to happen. You are trying to dictate that the library implementer not be allowed to use enforced access restriction. And, in the larger sense, you are trying to dictate that access restrictions not be enforced in Python. Now, please, explain to me, why are you so interested on preventing me from using the internals on my computer? If you want controls in the code that runs on your system, you can. Or contacting him about it and maybe send him a patch, sure, why not. But this has nothing to do with enforced data hiding. Having obj._public_var is just as badly designed as having private public_var. Sure, go ahead and contact him. If he agrees that a private attribute should be public, then the problem is solved. But if he does not agree, he should not be forced to bend to your desire. Wait, if I change my project to ignore the data hiding (enforced or not), am I forcing the author to bend for my desire? Please explain your reasoning. Or better yet... don't. I will just give up, right now. This is no longer about security, good practices, software engineering, bug catching or formal proofs as you've tried to paint it before. This is about you wanting to control how others use your code. And while it may be your legal right, that isn't the discussion I thought I was getting into. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Russ P. russ.paie...@gmail.com writes: Calling a one-word change a fork is quite a stretch, I'd say. I wouldn't. I've forked a project P if I've made a different version of it which isn't going to be reflected upstream. Now I've got to maintain my fork, merging in changes from upstream as they happen, and upgrading all the things which use my new version; if I want to distribute my program M to other people, they'll also need my forked version of whatever. Now suppose that two programs A and B both require one-word changes in P: there's a combinatorial explosion of little patches which need to be managed. A fork is a fork, regardless of how big the change is. The problem with a fork is the maintenance problem it entails. Besides, if I want to do some hacky debugging in ipython, should I really have to recompile and reinstall piles of libraries? Has it occurred to you that some users might actually *want* access controls? Maybe some users want to actually use the library as the author intended it to be used. What a bizarre concept! Huh? Then... use it as the author intended. I am _not_ forcing you to use the obj._protected attributes! But what if I want an automatic check to verify that I am using it as the author intended? Is that unreasonable? You mean that you can't /tell/ whether you typed mumble._seekrit? You're very strange. It's kind of hard to do by accident. I'd have thought that you could do that with grep, err... git grep '\._' | sed 's/self\._//g' | grep '\._' ought to do as a rough start. If you can't trust your programmers to make it clear when they're doing something dubious, I think you have bigger problems. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Russ P. russ.paie...@gmail.com writes: Imagine a person who repairs computers. He is really annoyed that he constantly has to remove the cover to get at the guts of the computer. So he insists that computers cases should be made without covers. Poor analogy. He gets fed up that the computers he's meant to be servicing are arriving in sealed containers which require specialist tools to open. After all, manufacturers put covers on computers only because they don't trust us and think we're too stupid to safely handle an uncovered computer box. It's more to do with keeping dust out, keeping air circulating, and keeping fingers away from sharp edges. Fortunately most computers are actually shipped in cases one can remove easily, using household tools -- or even no tools at all. Why, anyone would think that you were supposed to be able to grub about in there! That is logically equivalent to your position on enforced access restrictions in software. It is now that I've fixed it. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 25, 10:04 am, Mark Wooding m...@distorted.org.uk wrote: Russ P. russ.paie...@gmail.com writes: Calling a one-word change a fork is quite a stretch, I'd say. I wouldn't. I've forked a project P if I've made a different version of it which isn't going to be reflected upstream. Now I've got to maintain my fork, merging in changes from upstream as they happen, and upgrading all the things which use my new version; if I want to distribute my program M to other people, they'll also need my forked version of whatever. Now suppose that two programs A and B both require one-word changes in P: there's a combinatorial explosion of little patches which need to be managed. A fork is a fork, regardless of how big the change is. The problem with a fork is the maintenance problem it entails. Not really. A fork is something that *diverges* from the original. That means the differences *grow* over time. In this case, the differences will not grow over time (unless you access more private attributes). As I pointed out before, you don't even need to keep track of the changes you made. You will be automatically reminded as soon as you get a new version of the library and try to use it (again, assuming that your tests provide sufficient coverage and the attribute is not changed to public). Has it occurred to you that some users might actually *want* access controls? Maybe some users want to actually use the library as the author intended it to be used. What a bizarre concept! Huh? Then... use it as the author intended. I am _not_ forcing you to use the obj._protected attributes! But what if I want an automatic check to verify that I am using it as the author intended? Is that unreasonable? You mean that you can't /tell/ whether you typed mumble._seekrit? You're very strange. It's kind of hard to do by accident. I'd have If I have a team of 200 programmers, I can't easily tell if one of them did that somewhere. Why do people like you have such a hard time understanding that I'm not talking here about smallish programs with one or a few developers? And even with only one programmer, he might access mumble._seekrit for a debugging test, then forget to take it out. thought that you could do that with grep, err... git grep '\._' | sed 's/self\._//g' | grep '\._' ought to do as a rough start. If you can't trust your programmers to make it clear when they're doing something dubious, I think you have bigger problems. Yes, I think I have bigger problems. But I like the challenge. I don't think I'd be happy working on small problems, but to each his own. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Fri, 23 Jan 2009 21:36:59 -0500, Luis Zarrabeitia wrote: It makes sense... if the original author is an egotist who believes he must control how I use that library. Then I guess Guido must be such an egotist, because there's plenty of internals in Python that you can't (easy) mess with. Time for some reflection. (Apposite word, as it turns out.) For the avoidance of doubt, I shall grant (and not grudgingly): * Abstraction is a useful tool in building complex systems. * Separating an interface from its implementation reduces the cognitive burden on people trying to reason about the system (including when doing design, developing clients, or trying to do more formal kinds of reasoning). * It also makes maintenance of the implementation easier: in the cases where this it's possible to improve the implementation without changing the interface, clients can benefit without having to be changed. I think that one of the reasons this conversation is going on for so long is that we haven't really talked much about what kinds of `messing' we're talking about. I think that, most of the time when I'm inconvenienced by some abstraction, it's because it's hiding something that I wanted to see -- in a read-only fashion. The implementation knows some fact that, for whatever reason, it's unwilling to reveal to me. I understand that, in some future version, the implementation might change and this fact might not be available then, or that it's an artifact of the way the implementation works in some environment -- but for whatever reason (debugging is a typical one as was pointed out upthread) it turns out that I'm actually interested in this fact. Revealing it to me can't actually hurt the invariants of the system, though I need to be somewhat careful about how long I assume it's correct. Of course, that should be entirely my responsibility. It's this common problem of wanting to dig out some piece of information which I'm really worried about. And `enforced data hiding' just slams the door in my face. I'm not best pleased by the idea. Anyway, in this regard, the CPython implementation is pretty much a paragon of virtue. It lets one get at almost everything one could want and a whole lot else besides. Yes you could, and you could hack the OS to manipulate data behind the scenes, and you could build a hardware device to inject whatever data you want directly into the memory. You can do any of those things. So what? Data hiding isn't about some sort of mythical 100% certainty against any imaginable failure mode. Data hiding is a tool like any other, and like all tools, it has uses and misuses, and it works under some circumstances and not others. If you don't get 100% certainty that there will never be a failure no matter what, what do you get? Just off the top of my head, it: How much of these do you /lose/ by having a somehat more porous interface? * makes it easier for an optimising compiler to give fast code if it doesn't have to assume internal details can be changed; Irrelevant for read-only inspection. For making modifications, this might be a valid point, though (a) I'm unaware of any compilers sufficiently aggressive to make very effective use of this, and (b) I'm probably willing to accommodate the compiler by being sufficiently careful about my hacking. That is: go ahead, use a fancy compiler, and I'll cope as best I can. * makes it easier to separate interface from implementation when you can trust that the implementation actually isn't being used; Irrelevant for read-only inspection. For making modifications: you carry on assuming that the interface is being used as you expect, and I'll take on the job of reasoning about invariants and making sure that everything continues to work. * gives the developer more freedom to change the implementation; For read-only inspection, I might lose if you stop providing the information I want; I'll need to change my code, but you don't need to care. Probably if your implementation has changed that much, the information isn't relevant any more anyway. Besides, if your implementation changes break my code, I get to keep both pieces, and you get to laugh. What's the big deal? * makes it possible for meaningful correctness proofs; Irrelevant for read-only inspection. For making modifications, I'll take on the responsibility for amending the proofs as necessary. * reduces the amount of interconnections between different parts of your program by ensuring that all interaction goes through the interface instead of the implementation; For read-only inspection, I'm not sure this matter much -- if your implementation knows a fact that I want, then either I'll get it through your interface or dredge it out of your implementation's guts, but the module coupling's there either way. (If there was a better way to obtain that fact,
Re: Does Python really follow its philosophy of Readability counts?
On Jan 25, 10:04 am, Mark Wooding m...@distorted.org.uk wrote: But what if I want an automatic check to verify that I am using it as the author intended? Is that unreasonable? You mean that you can't /tell/ whether you typed mumble._seekrit? You're very strange. It's kind of hard to do by accident. But what if you type mumble._seekrit in several places, then the library implementer decides to give in to your nagging and makes it public by changing it to mumble.seekrit. Now suppose you forget to make the corresponding change somewhere in your code, such as mumble._seekrit = zzz You will get no warning at all. You will just be inadvertently creating a new private attribute -- and the assignment that you really want will not get done. For that matter, the library implementer himself could make the same mistake and get no warning. When you think about it, you soon realize that the leading underscore convention violates the spirit if not the letter of one of the first principles of programming 101: if you have a constant parameter that appears in several places, assign the literal value in one place rather than repeating it everywhere. Then if you need to change the value, you only need to change it in one place. That reduces effort, but more importantly it reduces the potential for error. The same principle applies to declaring an attribute private. If that declaration is encoded in every occurrence of its identifier, then if you decide to change it to public, you need to change the identifier at each and every location. But if a private or priv keyword were available, you would only need to make the change in one location. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Sun, 25 Jan 2009 12:01:16 -0800, Russ P. wrote: On Jan 25, 10:04 am, Mark Wooding m...@distorted.org.uk wrote: But what if I want an automatic check to verify that I am using it as the author intended? Is that unreasonable? You mean that you can't /tell/ whether you typed mumble._seekrit? You're very strange. It's kind of hard to do by accident. But what if you type mumble._seekrit in several places, then the library implementer decides to give in to your nagging and makes it public by changing it to mumble.seekrit. Now suppose you forget to make the corresponding change somewhere in your code, such as mumble._seekrit = zzz You will get no warning at all. You will just be inadvertently creating a new private attribute -- and the assignment that you really want will not get done. For that matter, the library implementer himself could make the same mistake and get no warning. When you think about it, you soon realize that the leading underscore convention violates the spirit if not the letter of one of the first principles of programming 101: if you have a constant parameter that appears in several places, assign the literal value in one place rather than repeating it everywhere. Then if you need to change the value, you only need to change it in one place. That reduces effort, but more importantly it reduces the potential for error. How is this scenario different from an API change where public_method() gets changed to method()? Surely this is just a downside to Python's lack of declarations, rather than specific to Python's lack of data hiding? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Mon, 26 Jan 2009 00:59:48 +, Steven D'Aprano wrote: How is this scenario different from an API change where public_method() gets changed to method()? Sorry, that's a poor example, since you were talking about attributes rather than methods. Must stop posting before coffee *wink* Rewording: How is this scenario different from an API change where self.some_attribute gets changed to self.attribute? Surely this is just a downside to Python's lack of declarations, rather than specific to Python's lack of enforced data hiding? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steven D'Aprano st...@remove-this-cybersource.com.au writes: How is this scenario different from an API change where self.some_attribute gets changed to self.attribute? That would be a backward incompatible change to a published interface, something that should not be done without a good reason, and which was mostly avoided through the whole Python 2.x series (incompatible changes were saved for Python 3.0). Changing an undocumented and supposedly private interface is something different entirely. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Sun, 25 Jan 2009 17:15:47 -0800, Paul Rubin wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: How is this scenario different from an API change where self.some_attribute gets changed to self.attribute? That would be a backward incompatible change to a published interface, something that should not be done without a good reason, and which was mostly avoided through the whole Python 2.x series (incompatible changes were saved for Python 3.0). Changing an undocumented and supposedly private interface is something different entirely. We're not talking specifically about Python standard library changes, we're talking about any project which may have more entertaining *cough* policies regarding API changes. Or if you prefer... some projects take the philosophy that the API isn't fixed until version 1.0, and so they can change anything until then. It seems to me that Russ' latest objection to _private names is not specific to _private names. The same problem: You will get no warning at all. You will just be inadvertently creating a new private attribute -- and the assignment that you really want will not get done. occurs with public names as well. However, I do see his point that if we take the presence of a leading underscore in the name as semantically significant, then we're recording that information *everywhere* instead of in one place. That is a lesser version of Hungarian notation -- not as bad as redundantly storing type information that the compiler already knows, but still not ideal. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steven D'Aprano st...@remove-this-cybersource.com.au writes: We're not talking specifically about Python standard library changes, we're talking about any project which may have more entertaining *cough* policies regarding API changes. Oh, yes, I see what you mean. That's a problem even in small projects, sometimes even in 1-person projects. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Russ P. russ.paie...@gmail.com writes: On Jan 25, 10:04 am, Mark Wooding m...@distorted.org.uk wrote: But what if you type mumble._seekrit in several places, then the library implementer decides to give in to your nagging and makes it public by changing it to mumble.seekrit. There's a possibly better fix: introduce a property `seekrit' (or perhaps a better name!) which diddles the _seekrit attribute under the covers. Now suppose you forget to make the corresponding change somewhere in your code, such as mumble._seekrit = zzz You will get no warning at all. You will just be inadvertently creating a new private attribute -- and the assignment that you really want will not get done. True. That's a shame. It'd be nice if there were a way to fix that. There's this __slots__ thing I keep hearing about... For that matter, the library implementer himself could make the same mistake and get no warning. He could do. Why he didn't do a search and replace like any sensible person is a mystery. Testing is good, too. When you think about it, you soon realize that the leading underscore convention violates the spirit if not the letter of one of the first principles of programming 101: if you have a constant parameter that appears in several places, assign the literal value in one place rather than repeating it everywhere. You mean `once and only once'. Yeah, I like that one too. Then if you need to change the value, you only need to change it in one place. That reduces effort, but more importantly it reduces the potential for error. The same principle applies to declaring an attribute private. Introducing a property hides the problem, but doesn't actually solve it, because you're right on this. Fortunately the problem doesn't actually come up that often. But yes, basically, I agree with you on this particular point: it's easier to add an alias than to rename, which avoids the problem but is error prone. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 25, 5:31 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: It seems to me that Russ' latest objection to _private names is not specific to _private names. The same problem: You will get no warning at all. You will just be inadvertently creating a new private attribute -- and the assignment that you really want will not get done. occurs with public names as well. That is true. Any name change could cause that sort of problem. But I brought it up specifically in reply to Mr. Wooding, who pointed out that it is hard to accidentally type a name with a leading underscore without realizing what you are doing. You may fully understand what you are doing when you type it, but you may not realize what has happened later when you forget to change it to be consistent with the new version of the library (or another module in an application). To change an attribute from private to public, the leading-underscore convention requires that every occurrence of the name be changed. That is more error prone than if the change only needs to be done in one place. And the fact that Python allows you to create new attributes on the fly also contributes to this problem, of course. That makes renaming and refactoring riskier in general in Python than in statically typed languages with enforced access restrictions. More care and attention to detail is needed to do it right in Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Russ P. russ.paie...@gmail.com writes: [snip stuff I don't disagree with] That makes renaming and refactoring riskier in general in Python than in statically typed languages with enforced access restrictions. More care and attention to detail is needed to do it right in Python. In fact, I don't disagree with this statement either. It's just that I think there's a legitimate tradeoff between the assurances you can get from a language designed for static analysis and strictness, and the freedom and dynamicness of languages like Python. It's just that I rather like where Python is now on this continuum, and disagree that shifting it is necessarily a good idea. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 25, 7:56 pm, Mark Wooding m...@distorted.org.uk wrote: Russ P. russ.paie...@gmail.com writes: [snip stuff I don't disagree with] That makes renaming and refactoring riskier in general in Python than in statically typed languages with enforced access restrictions. More care and attention to detail is needed to do it right in Python. In fact, I don't disagree with this statement either. It's just that I think there's a legitimate tradeoff between the assurances you can get from a language designed for static analysis and strictness, and the freedom and dynamicness of languages like Python. It's just that I rather like where Python is now on this continuum, and disagree that shifting it is necessarily a good idea. -- [mdw] I would like to have the option to use Python either way, if possible -- and I honestly don't know if it is possible. The new type annotations are a step in that direction. They are optional, but if used they could make refactoring safer and facilitate static analysis. Enforced access restrictions, if they can be added to Python, would be optional too -- as they are in any language. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Paul Rubin http://phr...@nospam.invalid wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: We're not talking specifically about Python standard library changes, we're talking about any project which may have more entertaining *cough* policies regarding API changes. Oh, yes, I see what you mean. That's a problem even in small projects, sometimes even in 1-person projects. I think it is more prevalent in single person projects than what we have the honesty to admit - After all, if *I* am writing the code, then *I* can do what *I* want, and often *I* do, much to *my* chagrin, when the effects strike home. Do I talk about it? - No way! I just quietly fix it. Sometimes too much freedom is not such a good thing - it leads to all sort of effects of which API spec. creep is one of the least. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Fri, 23 Jan 2009 21:36:59 -0500, Luis Zarrabeitia wrote: Quoting Steven D'Aprano st...@remove-this-cybersource.com.au: On Fri, 23 Jan 2009 13:07:55 -0500, Luis Zarrabeitia wrote: It should be in _our_ power as the team of all participant coders on _our_ project to decide if we should mess with the internals or not. What makes no sense is that it should be in the original author's power to decide, if he is not part of _our_ team. Makes *no* sense? There's *no* good reason *at all* for the original author to hide or protect internals? My bad, sorry. It makes sense... if the original author is an egotist who believes he must control how I use that library. Then I guess Guido must be such an egotist, because there's plenty of internals in Python that you can't (easy) mess with. Or, if external forces make him do it (maybe like, 'oh, if I change python, then I'm not using python anymore'). That parenthesised comment makes no sense to me. Python has changed significantly since it was first released. Recently, print became a function instead of a statement, and one of the motivations for this was to allow people to change the behaviour of Python's print simply by defining a new function. Shadowing built-ins, as they call it, is a feature, not a bug. I can't see any good reason for thinking that if you change (say) the way Python prints, you don't have Python any more. Even more fundamental changes have occurred, e.g. new style classes, ABCs, nested scopes. [...] If a variable is marked as... I don't like 'private', I'll call it 'implementation detail', I would not use it without good reason. Not even by subclassing it. Why do you assume that I'd change list._length if I could? I wouldn't. I didn't say you would change it on a whim. I said that *if* it were exposed to Python code, you *could* change it. You might change it because you thought you had a good reason to. You might change it by accident. You might not realise the consequences of changing it. Who knows? It doesn't matter what your motives are. My point is that you claimed that there is no good reason at all for hiding implementation details. Python is full of implementation details which are quite effectively hidden from Python programmers. So there are two possibilities: (1) you are right that it makes no sense (your words) for the original author (in this case, Guido) to hide those implementation details from Python programmers; or (2) you are wrong that it makes no sense, because there is at least one case where the original author (Guido again) did a sensible thing by hiding implementation details. In an effort to avoid going round and round in circles, let me explicitly say that option (2) does not imply that it always makes sense to hide implementation details. Anyway, did you notice that your counter-example was a radical change-the-way-python-works scenario? No, my scenario is merely extending what you can already do with pure- Python classes to built-in classes written in C. It would have a radical effect (pure Python code could core dump easily) but it wouldn't be a radical change. It might take as little as one new function. [...] So what you're saying is that the fundamental design of Python -- to be a high-level language that manages memory for you while avoiding common programming errors such as buffer overflows -- makes no sense. Is that what you intended? Yes, that's what I intended, obviously. I'd like to have buffer overflows in python. In case you don't understand irony: don't go putting words in my mouth. I'm not putting words in yours. And neither am I. I'm pointing out the logical implications of your position. If you find those implications unpleasant, then perhaps you should modify your position to be less extreme and more realistic. As I see it, you have two coherent positions. On the one hand, you could be like Mark Wooding, and say that Yes you want to risk buffer overflows by messing with the internals -- in which case I'm not sure what you see in Python, which protects so many internals from you. Or you can say that you made a mistake, that there are *some* good reasons to protect/hide internals from external access. Or, I could have a third option: assume that I am a grownup who knows what he is doing. This is totally orthogonal to what we're discussing. Whether you are a grownup or a child, whether you have good reasons or bad reasons, you can still make either of the two choices. After all, even with all those protections in list, I could just create an extension module to shoot me in the foot anyway, if I really wanted to. Yes you could, and you could hack the OS to manipulate data behind the scenes, and you could build a hardware device to inject whatever data you want directly into the memory. You can do any of those things. So what? Data hiding isn't about some sort of mythical 100% certainty against
Re: Does Python really follow its philosophy of Readability counts?
Quoting Russ P. russ.paie...@gmail.com: On Jan 23, 6:36 pm, Luis Zarrabeitia ky...@uh.cu wrote: Makes *no* sense? There's *no* good reason *at all* for the original author to hide or protect internals? My bad, sorry. It makes sense... if the original author is an egotist who believes he must control how I use that library. If the original author provides you with the source code and the right to modify it, he cannot possibly control how you use the library. You can trivially disable any access controls. But for some reason that's not enough for you. No, I'm not satisfied with forking python just to use sys._getframe. Has it occurred to you that some users might actually *want* access controls? Maybe some users want to actually use the library as the author intended it to be used. What a bizarre concept! Huh? Then... use it as the author intended. I am _not_ forcing you to use the obj._protected attributes! Even I run pylint against third party libraries just to assess if the risk of them messing with someone else's internals is worth taking (as in the case of inspect.currentframe, which is exactly the same as sys._getframe) or not (random library downloaded from the net). Oh, but only a paranoid fool could possibly want access controls, eh? Who's the egotist here? See? You too changed what I said. Somehow you managed to delete the _other_ situation I gave. Not worth correcting it. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
2009/1/24 Rhodri James rho...@wildebst.demon.co.uk: My experience with medium-sized organisations (50-100 people) is that either you talk to Fred directly, or it doesn't happen. In particular the more people (especially PHBs) that get involved, the slower the change will come and the less like your original requirement it will look. Each person, no matter how technically adept, has a significant chance of misunderstanding what it is you need and/or expressing it poorly to the next person in line. So you talk to Fred, and he changes the pong library function to go ping, as you wish. Unfortulately, neither of you know that Alice is depending on Fred's pong library function to go pong as specified, and is totally stuffed when he delivers it and it goes ping. That's why changes to specifications need to go through a proper specification change procedure if the team (not the organisation) is more than a few people. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Quoting Steven D'Aprano st...@remove-this-cybersource.com.au: On Fri, 23 Jan 2009 21:36:59 -0500, Luis Zarrabeitia wrote: Quoting Steven D'Aprano st...@remove-this-cybersource.com.au: Makes *no* sense? There's *no* good reason *at all* for the original author to hide or protect internals? My bad, sorry. It makes sense... if the original author is an egotist who believes he must control how I use that library. Then I guess Guido must be such an egotist, because there's plenty of internals in Python that you can't (easy) mess with. Yeap, ignore the second part, and claim that I only said this. Or, if external forces make him do it (maybe like, 'oh, if I change python, then I'm not using python anymore'). That parenthesised comment makes no sense to me. It was directly countering your 'list' example. _I_ don't want to change _python_, nor python's assumptions and assurances. A standard python that can segfault would be no python. Again, if you think that means that deep down I like enforced data hiding, so be it. [...] If a variable is marked as... I don't like 'private', I'll call it 'implementation detail', I would not use it without good reason. Not even by subclassing it. Why do you assume that I'd change list._length if I could? I wouldn't. I didn't say you would change it on a whim. I said that *if* it were exposed to Python code, you *could* change it. You might change it because you thought you had a good reason to. You might change it by accident. You might not realise the consequences of changing it. Who knows? It doesn't matter what your motives are. Exactly, they don't matter to you, unless you happen to be running my code. My point is that you claimed that there is no good reason at all for hiding implementation details. Python is full of implementation details which are quite effectively hidden from Python programmers. So there are two possibilities: I didn't say at all. Those were your words, not mine. I said that it makes no sense that the power lies on _you_ instead of on _my team_. And, when I said that, I recall we were talking about the python language, not C. (1) you are right that it makes no sense (your words) for the original author (in this case, Guido) to hide those implementation details from Python programmers; or Just to be clear: I think the opposite. He made a language and interpreter, and it ensures that it will not segfault because of incorrect pure python code. That is my blackbox. In doing that, he made a language where I don't have to worry that much about enforcing access restrictions. Again, if you think that means that I want enforced data hiding in python, so be it. (2) you are wrong that it makes no sense, because there is at least one case where the original author (Guido again) did a sensible thing by hiding implementation details. hiding the implementation details of a C implementation... not python. In an effort to avoid going round and round in circles, let me explicitly say that option (2) does not imply that it always makes sense to hide implementation details. Huh? It makes sense to hide implementations details. I'd say it always makes sense. What doesn't make sense is that someone fights so vehemently to stop me from getting at them, on my code, on my systems. [...] So what you're saying is that the fundamental design of Python -- to be a high-level language that manages memory for you while avoiding common programming errors such as buffer overflows -- makes no sense. Is that what you intended? Yes, that's what I intended, obviously. I'd like to have buffer overflows in python. In case you don't understand irony: don't go putting words in my mouth. I'm not putting words in yours. And neither am I. I'm pointing out the logical implications of your position. If you find those implications unpleasant, then perhaps you should modify your position to be less extreme and more realistic. But it is realistic. You put the words at all, and you shifted the discussion from Python to C, and from programs in python to python's implementation. [snip the comments about the advantages of data hiding. We are not talking about data hiding, we are talking about having data hiding enforced against me] I stand by my words - but not by your interpretation of them: What makes no sense is that it should be in the original author's power to decide, if he is not part of _our_ team. Do you _really_ read from that sentence that I should dislike python because it makes it a bit harder to get a buffer overflow with their native types? Well, you tell me: does it make sense for Guido to have decided to make it hard for pure Python developers to cause buffer overflows? Yes it does. And this answers my question... You do consider the fact that I like python, that I like that python is not C, and that I use python as a blackbox, as a confirmation
Re: Does Python really follow its philosophy of Readability counts?
On Jan 24, 4:17 pm, Luis Zarrabeitia ky...@uh.cu wrote: Quoting Russ P. russ.paie...@gmail.com: On Jan 23, 6:36 pm, Luis Zarrabeitia ky...@uh.cu wrote: Makes *no* sense? There's *no* good reason *at all* for the original author to hide or protect internals? My bad, sorry. It makes sense... if the original author is an egotist who believes he must control how I use that library. If the original author provides you with the source code and the right to modify it, he cannot possibly control how you use the library. You can trivially disable any access controls. But for some reason that's not enough for you. No, I'm not satisfied with forking python just to use sys._getframe. Calling a one-word change a fork is quite a stretch, I'd say. Has it occurred to you that some users might actually *want* access controls? Maybe some users want to actually use the library as the author intended it to be used. What a bizarre concept! Huh? Then... use it as the author intended. I am _not_ forcing you to use the obj._protected attributes! But what if I want an automatic check to verify that I am using it as the author intended? Is that unreasonable? Think of enforced access restriction as an automatic assert every time an attribute is accessed that it is not a private attribute. I may want this automatic verification in my own code just for peace of mind. More importantly, a project manager may want it to verify that no one on the development team is accessing private attributes. Sure, he could do that with code reviews, but code reviews are far more expensive (and less reliable in some ways) than a simple check enforced by the language itself. Without enforced access protection, depending on code reviews to detect the use of private attributes is a bit like depending on security guards to keep doors closed without putting locks on the doors. You don't need a lock on a door if you can afford to post a security guard there full time, but doesn't it make more sense to put a lock on the door and have a security guard check it only occasionally? -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 24, 5:09 pm, Luis Zarrabeitia ky...@uh.cu wrote: I didn't say at all. Those were your words, not mine. I said that it makes no sense that the power lies on _you_ instead of on _my team_. And, when I said that, I recall we were talking about the python language, not C. Once again, if you have the source code for the library (and the right to modify it), how does the power lie with the library implementer rather than you the user? You say you don't want to fork the library. Let's stipulate for the sake of argument that a one-line change is indeed a fork. Think about what you are saying. You are saying that you should dictate how the producer of the library should implement it because you don't want to be bothered to fork it. If you don't like his design decisions, shouldn't the onus be on *you* to make the trivial change necessary to get access to what you want? Imagine a person who repairs computers. He is really annoyed that he constantly has to remove the cover to get at the guts of the computer. So he insists that computers cases should be made without covers. After all, manufacturers put covers on computers only because they don't trust us and think we're too stupid to safely handle an uncovered computer box. That is logically equivalent to your position on enforced access restrictions in software. And, FYI, when programming in java, C++ or C#, I do use private and protected variables, not becasue I want to forbid others from using it, but because it is [rightly?] assumed that everything marked as public is safe to use - and I consider that a strong enough external reason to do it. You could just use leading underscores and note their meaning in the documentation. If that's such a great approach, why not do it? Yes, I know, it's not a widely used convention in those other languages. Fair enough. But you could still do it if it's such a good idea. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Sun, 25 Jan 2009 00:31:14 -, Tim Rowe digi...@gmail.com wrote: 2009/1/24 Rhodri James rho...@wildebst.demon.co.uk: My experience with medium-sized organisations (50-100 people) is that either you talk to Fred directly, or it doesn't happen. In particular the more people (especially PHBs) that get involved, the slower the change will come and the less like your original requirement it will look. Each person, no matter how technically adept, has a significant chance of misunderstanding what it is you need and/or expressing it poorly to the next person in line. So you talk to Fred, and he changes the pong library function to go ping, as you wish. Unfortulately, neither of you know that Alice is depending on Fred's pong library function to go pong as specified, and is totally stuffed when he delivers it and it goes ping. That's why changes to specifications need to go through a proper specification change procedure if the team (not the organisation) is more than a few people. And, not coincidentally, why specification will take at least twice as long as you thought humanly possible, and any implementation you do before it's complete will probably have to be thrown away. The productivity of a team large enough that they don't all talk to each other anyway drops quite dramatically as one consequence of this. This also assumes that the proper specification change procedure works, which seems to be a bit on the optimistic side in many cases. But we digress. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Quoting Russ P. russ.paie...@gmail.com: Once again, if you have the source code for the library (and the right to modify it), how does the power lie with the library implementer rather than you the user? You say you don't want to fork the library. Let's stipulate for the sake of argument that a one-line change is indeed a fork. It is. For starters, I'd lose the information of this attribute was intended to be internal and I'm accessing it anyway. Think about what you are saying. You are saying that you should dictate how the producer of the library should implement it because you don't want to be bothered to fork it. No. I am not dictating _anything_. The beauty of it, you don't have to do _anything_ for this to happen. Now, you may say that I'm trying to force you to relax and do nothing instead of complaining because the language I use doesn't put enough restrictions on me. If you don't like his design decisions, shouldn't the onus be on *you* to make the trivial change necessary to get access to what you want? Or contacting him about it and maybe send him a patch, sure, why not. But this has nothing to do with enforced data hiding. Having obj._public_var is just as badly designed as having private public_var. Imagine a person who repairs computers. He is really annoyed that he constantly has to remove the cover to get at the guts of the computer. So he insists that computers cases should be made without covers. After all, manufacturers put covers on computers only because they don't trust us and think we're too stupid to safely handle an uncovered computer box. That is logically equivalent to your position on enforced access restrictions in software. Do you realize that most computer cases are trivially easy to open? (Nevermind that there are other reasons... dust, protection against physical damage, etc. My PC is locked enough to protect them, but opened enough so I can play with it whenever I need) And, FYI, when programming in java, C++ or C#, I do use private and protected variables, not becasue I want to forbid others from using it, but because it is [rightly?] assumed that everything marked as public is safe to use - and I consider that a strong enough external reason to do it. You could just use leading underscores and note their meaning in the documentation. If that's such a great approach, why not do it? Yes, I know, it's not a widely used convention in those other languages. Fair enough. It is not a widely used convention, and that is reason enough for me. It's quite a contradiction to say in the code this thing is safe to use and then document it as highly unsafe - do not touch. With Java and C# I'm more lenient (and work more with explicit interfaces rather than just the public/protected/private thing). BTW, the actual 'private' case for most languages is a different beast: it is used to prevent namespace pollution/name clashes. I can't easily simulate those with public attributes in C#/Java/C++ (but I concede that their 'privates' do a better job at this than python's self.__local) But you could still do it if it's such a good idea. I think someone commented in this thread about a case where he had to do exactly that. [copying from your other reply] But what if I want an automatic check to verify that I am using it as the author intended? Is that unreasonable? Think of enforced access restriction as an automatic assert every time an attribute is accessed that it is not a private attribute. I think that was a reply to a message where I said that I used pylint run those checks on third party libraries. And I obviously can do the same with my own code. I don't have threading now, so I can't check if I really said that. If I didn't, well, I'm saying it now. Now, as Paul Robin pointed out, those statics checks done by pylint can't catch a runtime workaround using eval, exec or getattr/setattr. But neither can C++. By the way, I urge you to try to write code that pylint doesn't complain about. It's easy to not be satisfied with the checks it provides if you haven't used it. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 24, 9:54 pm, Luis Zarrabeitia ky...@uh.cu wrote: Quoting Russ P. russ.paie...@gmail.com: Once again, if you have the source code for the library (and the right to modify it), how does the power lie with the library implementer rather than you the user? You say you don't want to fork the library. Let's stipulate for the sake of argument that a one-line change is indeed a fork. It is. For starters, I'd lose the information of this attribute was intended to be internal and I'm accessing it anyway. Not really. When you get a new version of the library and try to use it, you will quickly get a reminder about the change (assuming your tests provide sufficient converage, and also assuming that the attribute is not made public in the new version). So you don't really even need to keep track of the change. Think about what you are saying. You are saying that you should dictate how the producer of the library should implement it because you don't want to be bothered to fork it. No. I am not dictating _anything_. The beauty of it, you don't have to do _anything_ for this to happen. You are trying to dictate that the library implementer not be allowed to use enforced access restriction. And, in the larger sense, you are trying to dictate that access restrictions not be enforced in Python. Now, you may say that I'm trying to force you to relax and do nothing instead of complaining because the language I use doesn't put enough restrictions on me. And you are trying to put restrictions on anyone who might prefer to enforce access restrictions. If you don't allow them to do that, you are restricting them. If you don't like his design decisions, shouldn't the onus be on *you* to make the trivial change necessary to get access to what you want? Or contacting him about it and maybe send him a patch, sure, why not. But this has nothing to do with enforced data hiding. Having obj._public_var is just as badly designed as having private public_var. Sure, go ahead and contact him. If he agrees that a private attribute should be public, then the problem is solved. But if he does not agree, he should not be forced to bend to your desire. Imagine a person who repairs computers. He is really annoyed that he constantly has to remove the cover to get at the guts of the computer. So he insists that computers cases should be made without covers. After all, manufacturers put covers on computers only because they don't trust us and think we're too stupid to safely handle an uncovered computer box. That is logically equivalent to your position on enforced access restrictions in software. Do you realize that most computer cases are trivially easy to open? (Nevermind That was exactly my point. Deleting the word private (or whatever) is also trivially easy if you have access to the source code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steven D'Aprano a écrit : On Thu, 22 Jan 2009 19:10:05 +, Mark Wooding wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote: Steven D'Aprano a écrit : But if you have free access to attributes, then *everything* is interface. Nope. How could anyone fail to be convinced by an argument that detailed and carefully reasoned? Well, your claim /was/ just wrong. But if you want to play dumb: the interface is what's documented as being the interface. But you miss my point. We're told Python doesn't have private attributes. Yes. We're told that we're allowed to mess with the internals, Given that we're willing and able to cope with possible consequences. we're *encouraged* to do so Certainly not. Python gives you the freedom to do so, and any suggestion that freedom might be reduced even a tiny bit is fought passionately. Won't comment on this. When people ask how to implement private attributes, they're often told not to bother even using single-underscore names. often ? Not as far as I can tell. I think you're confusing this with the advice to not use getters/setters for no good reason, given Python's support for computed attributes - which is not exactly the same thing. When it is suggested that Python should become stricter, with enforced data hiding, the objections come thick and fast: people vehemently say that they like Python just the way it is, that they want the ability to mess with the internals. Indeed. There's no shortage of BD languages, and well, Python is OSS, so if you want a BD Python (now that's an oxymoron), please feel free to implement it. But by all mean, leave my favorite language alone. Thanks. You even argued that you disliked data structures implemented in C and preferred those written in Python because you have more ability to mess with the private attributes. In context, I had just mentioned that lists' internals were inaccessible from Python code. I neglected to give an example at the time, but a good example is the current length of the list. Consider the experience of Microsoft and Apple. Yes, two great examples of freedom champions. No matter how often they tell people not to mess with the internals, people do it anyway, and always believe that their reason is a good reason. And who are *you* to pronounce any judgement about that ? And Python culture encourages that behaviour (albeit the consequences are milder: no buffer overflows or core dumps). Add to that the culture of Open Source that encourages reading the source code. Indeed. A *very* good thing FWIW. You don't need to buy a book called Undocumented Tips and Tricks for Python to discover the internals. You just need to read the source code. Exactly. And then you have at least two places in the standard library where _attributes are *explicitly* public: http://bugs.python.org/issue3152 Given this permissive culture, any responsible For your personal definition of responsible. library writer must assume that if he changes his so-called private attributes, he will break other people's code. You still don't get the point. If someone's code breaks because he messed with my implementation code, then *he* is responsible. The contract is very clear : warranty void if unsealed. In principle it could break just as much code as if he didn't even bother flagging them with a leading underscore, which is probably why many people don't even bother with _names. In other words, if you make it easy for people to mess with your internals, if you have a culture that allows and even encourages them to mess with your internals, then you don't have internals. Everything is de facto public. Now that you've exposed your opinions, let's face reality (I mean, *facts*): Python developpers very rarely mess with implementation, usually do so for very good (and documented) reasons, and from what I've seen usually tend to get in touch with the library author to explain their case and find a better solution. Funny enough, it looks that the more you treat programmers as responsible, normally intelligent adult person, the more they tend to behave as such. And the other way around, too. Now, you comprehensively exposed your personnal distaste for Python's and more generally OSS philosophy. So I can only - as I already did way before in this thread - wonder *why* are you using Python ? I mean, is it because your bosses forces you to do so ? If yes, then, I'm truly sorry for you - I sometimes have to work with languages I really dislike so I can feel your pain (but OTHO, I never complained on these languages newsgroups about how wrong they were nor how they should IMHO be). Else, well, I just don't get the point. What you are fussing about are fundamental design choices (and philosophic points) that are well known, explained, advertized, etc. - and are really
Re: Does Python really follow its philosophy of Readability counts?
Russ P. a écrit : On Jan 21, 4:04 am, Bruno Desthuilliers bruno. 42.desthuilli...@websiteburo.invalid wrote: Russ P. a écrit : (snip) Your mistake for being a moron. But it seems to happen regularly, doesn't it. How much more of my time are you going to waste, loser? Calling people names is certainly not the best way to defend your opinions here. Adios, Mr. P. You are absolutely right, Mr. D. I regret that post, and I have since apologized to the person I was addressing. This stuff really isn't important enough to get that worked up about. Ok, so welcome back then. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 23, 1:54 am, Bruno Desthuilliers bruno. 42.desthuilli...@websiteburo.invalid wrote: Steven D'Aprano a écrit : On Thu, 22 Jan 2009 19:10:05 +, Mark Wooding wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote: Steven D'Aprano a écrit : But if you have free access to attributes, then *everything* is interface. Nope. How could anyone fail to be convinced by an argument that detailed and carefully reasoned? Well, your claim /was/ just wrong. But if you want to play dumb: the interface is what's documented as being the interface. But you miss my point. We're told Python doesn't have private attributes. Yes. We're told that we're allowed to mess with the internals, Given that we're willing and able to cope with possible consequences. we're *encouraged* to do so Certainly not. Python gives you the freedom to do so, and any suggestion that freedom might be reduced even a tiny bit is fought passionately. Won't comment on this. When people ask how to implement private attributes, they're often told not to bother even using single-underscore names. often ? Not as far as I can tell. I think you're confusing this with the advice to not use getters/setters for no good reason, given Python's support for computed attributes - which is not exactly the same thing. When it is suggested that Python should become stricter, with enforced data hiding, the objections come thick and fast: people vehemently say that they like Python just the way it is, that they want the ability to mess with the internals. Indeed. There's no shortage of BD languages, and well, Python is OSS, so if you want a BD Python (now that's an oxymoron), please feel free to implement it. But by all mean, leave my favorite language alone. Thanks. You even argued that you disliked data structures implemented in C and preferred those written in Python because you have more ability to mess with the private attributes. In context, I had just mentioned that lists' internals were inaccessible from Python code. I neglected to give an example at the time, but a good example is the current length of the list. Consider the experience of Microsoft and Apple. Yes, two great examples of freedom champions. No matter how often they tell people not to mess with the internals, people do it anyway, and always believe that their reason is a good reason. And who are *you* to pronounce any judgement about that ? And Python culture encourages that behaviour (albeit the consequences are milder: no buffer overflows or core dumps). Add to that the culture of Open Source that encourages reading the source code. Indeed. A *very* good thing FWIW. You don't need to buy a book called Undocumented Tips and Tricks for Python to discover the internals. You just need to read the source code. Exactly. And then you have at least two places in the standard library where _attributes are *explicitly* public: http://bugs.python.org/issue3152 Given this permissive culture, any responsible For your personal definition of responsible. library writer must assume that if he changes his so-called private attributes, he will break other people's code. You still don't get the point. If someone's code breaks because he messed with my implementation code, then *he* is responsible. The contract is very clear : warranty void if unsealed. In principle it could break just as much code as if he didn't even bother flagging them with a leading underscore, which is probably why many people don't even bother with _names. In other words, if you make it easy for people to mess with your internals, if you have a culture that allows and even encourages them to mess with your internals, then you don't have internals. Everything is de facto public. Now that you've exposed your opinions, let's face reality (I mean, *facts*): Python developpers very rarely mess with implementation, usually do so for very good (and documented) reasons, and from what I've seen usually tend to get in touch with the library author to explain their case and find a better solution. Funny enough, it looks that the more you treat programmers as responsible, normally intelligent adult person, the more they tend to behave as such. And the other way around, too. Now, you comprehensively exposed your personnal distaste for Python's and more generally OSS philosophy. So I can only - as I already did way before in this thread - wonder *why* are you using Python ? I mean, is it because your bosses forces you to do so ? If yes, then, I'm truly sorry for you - I sometimes have to work with languages I really dislike so I can feel your pain (but OTHO, I never complained on these languages newsgroups about how wrong they were nor how they should IMHO be). Else, well, I just don't get
Re: Does Python really follow its philosophy of Readability counts?
On Jan 22, 9:22 pm, Russ P. russ.paie...@gmail.com wrote: code. You can play around with the internals all you want in your own little world, but as when you are working with a team, you need to adhere to the interfaces they define (if any). The word as should not be there: ... but when you are working with a team, ... Sorry, but that was bothering me. I sure wish these posts could be edited after they are submitted. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On 2009-01-16, Luis Zarrabeitia ky...@uh.cu wrote: Quoting Russ P. russ.paie...@gmail.com: On Jan 15, 12:21 pm, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Once again, the important point is that there's a *clear* distinction between interface and implementation, and that you *shouldn't* mess with implementation. If you *shouldn't* mess with the implementation, then what is wrong with enforcing that shouldn't in the language itself? Because, as a library user, it should be my power to chose when and how I _should_ mess with the implementation, not the compiler, and definitely not you. Why should it be in your power? By messing with the implementation of a library you risk the correctness of the code of all participant coders in that project. I not that sure it should be your power to chose when and how to do that. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Fri, 23 Jan 2009 10:54:53 +0100, Bruno Desthuilliers wrote: In context, I had just mentioned that lists' internals were inaccessible from Python code. I neglected to give an example at the time, but a good example is the current length of the list. Consider the experience of Microsoft and Apple. Yes, two great examples of freedom champions. What does that little dig at Microsoft and Apple have to do with what we're discussing? I dare say Linux has private internals too. Let's see if we can find some in 30 seconds of googling. http://forum.soft32.com/linux2/Bug-406747-linux-kernel-headers-private- symbols-u16-u32-asm-ftopict67443.html http://groups.google.com/group/linux.kernel/browse_thread/thread/ a08fd6423204e918 Those fascists! Private data in the kernel!!! Why can't my userland app mess with the kernel's private data??? It's so unfair!!! No matter how often they tell people not to mess with the internals, people do it anyway, and always believe that their reason is a good reason. And who are *you* to pronounce any judgement about that ? Did I pronounce any judgement? ... [Any] library writer must assume that if he changes his so-called private attributes, he will break other people's code. You still don't get the point. If someone's code breaks because he messed with my implementation code, then *he* is responsible. The contract is very clear : warranty void if unsealed. You've built something full of user serviceable parts. You've insisted, publicly and loudly, that the ability to modify those parts is absolutely essential, you've rejected every effort to lock down those internals, and then when somebody does exactly what you encourage, you suddenly turn on them and say they're on their own. That's pretty irresponsible behaviour. As an aside, Apple and Microsoft have opposite approaches to dealing with this problem. Apple hangs the developer out to dry, which is why there are so few developers who make Mac software, while Microsoft goes to (or at least did) heroic efforts to protect developers from their mistakes, which is why the Windows internals is a dog's breakfast but there are more Windows developers named Steve then there are Mac developers in total. (BTW, I'm not one of them.) http://www.joelonsoftware.com/articles/APIWar.html Now that you've exposed your opinions, let's face reality (I mean, *facts*): Python developpers very rarely mess with implementation, usually do so for very good (and documented) reasons, and from what I've seen usually tend to get in touch with the library author to explain their case and find a better solution. Facts, are they? Care to provide some reputable sources for these facts? Funny enough, it looks that the more you treat programmers as responsible, normally intelligent adult person, the more they tend to behave as such. And the other way around, too. You're the one who repeatedly declared that programmers who modified internals were cretins who should be fired. I never said such a thing -- in fact, I defended them. Now, you comprehensively exposed your personnal distaste for Python's and more generally OSS philosophy. Really? I did? Fancy that. So I can only - as I already did way before in this thread - wonder *why* are you using Python ? Ah yes, the old if you're not 100% for us, you must be 100% against us argument. Anyone who thinks that there are costs as well as benefits to dynamic programming must be a freedom-hater, and probably kicks puppies too. I mean, is it because your bosses forces you to do so ? Yeah, my mean old boss forces me to write Python scripts in my spare time, he forces me to spend my personal time on comp.lang.python, he forces me to write things like: [quote] Oh yes, it is liberating to say I don't care if my method crashes (raises an exception), it's the caller's fault for messing with my class' internals, and he can deal with it. I'm not being sarcastic by the way. It really is liberating not to have to deal with unexpected input or broken pre-conditions. Just let the caller deal with it! [end quote] What a mean old boss! If yes, then, I'm truly sorry for you - I sometimes have to work with languages I really dislike so I can feel your pain (but OTHO, I never complained on these languages newsgroups about how wrong they were nor how they should IMHO be). If people hadn't complained about missing features/misdesigns, would Python have: generator expressions print as a function booleans nested scopes None as a keyword ABCs closures to name just a few? I am curious though... you've made a few comments that suggest that your in favour of more freedom, rather than less: you've made a disparaging comment about Microsoft and Apple, you apparently think highly of Open Source software, and more. Does this freedom extend to people who have criticisms -- even mild criticisms -- of Python? Else, well, I just don't get the
Re: Does Python really follow its philosophy of Readability counts?
Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Thu, 22 Jan 2009 19:10:05 +, Mark Wooding wrote: Well, your claim /was/ just wrong. But if you want to play dumb: the interface is what's documented as being the interface. But you miss my point. Evidently. We're told Python doesn't have private attributes. We're told that we're allowed to mess with the internals, we're *encouraged* to do so: Python gives you the freedom to do so, and any suggestion that freedom might be reduced even a tiny bit is fought passionately. Your deduction skills are faulty. * Python gives us the freedom to do so, and we fight to protect that freedom -- yes. * But interpreting that as encouragement is wrong. It's permission, not encouragement. If you don't want to, that's fine, and we won't think less of you. Many things are possible which aren't, as a general rule, good ideas. Misinterpreting permission as encouragement will lead you to doing many stupid things. When people ask how to implement private attributes, they're often told not to bother even using single-underscore names. When it is suggested that Python should become stricter, with enforced data hiding, the objections come thick and fast: people vehemently say that they like Python just the way it is, that they want the ability to mess with the internals. You even argued that you disliked data structures implemented in C and preferred those written in Python because you have more ability to mess with the private attributes. In context, I had just mentioned that lists' internals were inaccessible from Python code. I neglected to give an example at the time, but a good example is the current length of the list. Umm... I'm pretty sure that that's available via the `len' function, which is tied to list.__len__ (via the magic C-implemented-type mangler, in C). Though it's read-only -- and this is a shame, 'cos it'd be nice to be able to adjust the length of a list in ways which are more convenient than * deleting or assigning to a trailing slice, or * augmenting or assigning to a trailing zero-width slice (Perl has supported assigning to $#ARRAY for a long time. Maybe that's a good argument against it.) Consider the experience of Microsoft and Apple. No matter how often they tell people not to mess with the internals, people do it anyway, and always believe that their reason is a good reason. And Microsoft and Apple can either bend over backwards to preserve compatibility anyway (which effectively rewards the misbehaviour) or change the internals. I'd prefer that they did the latter. There are times when messing with internals is the only way to get things done; but there's a price to be paid for doing that, and the price is compatibility. The internals will change in later versions, and your code will break, in subtle and complex ways. It's not always an easy decision to make -- but I'm glad it's me that gets to decide, and not some random who neither knows nor cares much about the problem I'm trying to solve. It's also important to bear in mind that programs' lifetimes vary. Some programs are expected to live for years; some programs only for a week or so; and some for just long enough to be typed and executed once (e.g., at the interactive prompt). That Python is useful for all these kinds of program lifetimes is testament to its designers' skill. Programmers can, and should!, make different tradeoffs depending on the expected lifetime of the program they're writing. If I type some hacky thing at ipython, I know it's going to be executed there and then, and if the implementation changes tomorrow, I just don't care. If I'm writing a thing to solve an immediate problem, I won't need it much past next week, and I'll still probably get away with any awful hacking -- but there's a chance I might reuse the program in a year or so, so I ought to put a comment in warning the reader of a possible bitrot site. If I'm writing a thing that's meant to last for years, I need to plan accordingly, and it's probably no appropriate to hack with internals without a very good reason. Making these kinds of decisions isn't easy. It requires experience, subtle knowledge of how the systems one's using work, and occasionally a little low cunning. And sometimes one screws up. And Python culture encourages that behaviour (albeit the consequences are milder: no buffer overflows or core dumps). Add to that the culture of Open Source that encourages reading the source code. You don't need to buy a book called Undocumented Tips and Tricks for Python to discover the internals. You just need to read the source code. Indeed. Very useful. Example: for my cryptographic library bindings, I needed to be able to convert between Python's `long's and my library's `mp's. I have a choice between doing it very slowly (using shift and masking operators on the `long') or fast (by including
Re: Does Python really follow its philosophy of Readability counts?
Russ P. a écrit : (snip) I am curious about something. Have you ever needed to access a private attribute (i.e., one named with a leading underscore) in Python code that you did not have the source code for? For that matter, have you ever even used a library written in Python without having access to the source code? No to both. As I said before, if you have the source code you can always change private attributes to public in a pinch if the language enforces encapsulation. And then have to maintain a fork. No, thanks. But if you are working on a team project, you can't change the code that another member of a team checks in. Why on earth couldn't I change the code of another member of my team if that code needs changes ? The code is the whole team's ownership. Now and FWIW, in this case (our own code), I just don't need to mess with internals - I just just change what needs to be changed. That is how enforced data hiding helps teams of developers manage interfaces. I totally fails to find any evidence of this assertion in the above demonstration. The bigger the team and the bigger the project, the more it helps. Your opinion. Mr. D'Aprano gave an excellent example of a large banking program. Without enforced encapsulation, anyone on the development team has access to the entire program and could potentially sneak in fraudulent code much more easily than if encapsulation were enforced by the language. My my my. If you don't trust your programmers, then indeed, don't use Python. What can I say (and what do I care ?). But once again, relying on the language's access restriction to manage *security* is, well, kind of funny, you know ? I am certainly not saying that Python is useless without enforced data hiding. It is obviously very useful for a wide range of applications and domains already. I am only saying that it's usefulness could be enhanced if enforced encapsulation can be added You might have a chance to sell this to a clueless pointy haired boss - I mean, that enforced access restriction will make Python more suitable for some big enterprizey project. As far as I'm concerned, I'm not buying it. without somehow comromising the language. Then just forget it. I don't know enough about the inner workings of the Python interpreter to know if that is the case or not (I am an aeronautical engineer), but the objections I've seen so far on this thread have not impressed me. I've not seen much technical objections - but anyway: learn (I mean, *really* learn) how Python's object model works, and you'll perhaps find out why this would break the whole thing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 23, 4:30 am, Mark Wooding m...@distorted.org.uk wrote: Suppose that you write a Python library module and release it. I find that it's /almost/ the right thing for some program of mine, but it doesn't quite work properly unless I hack about like so... perfect! I'm a happy bunny; you've gained a user (maybe that's a good thing, maybe it isn't!). Now, I've hacked about in your module's internal stuff: how has this affected you? Answer: not at all; you probably didn't feel a thing. You release a new version with improved internal structure and my program breaks: how has this affected you? Answer: still not at all. How did it affect me? Quite a bit, but then again, I knew what I was getting into. I gambled and lost; oh, well, that happens sometimes. Was this library module released in source form? If so, then why would you care that it has enforced access restrictions? You can just take them out, then do whatever you would have done had they not been there to start with. I don't see how that is any more work than figuring out what internals you need to access. Either way you need to read and understand the code. Wait ... it wasn't released in source form? Then how would you even know what internals you need to access? And why would you use something that goes against your philosophy of openness anyway? -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Fri, 23 Jan 2009 13:57:52 +0100, Bruno Desthuilliers wrote: As I said before, if you have the source code you can always change private attributes to public in a pinch if the language enforces encapsulation. And then have to maintain a fork. No, thanks. If you're messing with the internals, you have to do this anyway. As soon as the internals change, your monkey-patched solution falls apart. But if you are working on a team project, you can't change the code that another member of a team checks in. Why on earth couldn't I change the code of another member of my team if that code needs changes ? The code is the whole team's ownership. That's a model that works well when you have a small team of, say, a dozen people. It's not a model that works when you have hundreds of developers working on the project. The last thing I want in my projects is cowboys who ride all over other people's code, changing internals of parts they barely know at the drop of a hat, causing who knows what side- effects. But anyway, this is a red-herring. Data hiding isn't really about managing the development process, it's about ensuring that when you and Fred are using Barney's OrderedDict class in your code, Barney is free to change his the implementation without your code suddenly failing. It's also to ensure that any changes you make at runtime to the class don't suddenly make Fred's code break. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 23, 4:57 am, Bruno Desthuilliers bruno. 42.desthuilli...@websiteburo.invalid wrote: Russ P. a écrit : As I said before, if you have the source code you can always change private attributes to public in a pinch if the language enforces encapsulation. And then have to maintain a fork. No, thanks. For crying out loud, how many private attributes do you need to access? If it's a dozen, then you and your library developer are obviously not on the same page. If it's one or two, then it's hardly a fork. Just take note of the one or two places where you needed to remove the access restriction and you're done. Heck, you don't even need to do that, because you will be warned automatically anyway when you get the new version of the library (unless those private attributes are changed to public). But if you are working on a team project, you can't change the code that another member of a team checks in. Why on earth couldn't I change the code of another member of my team if that code needs changes ? The code is the whole team's ownership. OK, fine, you can change the code of another member of the team. Are you going to check with him first, or just do it? The point is that changing an interface requires agreement of the team members who use that interface, whether on the calling or the implementation side of it. If you change interfaces without getting agreement with the other team members, you probably won't be on the team for long. And without access restrictions, accessing _private is equivalent to changing the interface. Now and FWIW, in this case (our own code), I just don't need to mess with internals - I just just change what needs to be changed. That is how enforced data hiding helps teams of developers manage interfaces. I totally fails to find any evidence of this assertion in the above demonstration. The bigger the team and the bigger the project, the more it helps. Your opinion. Mr. D'Aprano gave an excellent example of a large banking program. Without enforced encapsulation, anyone on the development team has access to the entire program and could potentially sneak in fraudulent code much more easily than if encapsulation were enforced by the language. My my my. If you don't trust your programmers, then indeed, don't use Python. What can I say (and what do I care ?). But once again, relying on the language's access restriction to manage *security* is, well, kind of funny, you know ? Are you seriously saying that if you were managing the production of a major financial software package with hundreds of developers, you would just trust them all to have free access to the most sensitive and critical parts of the program? Now *that's*, well, kind of funny, you know? Would you give all those developers your password to get into the system? No? Wait a minute ... you mean you wouldn't trust them with your password? But what about openness? Are you some sort of fascist or what? -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Fri, 23 Jan 2009 05:42:38 -0800, Russ P. wrote: My my my. If you don't trust your programmers, then indeed, don't use Python. What can I say (and what do I care ?). But once again, relying on the language's access restriction to manage *security* is, well, kind of funny, you know ? Are you seriously saying that if you were managing the production of a major financial software package with hundreds of developers, you would just trust them all to have free access to the most sensitive and critical parts of the program? Now *that's*, well, kind of funny, you know? I think this is a red-herring. Probably my fault -- I was the first one to mention access controls for banking software. I meant it as an analog to data hiding, rather than implying that one can or should use private/ protected attributes to implement data hiding. Private attributes are a form of data hiding, but not all data hiding can be implemented as private attributes. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Bruno Desthuilliers wrote: Russ P. a écrit : [...] Mr. D'Aprano gave an excellent example of a large banking program. Without enforced encapsulation, anyone on the development team has access to the entire program and could potentially sneak in fraudulent code much more easily than if encapsulation were enforced by the language. My my my. If you don't trust your programmers, then indeed, don't use Python. What can I say (and what do I care ?). But once again, relying on the language's access restriction to manage *security* is, well, kind of funny, you know ? I have to say that I thought the example was somewhat bogus. Any development team that is even slightly concerned about the possibility of logic bombs in the code will try to mitigate that possibility by the use of code inspections. I am certainly not saying that Python is useless without enforced data hiding. It is obviously very useful for a wide range of applications and domains already. I am only saying that it's usefulness could be enhanced if enforced encapsulation can be added You might have a chance to sell this to a clueless pointy haired boss - I mean, that enforced access restriction will make Python more suitable for some big enterprizey project. As far as I'm concerned, I'm not buying it. I'm not sure that there's much to be gained by this level of dogmatism on either side. Enforced encapsulation has been implemented in both C++ and Java, and both have proved to be circumventable. Just the same, talk of clueless pointy-haired bosses is unlikely to be convincing. Even the pointy-haired types never recognize themselves as such. Annotations *have* made it into 3.0, so it's possible that the might become usable. Remember, they'll always be optional, so those who don't want to use them won't lose anything at all. [...] regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Hello thats excellant !! On 1/23/09, Russ P. russ.paie...@gmail.com wrote: On Jan 23, 4:57 am, Bruno Desthuilliers bruno. 42.desthuilli...@websiteburo.invalid wrote: Russ P. a écrit : As I said before, if you have the source code you can always change private attributes to public in a pinch if the language enforces encapsulation. And then have to maintain a fork. No, thanks. For crying out loud, how many private attributes do you need to access? If it's a dozen, then you and your library developer are obviously not on the same page. If it's one or two, then it's hardly a fork. Just take note of the one or two places where you needed to remove the access restriction and you're done. Heck, you don't even need to do that, because you will be warned automatically anyway when you get the new version of the library (unless those private attributes are changed to public). But if you are working on a team project, you can't change the code that another member of a team checks in. Why on earth couldn't I change the code of another member of my team if that code needs changes ? The code is the whole team's ownership. OK, fine, you can change the code of another member of the team. Are you going to check with him first, or just do it? The point is that changing an interface requires agreement of the team members who use that interface, whether on the calling or the implementation side of it. If you change interfaces without getting agreement with the other team members, you probably won't be on the team for long. And without access restrictions, accessing _private is equivalent to changing the interface. Now and FWIW, in this case (our own code), I just don't need to mess with internals - I just just change what needs to be changed. That is how enforced data hiding helps teams of developers manage interfaces. I totally fails to find any evidence of this assertion in the above demonstration. The bigger the team and the bigger the project, the more it helps. Your opinion. Mr. D'Aprano gave an excellent example of a large banking program. Without enforced encapsulation, anyone on the development team has access to the entire program and could potentially sneak in fraudulent code much more easily than if encapsulation were enforced by the language. My my my. If you don't trust your programmers, then indeed, don't use Python. What can I say (and what do I care ?). But once again, relying on the language's access restriction to manage *security* is, well, kind of funny, you know ? Are you seriously saying that if you were managing the production of a major financial software package with hundreds of developers, you would just trust them all to have free access to the most sensitive and critical parts of the program? Now *that's*, well, kind of funny, you know? Would you give all those developers your password to get into the system? No? Wait a minute ... you mean you wouldn't trust them with your password? But what about openness? Are you some sort of fascist or what? -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
2009/1/22 Scott David Daniels scott.dani...@acm.org: Having once been a more type-A, I labored for a couple of years trying to build a restricted language that provably terminated for work on an object-oriented database research. I was careful to say that it was the /use/ of the language that is restricted; it's still possible to write undecidable programs, there's just an obligation on you to show that you haven't. I finally gave it up as a bad idea, because, in practice, we don't care if a loop will terminate or not in database work; a transaction that takes a year to commit is equivalent to an infinite loop for all applications that I have interacted with (and yes, I have worked allowing four day transactions to commit). True -- the really serious safety critical stuff is usually real time, and part of the proof obligations is to show that the maximum response time is tolerable. The loop variant can help with that, too. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 23, 6:21 am, Steve Holden st...@holdenweb.com wrote: I have to say that I thought the example was somewhat bogus. Any development team that is even slightly concerned about the possibility of logic bombs in the code will try to mitigate that possibility by the use of code inspections. Of course they would, but that does not mean that access restrictions enforced by the language are not prudent. Consider a corporation that needs to maintain the physical security of their buildings. You can say that locks on the doors are not sufficient. Of course they're not. Security guards are needed too -- but that doesn't mean the locks are not needed too. The locks may be *insufficient* by themselves, but they are certainly not *unnecessary*. Ditto for the enforced encapsulation for large financial or safety-critical projects. I'm not sure that there's much to be gained by this level of dogmatism on either side. Enforced encapsulation has been implemented in both C++ and Java, and both have proved to be circumventable. Just the same, talk of clueless pointy-haired bosses is unlikely to be convincing. Even the pointy-haired types never recognize themselves as such. Do you think the designers of C++, Java, Ada, and Scala would eliminate the enforced encapsulation if they had it to do over again? Of course not. The vast majority of the users of those languages consider it a major plus. And those who don't wish to use it aren't forced to use it except perhaps by their bosses or their customers. Again, I am not saying that Python necessarily needs enforced access restriction. I'm just saying it would be a plus if it can be added without compromising the language in some way. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Friday 23 January 2009 06:31:50 am Antoon Pardon wrote: On 2009-01-16, Luis Zarrabeitia ky...@uh.cu wrote: Quoting Russ P. russ.paie...@gmail.com: If you *shouldn't* mess with the implementation, then what is wrong with enforcing that shouldn't in the language itself? Because, as a library user, it should be my power to chose when and how I _should_ mess with the implementation, not the compiler, and definitely not you. Why should it be in your power? By messing with the implementation of a library you risk the correctness of the code of all participant coders in that project. I not that sure it should be your power to chose when and how to do that. Ok, let me fix that. It should be in _our_ power as the team of all participant coders on _our_ project to decide if we should mess with the internals or not. What makes no sense is that it should be in the original author's power to decide, if he is not part of _our_ team. Do you like it better now? Wasn't it obvious in the first place? -- Luis Zarrabeitia (aka Kyrie) Fac. de Matemática y Computación, UH. http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Russ P. russ.paie...@gmail.com writes: OK, fine, you can change the code of another member of the team. Are you going to check with him first, or just do it? The point is that changing an interface requires agreement of the team members who use that interface, whether on the calling or the implementation side of it. If you change interfaces without getting agreement with the other team members, you probably won't be on the team for long. So far, so good. And without access restrictions, accessing _private is equivalent to changing the interface. You've basically unilaterally stretched it, yes. Programmers who do this when the implementer of the interface is three feet away deserve to get smacked. If you don't have an easy way to get the interface extended, you have a pleasant choice between hacking at the guts and just being screwed. Have a nice day. On Jan 23, 4:57 am, Bruno Desthuilliers bruno. 42.desthuilli...@websiteburo.invalid wrote: My my my. If you don't trust your programmers, then indeed, don't use Python. What can I say (and what do I care ?). But once again, relying on the language's access restriction to manage *security* is, well, kind of funny, you know ? Are you seriously saying that if you were managing the production of a major financial software package with hundreds of developers, you would just trust them all to have free access to the most sensitive and critical parts of the program? Now *that's*, well, kind of funny, you know? If you're working with developers you don't trust, you're going to lose anyway. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steven D'Aprano st...@remove-this-cybersource.com.au writes: You've built something full of user serviceable parts. You've insisted, publicly and loudly, that the ability to modify those parts is absolutely essential, you've rejected every effort to lock down those internals, and then when somebody does exactly what you encourage, you suddenly turn on them and say they're on their own. That's pretty irresponsible behaviour. An egregious mischaracterization. Again, you're refusing to see the distinction between a published, stable interface, and exposed but potentially volatile internals. If you use my published interface and your program is broken by a change, it's my fault and I try to fix it; if you use the internals and your program's broken by a change, it's your fault and you're on your own. It's pretty easy. There are three possibilities: * The interface does what I want it to do. Cool. I win. * The interface doesn't do what I want it to do, but I can hack the internal guts until it does. Cool for now, but I might get screwed later if they change. Well, it's something to think about. * The interface doesn't do what I want it to do, and I can't hack the internal guts. I just lose. If all interfaces were perfect, there wouldn't be an argument. But they aren't. So we're sometimes left with the other two choices. Which one looks more appealing to you? -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Russ P. russ.paie...@gmail.com writes: Was this library module released in source form? If so, then why would you care that it has enforced access restrictions? You can just take them out, then do whatever you would have done had they not been there to start with. I don't see how that is any more work than figuring out what internals you need to access. Either way you need to read and understand the code. I could do. But in practice internal details often aren't horrifically unstable. If I fork the library, I've now got to mess with distributing the forked version, and keeping the patch up to date -- the codebase is likely to be much more volatile than the internals I'm hacking on. It's just not such a good tradeoff. See elsewhere where I described hacking Python's `long' representation. You'd have me fork the Python interpreter. That doesn't seem like a win to me. Wait ... it wasn't released in source form? Then how would you even know what internals you need to access? We call them `disassemblers' and `debuggers'. Sometimes even simple experimentation is sufficient. And why would you use something that goes against your philosophy of openness anyway? I try not to. Sometimes I fail. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steve Holden st...@holdenweb.com writes: Annotations *have* made it into 3.0, so it's possible that the might become usable. Remember, they'll always be optional, so those who don't want to use them won't lose anything at all. There's a problem here. An interface has two sides. Access control annotations, as far as I've seen so far, look like they're only optional on one side: that is, once specified on the implementation side, they have a mandatory effect on the user side. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Fri, 23 Jan 2009 13:57:52 +0100, Bruno Desthuilliers wrote: Why on earth couldn't I change the code of another member of my team if that code needs changes ? The code is the whole team's ownership. That's a model that works well when you have a small team of, say, a dozen people. It's not a model that works when you have hundreds of developers working on the project. The last thing I want in my projects is cowboys who ride all over other people's code, changing internals of parts they barely know at the drop of a hat, causing who knows what side- effects. Why are you assuming that Bruno would make his change in such an irresponsible manner? Such things need discussing, with some appropriate level of formality, with the people most involved with the relevant code -- which might be anything between a quick chat with the bloke across the room or an agenda item on the next team meeting to a written proposal. Given your apparent readiness to assume the worst of programmers at every opportunity (e.g., your above assumption that Bruno would change code unilaterally and secretly, assumptions elsewhere that programmers treat any exposed wiring as being published interface), I can only assume that you really need to get some better cow-orkers. But anyway, this is a red-herring. Data hiding isn't really about managing the development process, it's about ensuring that when you and Fred are using Barney's OrderedDict class in your code, Barney is free to change his the implementation without your code suddenly failing. It's also to ensure that any changes you make at runtime to the class don't suddenly make Fred's code break. If Barney, Fred and I share a room, we can discuss what we need from OrderedDict around the water-cooler. If we're all in different continents, the tradeoffs look different. If Barney's the kind of guy with quick turnaround, I might well just ask for the necessary change. If I'll have to wait for the next release in July (for posterity: it's January now) I'll probably hack the guts now. If I do that, Barney's still free to change his implementation. It might screw me, but that's my problem and not his; the alternative, with mandatory `hiding', is that I just lose: possible breakage down the line looks like an improvement. Now we come on to Fred. If Fred's across the room from me then we're back to the water-cooler. If he's on a different continent, and I know he'll be affected, I'll probably email him. If I've never heard of him at all, well, he might just lose when someone puts my code and Fred's together with OrderedDict; hopefully I'll get a bug report (I ought to have put a notice in with my distribution explaining that it uses undocumented internals of OrderedDict, so I should be in the firing line) and we'll sort through the wreckage. But again, if I just lost in the second paragraph, we wouldn't even have got this far. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Mark Wooding m...@distorted.org.uk writes: Now we come on to Fred. If Fred's across the room from me then we're back to the water-cooler. If he's on a different continent, and I know he'll be affected, I'll probably email him. If I've never heard of him at all, well, he might just lose when someone puts my code and Fred's together with OrderedDict... In a large project, more probably you'd enter a change request into some kind of tracking system, there would be discussion in the tracking system about how to do the change; perhaps at your weekly staff meeting you might bring up the issue with your PHB if you were blocking on the issue, and your PHB would bring it up at the inter-PHB meeting with Fred's PHB to bump the item's priority, and eventually Fred would check in a change and you would use it. There is necessarily some wasted motion in any organization of that size; good management is about keeping the friction to a minimum and getting the stuff done. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Fri, 23 Jan 2009 20:09:48 +, Mark Wooding wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Fri, 23 Jan 2009 13:57:52 +0100, Bruno Desthuilliers wrote: Why on earth couldn't I change the code of another member of my team if that code needs changes ? The code is the whole team's ownership. That's a model that works well when you have a small team of, say, a dozen people. It's not a model that works when you have hundreds of developers working on the project. The last thing I want in my projects is cowboys who ride all over other people's code, changing internals of parts they barely know at the drop of a hat, causing who knows what side- effects. Why are you assuming that Bruno would make his change in such an irresponsible manner? I did? Where did I make that assumption? What I said was that the model The code is the whole team's ownership doesn't work well for large projects. *One* reason it doesn't work for large projects is that you will invariably have cowboys who, given half a chance, will code irresponsibly *if you let them* by encouraging the attitude that, sure, that class written by the database backend team belongs to everyone, never mind that you're in the UI team, go right ahead and use whatever internals you like. There are other reasons -- do I need to elaborate on them? Even in a project as small as Python there is sense of *individual* (rather than collective) code ownership, in the sense of responsibility for specific portions of the code base. Scale up the project by a factor of ten, and the problems caused by collective responsibility are simply intractable. Such things need discussing, with some appropriate level of formality, with the people most involved with the relevant code -- which might be anything between a quick chat with the bloke across the room or an agenda item on the next team meeting to a written proposal. Yes, and when you have hundreds of developers working on the project, the chances are quite good that there will be twenty such agenda items every week, and then the project will bog down on arguments about what needs to be private and what doesn't, until the project manager just makes a blanket ruling No Access To Internals Full Stop. And then, you know what, the project still manages to go forward. Instead of spending 15 minutes hacking the existing Foo class to do what they want, and then 15 hours dealing with the cascading bugs when the class changes, people simply spend 7 hours subclassing Foo to get what they want, and it's all good and not the end of the world. Given your apparent readiness to assume the worst of programmers at every opportunity (e.g., your above assumption that Bruno would change code unilaterally and secretly, assumptions elsewhere that programmers treat any exposed wiring as being published interface), I can only assume that you really need to get some better cow-orkers. Now you're just being naive. The solution to these sorts of problems isn't get better programmers because even the best programmers make mistakes (errors, and errors of judgement). Communication breaks down -- Fred is sure Barney said Yes while Barney is equally positive he said No. Or somebody has a demo to the CEO in two hours and needs to hack something up Right Now and the guy he has to chat to is home sick with the phone turned off, and by the time he comes back to work the little hack is forgotten. Or whatever. There's a *bazillion* number of things that can go wrong in big projects, and getting better programmers only reduces that to something like a hundred million. It's a credit to *everybody*, including the cowboys and the cow-orkers, that any project of any significant size makes any progress at all. Besides, better programmers are in short supply. Sometimes you have to use who you've got, because Guido and the timbot are working somewhere else and you can't afford them. That's why we have languages like Python: so that *ordinary* programmers can be as productive as genius programmers in languages like C. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Fri, 23 Jan 2009 13:07:55 -0500, Luis Zarrabeitia wrote: It should be in _our_ power as the team of all participant coders on _our_ project to decide if we should mess with the internals or not. What makes no sense is that it should be in the original author's power to decide, if he is not part of _our_ team. Makes *no* sense? There's *no* good reason *at all* for the original author to hide or protect internals? Let's be specific here. The list implementation in CPython is an array with a hidden field storing the current length. If this hidden field was exposed to Python code, you could set it to a value much larger than the actual size of the array and cause buffer overflows, and random Python code could cause core dumps (and possibly even security exploits). So what you're saying is that the fundamental design of Python -- to be a high-level language that manages memory for you while avoiding common programming errors such as buffer overflows -- makes no sense. Is that what you intended? As I see it, you have two coherent positions. On the one hand, you could be like Mark Wooding, and say that Yes you want to risk buffer overflows by messing with the internals -- in which case I'm not sure what you see in Python, which protects so many internals from you. Or you can say that you made a mistake, that there are *some* good reasons to protect/hide internals from external access. In the second case, the next question is, why should it only be code written in C that is allowed that protection? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steven D'Aprano st...@remove-this-cybersource.com.au writes: I did? Where did I make that assumption? I inferred it from the juxtaposition, apparently in error. Sorry. What I said was that the model The code is the whole team's ownership doesn't work well for large projects. *One* reason it doesn't work for large projects is that you will invariably have cowboys who, given half a chance, will code irresponsibly *if you let them* by encouraging the attitude that, sure, that class written by the database backend team belongs to everyone, never mind that you're in the UI team, go right ahead and use whatever internals you like. `Cowboys' will code irresponsibly anyway; they need reeducating gently with a stick. Such things need discussing, with some appropriate level of formality, with the people most involved with the relevant code -- which might be anything between a quick chat with the bloke across the room or an agenda item on the next team meeting to a written proposal. Yes, and when you have hundreds of developers working on the project, the chances are quite good that there will be twenty such agenda items every week, and then the project will bog down on arguments about what needs to be private and what doesn't, until the project manager just makes a blanket ruling No Access To Internals Full Stop. Err... you've wandered off the track here. The purpose of the proposed changes is to expose the right interfaces so that people don't need to fiddle with internals. If I've discovered that I need to dredge something out of the middle of your module, I have three choices: (a) somehow get your module changed so that it hands me the information I want through a documented interface, (b) suck your module's brains out through a straw whether the interface lets me or not, or (c) lose. The agenda items are supporting (a), which I thought you were in favour of; you certainly seem to be against (b), and (c) doesn't look appealing. And then, you know what, the project still manages to go forward. Instead of spending 15 minutes hacking the existing Foo class to do what they want, and then 15 hours dealing with the cascading bugs when the class changes, people simply spend 7 hours subclassing Foo to get what they want, and it's all good and not the end of the world. Subclassing hardly fixes these sorts of problems well. Hardly any class libraries are documented sufficiently well enough to support subclassing properly. Have a look at the CLOS MOP specification http://www.lisp.org/mop/index.html for a rare example of how to do it right. Besides, better programmers are in short supply. Sometimes you have to use who you've got, because Guido and the timbot are working somewhere else and you can't afford them. That's why we have languages like Python: so that *ordinary* programmers can be as productive as genius programmers in languages like C. Why waste genius programmers on churning out C? Just imagine how much they could do with something like Python! -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 23, 7:01 pm, Mark Wooding m...@distorted.org.uk wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: I did? Where did I make that assumption? I inferred it from the juxtaposition, apparently in error. Sorry. What I said was that the model The code is the whole team's ownership doesn't work well for large projects. *One* reason it doesn't work for large projects is that you will invariably have cowboys who, given half a chance, will code irresponsibly *if you let them* by encouraging the attitude that, sure, that class written by the database backend team belongs to everyone, never mind that you're in the UI team, go right ahead and use whatever internals you like. `Cowboys' will code irresponsibly anyway; they need reeducating gently with a stick. A lot of this is a question of how tight you want the handcuffs. Stricter backgrounds and bigger projects make you want tighter ones. You can't jump right from tight handcuffs to loose ones. You'll tend to like them looser over time. A language looser than Python in unheard of. Google says: 'No results found for looser than Python.' -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steven D'Aprano st...@remove-this-cybersource.com.au writes: Let's be specific here. The list implementation in CPython is an array with a hidden field storing the current length. If this hidden field was exposed to Python code, you could set it to a value much larger than the actual size of the array and cause buffer overflows, and random Python code could cause core dumps (and possibly even security exploits). [...] As I see it, you have two coherent positions. On the one hand, you could be like Mark Wooding, and say that Yes you want to risk buffer overflows by messing with the internals Please, point out where I said that! I'm pretty sure that the only time I commented on this particular point (in message 87y6x2cih0.fsf@metalzone.distorted.org.uk), I said: : Umm... I'm pretty sure that that's available via the `len' function, : which is tied to list.__len__ (via the magic C-implemented-type mangler, : in C). Though it's read-only -- and this is a shame, 'cos it'd be nice : to be able to adjust the length of a list in ways which are more : convenient than : : * deleting or assigning to a trailing slice, or : * augmenting or assigning to a trailing zero-width slice : : (Perl has supported assigning to $#ARRAY for a long time. Maybe that's : a good argument against it.) While I realise I didn't spell it out, the semantics I had in mind where foo.len = n means if n 0: raise ValueError, 'don\'t be stupid' elif len(foo) n: foo += [None] * (n - len(foo)) else: foo[n:] = [] (I'm not fussy what the new array slots get filled with, but it seems sensible to be clear. Perl's semantics are more complicated: if you decrease $#foo and then increase it again you get the old values back. Common Lisp users will recall the idea of a fill-pointer.) If there's anything unsafe about that, I'll be surprised. -- in which case I'm not sure what you see in Python, which protects so many internals from you. Or you can say that you made a mistake, that there are *some* good reasons to protect/hide internals from external access. Safety is good. Escape hatches are good, too. In the second case, the next question is, why should it only be code written in C that is allowed that protection? Because Python code can't cause those sorts of problems without resorting to the escape hatches (e.g., ctypes). And, very significantly, because C code /needs/ that protection and Python basically doesn't. The basic difference is that C code is fundamentally brittle: if you mess up its invariants, it can crash horribly and possibly allow its brain to be taken over by evil people. Python code is fundamentally robust. The worst that can happen[1] is that the interpreter raises an exception. This makes it ideally suited to having a more relaxed attitude to life. And that, in turn, makes it approachable, hackable interactively, fun! [1] Assuming that (a) the Python implementation and C extensions are correct, and (b) that the code in question isn't using the escape hatches. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Mark Wooding wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: I did? Where did I make that assumption? I inferred it from the juxtaposition, apparently in error. Sorry. What I said was that the model The code is the whole team's ownership doesn't work well for large projects. *One* reason it doesn't work for large projects is that you will invariably have cowboys who, given half a chance, will code irresponsibly *if you let them* by encouraging the attitude that, sure, that class written by the database backend team belongs to everyone, never mind that you're in the UI team, go right ahead and use whatever internals you like. `Cowboys' will code irresponsibly anyway; they need reeducating gently with a stick. Unfortunately on large projects it's impossible to avoid cowboys, and some of them are completely lost to reason. [...] regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Fri, 23 Jan 2009 21:28:22 -, Paul Rubin http://phr.cx@nospam.invalid wrote: Mark Wooding m...@distorted.org.uk writes: Now we come on to Fred. If Fred's across the room from me then we're back to the water-cooler. If he's on a different continent, and I know he'll be affected, I'll probably email him. If I've never heard of him at all, well, he might just lose when someone puts my code and Fred's together with OrderedDict... In a large project, more probably you'd enter a change request into some kind of tracking system, there would be discussion in the tracking system about how to do the change; perhaps at your weekly staff meeting you might bring up the issue with your PHB if you were blocking on the issue, and your PHB would bring it up at the inter-PHB meeting with Fred's PHB to bump the item's priority, and eventually Fred would check in a change and you would use it. There is necessarily some wasted motion in any organization of that size; good management is about keeping the friction to a minimum and getting the stuff done. My experience with medium-sized organisations (50-100 people) is that either you talk to Fred directly, or it doesn't happen. In particular the more people (especially PHBs) that get involved, the slower the change will come and the less like your original requirement it will look. Each person, no matter how technically adept, has a significant chance of misunderstanding what it is you need and/or expressing it poorly to the next person in line. If I need something that goes 'ping' by Friday, and get something that goes 'pong' three weeks later (together with a note from Fred telling me that three-and-fourpence isn't going to get me into any of the good dance clubs), I'd have been better off taking a hacksaw to the internals myself and presenting my fix for Fred's consideration. Python allows me to do this without the fuss and drama that strict encapsulation seems to posit is necessary, instead of delaying an entire release cycle because the process doesn't trust me. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Quoting Steven D'Aprano st...@remove-this-cybersource.com.au: On Fri, 23 Jan 2009 13:07:55 -0500, Luis Zarrabeitia wrote: It should be in _our_ power as the team of all participant coders on _our_ project to decide if we should mess with the internals or not. What makes no sense is that it should be in the original author's power to decide, if he is not part of _our_ team. Makes *no* sense? There's *no* good reason *at all* for the original author to hide or protect internals? My bad, sorry. It makes sense... if the original author is an egotist who believes he must control how I use that library. Or, if external forces make him do it (maybe like, 'oh, if I change python, then I'm not using python anymore'). Let's be specific here. The list implementation in CPython is an array with a hidden field storing the current length. If this hidden field was exposed to Python code, you could set it to a value much larger than the actual size of the array and cause buffer overflows, and random Python code could cause core dumps (and possibly even security exploits). In which case, my code would be broken. (Wait, let me be clear: in which case, our team's code may be broken - but it was _our_ team's decision, knowing the risk). If a variable is marked as... I don't like 'private', I'll call it 'implementation detail', I would not use it without good reason. Not even by subclassing it. Why do you assume that I'd change list._length if I could? I wouldn't. Anyway, did you notice that your counter-example was a radical change-the-way-python-works scenario? I also don't want to change the interpreter's code on the fly. Now, if you take that as a confession that I really, really, want enforced data hiding and that everything I've said is plain wrong, so be it. After all, I treat python's interpreter as a black box, don't I? So what you're saying is that the fundamental design of Python -- to be a high-level language that manages memory for you while avoiding common programming errors such as buffer overflows -- makes no sense. Is that what you intended? Yes, that's what I intended, obviously. I'd like to have buffer overflows in python. In case you don't understand irony: don't go putting words in my mouth. I'm not putting words in yours. As I see it, you have two coherent positions. On the one hand, you could be like Mark Wooding, and say that Yes you want to risk buffer overflows by messing with the internals -- in which case I'm not sure what you see in Python, which protects so many internals from you. Or you can say that you made a mistake, that there are *some* good reasons to protect/hide internals from external access. Or, I could have a third option: assume that I am a grownup who knows what he is doing. After all, even with all those protections in list, I could just create an extension module to shoot me in the foot anyway, if I really wanted to. In the second case, the next question is, why should it only be code written in C that is allowed that protection? Bug? Not worth the effort of exposing those variables? I don't know... [Btw, do you realize that C++'s private also don't provide that protection? I have almost no experience with C++ and found it trivial to circumvent] I don't think this is going anywhere. Now you are trying to push me to the extremes, changing what I _said_ for your exaggerated interpretation of it just so you could shoot it down, or force me to say that I want buffer overflows in python. I believe that's called strawman. I stand by my words - but not by your interpretation of them: What makes no sense is that it should be in the original author's power to decide, if he is not part of _our_ team. Do you _really_ read from that sentence that I should dislike python because it makes it a bit harder to get a buffer overflow with their native types? -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Rhodri James rho...@wildebst.demon.co.uk writes: My experience with medium-sized organisations (50-100 people) is that either you talk to Fred directly, or it doesn't happen. In particular the more people (especially PHBs) that get involved, the slower the change will come and the less like your original requirement it will look. Usually there would be enough communication with Fred that Fred is be aware of the problem and the amount of work needed to fix it (maybe you've even submitted a patch that Fred can commit after review and testing), but Fred has ten thousand other things that also need getting done. The job of the PHB's is to stay on top of what issues are important for the overall project and juggle the priorities of individual tasks. They figure out whether developing some feature pushes something else out of the way for the upcoming release, or gets slid off to the next one, or whatever. When they do a good job, that takes a big load off of the programmers. It is, to some extent, also part of the PHB's job to filter the traffic and protect both Fred and you from making too many interruptions for each other. This is especially important if you're the type of programmer who tends to get their hands in a lot of different areas of a project. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Sat, 24 Jan 2009 03:18:05 -, Paul Rubin http://phr.cx@nospam.invalid wrote: It is, to some extent, also part of the PHB's job to filter the traffic and protect both Fred and you from making too many interruptions for each other. This is especially important if you're the type of programmer who tends to get their hands in a lot of different areas of a project. In a perfect environment this is true. In an environment where the PHBs are overstretched because their PHBs aren't up to much, that filter function tends to become a full roadblock. Under those circumstances you have three choices: 1) defeat the data hiding by talking to Fred directly; 2) defeat the data hiding by hacking away yourself and getting Fred's forgiveness later; 3) give up. See, we're back on topic! -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Sat, 24 Jan 2009 01:41:35 +, Mark Wooding wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: ... As I see it, you have two coherent positions. On the one hand, you could be like Mark Wooding, and say that Yes you want to risk buffer overflows by messing with the internals Please, point out where I said that! I'm pretty sure that the only time I commented on this particular point (in message 87y6x2cih0.fsf@metalzone.distorted.org.uk), I said: [snip] Yes, that was the quote I was thinking of. While I realise I didn't spell it out, the semantics I had in mind where foo.len = n means if n 0: raise ValueError, 'don\'t be stupid' elif len(foo) n: foo += [None] * (n - len(foo)) else: foo[n:] = [] But that's not messing with the internals. That's the conceptual equivalent of a Python getter/setter: # Pseudo-code, untested and incomplete class MyList(list): def __init__(self): self._length = 0 def _getlength(self): return self._length def _setlength(self, n): if n 0: raise ValueError(don't be stupid) elif len(self) n: self += [None] * (n - len(self)) else: self[n:] = [] self._length = n len = property(_getlength, _setlength) alist = MyList() alist.length = 1000 # safe This is hardly what messing with the internals is! If your idea of modifying hidden, implementation-specific details is use a safe getter/ setter implementation that holds your hand and protects you from doing anything stupid, then no wonder you object to data hiding. I'd object to it to, if that's what I understood by it. What I'm talking about is unsafe, direct access to the underlying C slots with no hand-holding. You know: messing with the internals with no nice safe interface between you and disaster: alist._length = 2**128 # unsafe! Safety is good. Escape hatches are good, too. Something we can agree on. In the second case, the next question is, why should it only be code written in C that is allowed that protection? Because Python code can't cause those sorts of problems without resorting to the escape hatches (e.g., ctypes). And, very significantly, because C code /needs/ that protection and Python basically doesn't. The basic difference is that C code is fundamentally brittle: if you mess up its invariants, it can crash horribly and possibly allow its brain to be taken over by evil people. Python code is fundamentally robust. The worst that can happen[1] is that the interpreter raises an exception. This makes it ideally suited to having a more relaxed attitude to life. And that, in turn, makes it approachable, hackable interactively, fun! No, it's not the worst that can happen. I find it amusing when novice programmers believe their main job is preventing programs from crashing. ... More experienced programmers realize that correct code is great, code that crashes could use improvement, but incorrect code that doesn't crash is a horrible nightmare. http://www.pphsg.org/cdsmith/types.html -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 23, 6:36 pm, Luis Zarrabeitia ky...@uh.cu wrote: Makes *no* sense? There's *no* good reason *at all* for the original author to hide or protect internals? My bad, sorry. It makes sense... if the original author is an egotist who believes he must control how I use that library. If the original author provides you with the source code and the right to modify it, he cannot possibly control how you use the library. You can trivially disable any access controls. But for some reason that's not enough for you. Has it occurred to you that some users might actually *want* access controls? Maybe some users want to actually use the library as the author intended it to be used. What a bizarre concept! Oh, but only a paranoid fool could possibly want access controls, eh? Who's the egotist here? -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Wed, 21 Jan 2009 01:02:37 -0800, Aaron Brady wrote: class Parrot: ... _private = 'spam' ... p = Parrot() p._private = 'ham' # allowed by default from protection import lock lock(p)._private p._private = 'spam' Traceback (most recent call last): File stdin, line 1, in module ProtectionError: attribute is read-only from outside of class Parrot Would that be so bad? I don't think so. Sorry, I didn't see the last part originally. I don't think 'outside of class Parrot' is well-defined in Python. Does '_private' have to be a member of 'Parrot', an instance of 'Parrot', or the calling instance of 'Parrot', before entering the calling scope, or at the time the call is made? Since many of these can change on the fly, there's more than one consistent interpretation to the syntax. This is a good point. Any hypothetical move to make Python (or a Python- like language) stricter about private/protected attributes would need to deal with that question. I don't have to worry about that until somebody writes a PEP :) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Wed, 21 Jan 2009 12:55:42 -0500, Luis Zarrabeitia wrote: Btw, the correctness of a program (on a turing-complete language) cannot be statically proven. Ask Turing about it. The correctness of *all* *arbitrary* programs cannot be proven. That doesn't mean that no programs can be proven. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Tim Rowe digi...@gmail.com writes: Programs done in Ada are, by objective measures, more reliable than those done in C and C++ (the very best released C++ programs are about as good as the worst released Ada programs), although I've always wondered how much of that is because of language differences and how much is because Ada tends to be used on critical projects that also tend to get a lot more attention to development standards. A reliability comparison between C++ and Java might shed light on that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steven D'Aprano a écrit : On Wed, 21 Jan 2009 12:54:31 +0100, Bruno Desthuilliers wrote: Russ P. a écrit : (snip) In any case, I have suggested that Python should perhaps get a new keyword, private or priv. And quite a few people - most of them using Python daily - answered they didn't wan't it. Then they don't have to use it. Yes they would. Because this would become the official way to tell what's interface and what's implementation, and *this* is the important point. Lots of people think that double-underscore name mangling is a waste of time: not strict enough to be useful, not open enough to be Pythonic. Solution? Don't use double-underscore names. The name-mangling mechanism is actually useful when you want to make sure some vital implementation attribute (usually of a class intented to be extended by the library users) won't be *accidentally* overwritten. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Paul Rubin a écrit : Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid writes: In my limited experience with Haskell (statically typed but very high level), dynamic and static were not meant to concern typing here (or at least not only typing). I'm not sure what you mean by those terms then. Python (and some other dynamic OOPLs) allow you to dynamically add / remove / replace attributes (inclunding methods), either on a per-instance or per-class (at least for class-based oned) basis. Haskell and MLs are indeed statically typed, but with a powerfull type inference system, which gives great support for genericity ot(hmmm... is that the appropriate word ?)/ot I think you mean polymorphism; Yeps. genericity in functional programming usually means compile time reflection about types. (It means something different in Java or Ada). Now these are functional languages, so the notion of access restriction is just moot in this context !-) I'm not sure what you mean by that; Haskell certainly supports access restrictions, through its type and module systems. Same word, somehow different context. What I meant was that since functional languages are (supposedly) stateless, there's no state to make private. But you're right to correct me wrt/ existing access restrictions in Haskell. Ok, I should probably have made clear I was thinking of a hi-level dynamic _imperative_ language vs a low-level static _imperative_ language. FP is quite another world. I'd say that Python's FP characteristics are an important part of its expressiveness. Indeed - but they do not make Python a functional language[1]. Python is based on objects, not on functions, and quite a lot of the support for functional programing in Python comes from the object system. Just look how functools.partial is implemented. Yes, it could have been implemented with a HOF and closures (and there have been such implementations), but using a class is still the most pythonic way here. [1] except for a very formal definition of functional language. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Btw, the correctness of a program (on a turing-complete language) cannot be statically proven. Ask Turing about it. For the most safety critical of programmes, for which static proof is required, restrictions are placed on the use of the language that effectively mean that it is not Turing-complete. Specifically, all loops that are required to terminate require a loop variant to be defined. Typically the loop variant is a finite non-negative integer that provably decreases on every pass of the loop, which makes halting decidable. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Thu, 22 Jan 2009 10:33:26 +0100, Bruno Desthuilliers wrote: Steven D'Aprano a écrit : On Wed, 21 Jan 2009 12:54:31 +0100, Bruno Desthuilliers wrote: Russ P. a écrit : (snip) In any case, I have suggested that Python should perhaps get a new keyword, private or priv. And quite a few people - most of them using Python daily - answered they didn't wan't it. Then they don't have to use it. Yes they would. Because this would become the official way to tell what's interface and what's implementation, and *this* is the important point. But if you have free access to attributes, then *everything* is interface. Lots of people think that double-underscore name mangling is a waste of time: not strict enough to be useful, not open enough to be Pythonic. Solution? Don't use double-underscore names. The name-mangling mechanism is actually useful when you want to make sure some vital implementation attribute (usually of a class intented to be extended by the library users) won't be *accidentally* overwritten. Except it doesn't. Take this simple module: # module.py class C(object): __n = 3 def spam(self): return spam * self.__n class D(C): pass # end module.py I have no interest in C; I may have no idea it even exists. It might be buried deep inside the inheritance hierarchy of the class I really want, D. So now I subclass D: from module import D class C(D): ... __n = 5 ... def ham(self): ... return I eat ham %d times a day % self.__n ... C().ham() 'I eat ham 5 times a day' assert C().spam() == D().spam() Traceback (most recent call last): File stdin, line 1, in module AssertionError And now I have accidentally broken the spam() method, due to a name clash. Besides, double-underscore names are a PITA to work with: class Parrot(object): ... __colour = 'blue' ... def __str__(self): ... return 'A %s parrot' % self.__colour ... __repr__ = __str__ ... class RedParrot(Parrot): # Just like Parrot, only red. ... __colour = 'red' ... Parrot() A blue parrot RedParrot() A blue parrot -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steven D'Aprano a écrit : On Thu, 22 Jan 2009 10:33:26 +0100, Bruno Desthuilliers wrote: Steven D'Aprano a écrit : On Wed, 21 Jan 2009 12:54:31 +0100, Bruno Desthuilliers wrote: Russ P. a écrit : (snip) In any case, I have suggested that Python should perhaps get a new keyword, private or priv. And quite a few people - most of them using Python daily - answered they didn't wan't it. Then they don't have to use it. Yes they would. Because this would become the official way to tell what's interface and what's implementation, and *this* is the important point. But if you have free access to attributes, then *everything* is interface. Nope. Lots of people think that double-underscore name mangling is a waste of time: not strict enough to be useful, not open enough to be Pythonic. Solution? Don't use double-underscore names. The name-mangling mechanism is actually useful when you want to make sure some vital implementation attribute (usually of a class intented to be extended by the library users) won't be *accidentally* overwritten. Except it doesn't. Except it works for all real-life code I've ever seen. (snip convoluted counter-example) Steven, sorry for being so pragmatic, but the fact is that, from experience (not only mine - I'm talking about thousands of man/year experience), it JustWork(tm). -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Paul Rubin http://phr...@nospam.invalid writes: Also, the application area matters. There is a difference between programming for one's own enjoyment or to do a personal task, and writing programs whose reliability or lack of it can affect other people's lives. I've never done any safety-critical programming but I do a fair amount of security-oriented Internet programming. I do quite a lot of that too. But I don't think it's necessary to have the kinds of static guarantees that a statically-typed language provides in order to write programs which are robust against attacks. Many actual attacks exploit the low-level nature and lack of safety of C (and related languages): array (e.g., buffer) overflows, integer overflows, etc. A language implementation can foil these attacks in one of two (obvious) ways. Firstly, by making them provably impossible -- which would lay proof obligations on the programmer to show that he never writes beyond the bounds of an array, or that arithmetic results are always within the prescribed bounds. (This doesn't seem practical for most programmers.) Secondly, by introducing runtime checks which cause the program to fail safely, either by signalling an exception or simply terminating, when these bad things happen. In the case of array overflows, many `safe' languages implement these runtime checks, and they now seem to be accepted as a good idea. The case of arithmetic errors seems less universal: Python and Lisp fail gracefully to unbounded integers when the machine's limits are exceeded; Java and C# silently give incorrect results[1]. Anyway, Python is exempt from these problems (assuming, at any rate, that the implementation is solid; but we've got to start somewhere). There's a more subtle strain of logical errors which can also be exploited. It's possible that type errors lead to exploitable weaknesses. I don't know of an example offhand, but it seems conceivable that a C program has a bug where an object of one type is passed to a function expecting an object of a different type (maybe due to variadic argument handling, use of `void *', or a superfluous typecast); the contents of this object cause the function to misbehave in a manner convenient to the adversary. In Python, objects have types, and primitive operations verify that they are operating on objects of suitable types, signalling errors as necessary; but higher level functions may simply assume (`duck typing') that the object conforms to a given protocol and expecting a failure if this assumption turns out to be false. It does seem possible that an adversary might arrange for a different object to be passed in, which seems to obey the same protocol but in fact misinterprets the messages. (For example, the function expects a cleaning object, and invokes ob.polish(cup) to make the cup become shiny; in fact, the object is a nationality detector, and returns whether the cup is Polish; the function proceeds with a dirty cup!) Static type systems can mitigate these sorts of `ugly duckling' attacks somewhat, but it's not possible to do so entirely. The object in question may in fact implement the protocol in question (implement the interface, in Java, or be an instance of an appropriate type-class in Haskell) but do so in an unexpected manner. And beyond these kinds of type vulnerabilities are other mistakes which are very unlikely to be caught by even a sophisticated type system; e.g., a function for accepting input to a random number generator, which actually ignores the caller's data! [1] Here, I don't mean to suggest that the truncating behaviour of Java or C# arithmetic can't be used intentionally. Rather, I mean that, in the absence of such an intention, arithmetic in these languages simply yields results which are inconsistent with the usual rules of integer arithmetic. Finally, your type-A / type-B comparison works best regarding programs written by one programmer or by a few programmers who communicate closely. Possibly; but I think that larger groups can cooperate reasonably within a particular style. I'm working on a Python program in conjunction with a bunch of people in widely dispersed time zones, so communication isn't so fluid, and when something changes it's not always easy to notice the change or understand the reason and deal with it. I'll agree that dynamic languages like Python require a degree of discipline to use effectively (despite the stereotype of type B as ill-disciplined hackers), and that includes communicating effectively with other developers about changes which might affect them. Statically typed languages provide a safety-net, but not always a complete one. One might argue that the static-typing safety-net can lead to complacency -- a risk compensation effect. (I don't have any evidence for this so I'm speculating rather than arguing. I'd be interested to know whether there's any research on the subject, though.) Even so, I don't
Re: Does Python really follow its philosophy of Readability counts?
On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote:
Steven D'Aprano a écrit :
On Thu, 22 Jan 2009 10:33:26 +0100, Bruno Desthuilliers wrote:
Steven D'Aprano a écrit :
On Wed, 21 Jan 2009 12:54:31 +0100, Bruno Desthuilliers wrote:
Russ P. a écrit :
(snip)
In any case, I have suggested that Python should perhaps get a new
keyword, private or priv.
And quite a few people - most of them using Python daily - answered
they didn't wan't it.
Then they don't have to use it.
Yes they would. Because this would become the official way to tell
what's interface and what's implementation, and *this* is the
important point.
But if you have free access to attributes, then *everything* is
interface.
Nope.
How could anyone fail to be convinced by an argument that detailed and
carefully reasoned?
Lots of people think that double-underscore name mangling is a waste
of time: not strict enough to be useful, not open enough to be
Pythonic. Solution? Don't use double-underscore names.
The name-mangling mechanism is actually useful when you want to make
sure some vital implementation attribute (usually of a class intented
to be extended by the library users) won't be *accidentally*
overwritten.
Except it doesn't.
Except it works for all real-life code I've ever seen.
(snip convoluted counter-example)
Convoluted? It was subclassing from a class that itself was a subclass.
This happens very frequently. The only thing that was a tiny bit unusual
was a conjunction of two accidental name clashes: the subclass happened
to accidentally have the same name as one of the superclasses, and both
of them happened to have a double-underscore attribute.
Steven, sorry for being so pragmatic, but the fact is that, from
experience (not only mine - I'm talking about thousands of man/year
experience), it JustWork(tm).
Double-underscore names are great for preventing name clashes, until it
doesn't.
This isn't something new. Others have pointed out this failure mode,
including the Timbot:
http://mail.python.org/pipermail/python-dev/2005-December/058563.html
I think the attitude towards __names illustrates a huge gulf between two
ways of programming. One school of thought tries to write programs that
can't fail, and considers failure modes to be bugs to be fixed. The other
school of thought tries to write programs that won't fail until something
unusual or unexpected happens, and behaves as if the answer to failure
modes is if the function breaks when you do that, then don't do that.
Name mangling belongs in the second category.
The Python standard library has a split personality in that the parts of
it written in C are written so they can't fail, as much as humanly
possible. Good luck trying to get list.append() to unexpectedly fail. But
the parts written in Python are built to a much lower standard. Look how
easy it is to create an object with a ticking time bomb waiting to go off
at some later date:
from ConfigParser import ConfigParser
config = ConfigParser({'a':1})
You've successfully created a ConfigParser object. You'd expect it should
be safe to work with now: you haven't messed with any internals or done
anything strange, you've just given it a default value. But then, much
later:
config.get('DEFAULT', 'a') # or any section without option 'a'
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/local/lib/python2.6/ConfigParser.py, line 545, in get
return self._interpolate(section, option, value, d)
File /usr/local/lib/python2.6/ConfigParser.py, line 585, in
_interpolate
if %( in value:
TypeError: argument of type 'int' is not iterable
In stricter languages, particularly code with static type checking, the
attitude is you must only provide input that meets these pre-
conditions. (Often one pre-condition will be the argument type.) But in
Python, the attitude is you can provide any input you like, but if it
fails, don't blame me.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote:
Steven D'Aprano a écrit :
But if you have free access to attributes, then *everything* is
interface.
Nope.
How could anyone fail to be convinced by an argument that detailed and
carefully reasoned?
Well, your claim /was/ just wrong. But if you want to play dumb: the
interface is what's documented as being the interface.
You can tell that your claim is simply wrong by pushing it the other
way. If everything you have free access to is interface then all
behaviour observable by messing with the things you have access to is
fair game: you can rely on cmp returning one of {-1, 0, 1} on integer
arguments, for example.
But no: the Library Reference says only that it returns a negative, zero
or positive integer, and /that/ defines the interface. Everything else
is idiosyncrasy of the implementation, allowed to change at whim.
from ConfigParser import ConfigParser
config = ConfigParser({'a':1})
[...]
File /usr/local/lib/python2.6/ConfigParser.py, line 585, in
_interpolate
if %( in value:
TypeError: argument of type 'int' is not iterable
I'd say that this is a bug. The Library Reference says (9.2):
: `ConfigParser([defaults])'
: Derived class of `RawConfigParser' that implements the magical
: interpolation feature and adds optional arguments to the `get()'
: and `items()' methods. The values in DEFAULTS must be
: appropriate for the `%()s' string interpolation. Note that
: __NAME__ is an intrinsic default; its value is the section name,
: and will override any value provided in DEFAULTS.
The value 1 is certainly appropriate for `%()s' interpolation:
In [5]: '%(foo)s' % {'foo': 1}
Out[5]: '1'
so you've satisfied the documented preconditions.
In stricter languages, particularly code with static type checking,
the attitude is you must only provide input that meets these pre-
conditions.
You did that. It failed anyway. Therefore it's broken. Report a bug.
-- [mdw]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Tim Rowe wrote: Btw, the correctness of a program (on a turing-complete language) cannot be statically proven. Ask Turing about it. For the most safety critical of programmes, for which static proof is required, restrictions are placed on the use of the language that effectively mean that it is not Turing-complete. Specifically, all loops that are required to terminate require a loop variant to be defined. Typically the loop variant is a finite non-negative integer that provably decreases on every pass of the loop, which makes halting decidable. Having once been a more type-A, I labored for a couple of years trying to build a restricted language that provably terminated for work on an object-oriented database research. I finally gave it up as a bad idea, because, in practice, we don't care if a loop will terminate or not in database work; a transaction that takes a year to commit is equivalent to an infinite loop for all applications that I have interacted with (and yes, I have worked allowing four day transactions to commit). --Scott David Daniels scott.dani...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid writes: Paul Rubin a écrit : I'd say that Python's FP characteristics are an important part of its expressiveness. Indeed - but they do not make Python a functional language[1]. Python is based on objects, not on functions, I'd have a good go at defining a functional language as one which treats functions as first-class objects -- i.e., can be passed as arguments, returned as results, stored in data structures, etc. In that regard, Python is a proper paid-up functional programming language. It's not a /pure/ language -- i.e., there are side effects -- but ML has those too and it's widely considered functional; and it's not lazily evaluated -- but again neither is ML. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Thursday 22 January 2009 08:32:51 am Steven D'Aprano wrote: And now I have accidentally broken the spam() method, due to a name clash. True, that's bad. I wish that were 'fixed'. Besides, double-underscore names are a PITA to work with: Isn't that example the point of having self.__private variables? To make sure that the Parrot.__private attributes don't clash with the RedParrot.__private attributes with the same name? [parrot example follows just for context, but my reply ends here] class Parrot(object): ... __colour = 'blue' ... def __str__(self): ... return 'A %s parrot' % self.__colour ... __repr__ = __str__ ... class RedParrot(Parrot): # Just like Parrot, only red. ... __colour = 'red' ... Parrot() A blue parrot RedParrot() A blue parrot -- Luis Zarrabeitia (aka Kyrie) Fac. de Matemática y Computación, UH. http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Paul Rubin wrote: Mark Wooding m...@distorted.org.uk writes: Some people (let's call them `type A programmers') have decided that they want to be assisted with writing correct programs... Other people (`type B programmers') don't like having their (apparently? possibly?) correct programs rejected I think trying to persuade a type A programmer that he wants to work like a type B programmer, or /vice versa/, is difficult, bordering on futile. Type A stereotypes type B as a bunch of ill-disciplined reckless hackers; type B stereotypes type A as killjoy disciplinarians. Meeting in the middle is difficult. (`We just want to add a little safety.' `You want to take away our freedom!' Etc., /ad nauseam/.) That's an interesting analysis. You know, I think I'm really a type B programmer, interested in type A techniques and tools for the same reason someone who naturally sleeps late is interested in extra-loud alarm clocks. Also, the application area matters. There is a difference between programming for one's own enjoyment or to do a personal task, and writing programs whose reliability or lack of it can affect other people's lives. I've never done any safety-critical programming but I do a fair amount of security-oriented Internet programming. As such, I have to always assume that my programs will be attacked by people who are smarter than I am and know more than I do. I can't possibly out-think them. If I don't see problems in a program, it's still plausible that someone smarter than me will spot something I missed. Therefore, my failure to detect the presence of problems is not reassuring. What I want is means of verifying the absence of problems. M. your means of verifying the absence of problems were coded/thought by some other person who also has a measurable amount of intelligence. So it follows that there will be somebody else who is smarter and will spot something this other person missed and will be able to subvert those means. So it would seem that by thinking you can verify the absence of problems you are trying to get a false sense of security that actually does not exist. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Scott David Daniels scott.dani...@acm.org writes: Having once been a more type-A, I labored for a couple of years trying to build a restricted language that provably terminated for work on an object-oriented database research. I finally gave it up as a bad idea, because, in practice, we don't care if a loop will terminate or not in database work; a transaction that takes a year to commit is equivalent to an infinite loop for all applications that I have interacted with (and yes, I have worked allowing four day transactions to commit). I think the purpose of the termination proofs is to ensure that nonterminating functions don't introduce inconsistency into the verification logic, rather than out of concern that some function might actually loop. Consider the function def f(x): return 1 + f(x) aside from the minor issue of infinite recursion, this is a nice, well-typed function that doesn't have any side effects, doesn't raise exceptions, etc. It is referentially transparent, so one can substitute any call to it with the value from another call to the same arg, i.e. we can substitute x=3 and deduce the equation f(3) = 1 + f(3) Subtracting f(3) from each side, we get 0 = 1, an erroneous theorem from which the verification system can infer all kinds of other bogus results. By requiring proof that any function purporting to return a value really DOES return a value (rather than looping, raising an exception, etc.), we get rid of this problem. The actual number of computing steps before termination isn't an issue for this purpose, as long as it is finite. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Thu, 22 Jan 2009 19:10:05 +, Mark Wooding wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote:
Steven D'Aprano a écrit :
But if you have free access to attributes, then *everything* is
interface.
Nope.
How could anyone fail to be convinced by an argument that detailed and
carefully reasoned?
Well, your claim /was/ just wrong. But if you want to play dumb: the
interface is what's documented as being the interface.
But you miss my point.
We're told Python doesn't have private attributes. We're told that we're
allowed to mess with the internals, we're *encouraged* to do so: Python
gives you the freedom to do so, and any suggestion that freedom might be
reduced even a tiny bit is fought passionately. When people ask how to
implement private attributes, they're often told not to bother even using
single-underscore names. When it is suggested that Python should become
stricter, with enforced data hiding, the objections come thick and fast:
people vehemently say that they like Python just the way it is, that they
want the ability to mess with the internals.
You even argued that you disliked data structures implemented in C and
preferred those written in Python because you have more ability to mess
with the private attributes. In context, I had just mentioned that lists'
internals were inaccessible from Python code. I neglected to give an
example at the time, but a good example is the current length of the
list. Consider the experience of Microsoft and Apple. No matter how often
they tell people not to mess with the internals, people do it anyway, and
always believe that their reason is a good reason.
And Python culture encourages that behaviour (albeit the consequences are
milder: no buffer overflows or core dumps).
Add to that the culture of Open Source that encourages reading the source
code. You don't need to buy a book called Undocumented Tips and Tricks
for Python to discover the internals. You just need to read the source
code.
And then you have at least two places in the standard library where
_attributes are *explicitly* public:
http://bugs.python.org/issue3152
Given this permissive culture, any responsible library writer must assume
that if he changes his so-called private attributes, he will break
other people's code. In principle it could break just as much code as if
he didn't even bother flagging them with a leading underscore, which is
probably why many people don't even bother with _names.
In other words, if you make it easy for people to mess with your
internals, if you have a culture that allows and even encourages them to
mess with your internals, then you don't have internals. Everything is de
facto public.
You can tell that your claim is simply wrong by pushing it the other
way. If everything you have free access to is interface then all
behaviour observable by messing with the things you have access to is
fair game: you can rely on cmp returning one of {-1, 0, 1} on integer
arguments, for example.
But no: the Library Reference says only that it returns a negative, zero
or positive integer, and /that/ defines the interface. Everything else
is idiosyncrasy of the implementation, allowed to change at whim.
And yet people still assume that cmp returns -1, 0 or 1. Even Guido
himself makes that mistake occasionally. Quoting from PEP 285:
...you might be tempted to believe that cmp() also returned a
truth value, whereas in reality it can return three different values
(-1, 0, 1).
http://www.python.org/dev/peps/pep-0285/
No, cmp() can return an infinite number of values. It just never does, at
least not yet, but it might. But when Guido himself says that cmp() can
return three values, can you blame people for acting as if cmp() can
return three values?
Here's a thought experiment for you. You've suggested that the values
returned by cmp() are allowed to change at whim. Okay, let's do it:
make a patch that changes cmp() to return -17, 0 or 53, and promise to
support it for at least three years. Try to get it accepted on python-
dev. What do you expect they will say?
My money is on them saying No, this will pointlessly break code for no
good reason. Rejected.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
Steven D'Aprano wrote: Here's a thought experiment for you. You've suggested that the values returned by cmp() are allowed to change at whim. Okay, let's do it: make a patch that changes cmp() to return -17, 0 or 53, and promise to support it for at least three years. Try to get it accepted on python- dev. What do you expect they will say? My money is on them saying No, this will pointlessly break code for no good reason. Rejected. I have occasionally thought that things documented to possibly change *should* be changed just to expose the *bug* of depending on them not changing. Or maybe, the doc should be changed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of Readability counts?
On Jan 22, 6:30 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Thu, 22 Jan 2009 19:10:05 +, Mark Wooding wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote:
Steven D'Aprano a écrit :
But if you have free access to attributes, then *everything* is
interface.
Nope.
How could anyone fail to be convinced by an argument that detailed and
carefully reasoned?
Well, your claim /was/ just wrong. But if you want to play dumb: the
interface is what's documented as being the interface.
But you miss my point.
We're told Python doesn't have private attributes. We're told that we're
allowed to mess with the internals, we're *encouraged* to do so: Python
gives you the freedom to do so, and any suggestion that freedom might be
reduced even a tiny bit is fought passionately. When people ask how to
implement private attributes, they're often told not to bother even using
single-underscore names. When it is suggested that Python should become
stricter, with enforced data hiding, the objections come thick and fast:
people vehemently say that they like Python just the way it is, that they
want the ability to mess with the internals.
You even argued that you disliked data structures implemented in C and
preferred those written in Python because you have more ability to mess
with the private attributes. In context, I had just mentioned that lists'
internals were inaccessible from Python code. I neglected to give an
example at the time, but a good example is the current length of the
list. Consider the experience of Microsoft and Apple. No matter how often
they tell people not to mess with the internals, people do it anyway, and
always believe that their reason is a good reason.
And Python culture encourages that behaviour (albeit the consequences are
milder: no buffer overflows or core dumps).
Add to that the culture of Open Source that encourages reading the source
code. You don't need to buy a book called Undocumented Tips and Tricks
for Python to discover the internals. You just need to read the source
code.
And then you have at least two places in the standard library where
_attributes are *explicitly* public:
http://bugs.python.org/issue3152
Given this permissive culture, any responsible library writer must assume
that if he changes his so-called private attributes, he will break
other people's code. In principle it could break just as much code as if
he didn't even bother flagging them with a leading underscore, which is
probably why many people don't even bother with _names.
In other words, if you make it easy for people to mess with your
internals, if you have a culture that allows and even encourages them to
mess with your internals, then you don't have internals. Everything is de
facto public.
You can tell that your claim is simply wrong by pushing it the other
way. If everything you have free access to is interface then all
behaviour observable by messing with the things you have access to is
fair game: you can rely on cmp returning one of {-1, 0, 1} on integer
arguments, for example.
But no: the Library Reference says only that it returns a negative, zero
or positive integer, and /that/ defines the interface. Everything else
is idiosyncrasy of the implementation, allowed to change at whim.
And yet people still assume that cmp returns -1, 0 or 1. Even Guido
himself makes that mistake occasionally. Quoting from PEP 285:
...you might be tempted to believe that cmp() also returned a
truth value, whereas in reality it can return three different values
(-1, 0, 1).
http://www.python.org/dev/peps/pep-0285/
No, cmp() can return an infinite number of values. It just never does, at
least not yet, but it might. But when Guido himself says that cmp() can
return three values, can you blame people for acting as if cmp() can
return three values?
Here's a thought experiment for you. You've suggested that the values
returned by cmp() are allowed to change at whim. Okay, let's do it:
make a patch that changes cmp() to return -17, 0 or 53, and promise to
support it for at least three years. Try to get it accepted on python-
dev. What do you expect they will say?
My money is on them saying No, this will pointlessly break code for no
good reason. Rejected.
--
Steven
Needless to say, I agree with your post.
My understanding is that the vast majority of Python software is
provided as open source. Hence, I am a bit confused by all the talk
about the need for freedom and openness in Python. If data hiding were
enforced, and you need access to something marked as private, you can
just change it to public in the source code. What's the problem?
Note: that change would be much easier to make if a private (or
perhaps priv) keyword were used instead of the leading-underscore
rule. The former would require a change in only one
