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 point. What you are fussing about are > fundamental design choices (and philosophic points) that are well known, > explained, advertized, etc. - and are really not likely to change > anytime soon. No, probably not. Any such changes would have to start off as an external tool first. I'd guess that it couldn't even be considered as part of the base language until Python 4, which is probably a decade away. This is a good thing. There are, as you have so often pointed out, many B&D languages out there, and they are a PITA to use. Nobody wants to make Python unpleasant to use, but if you think data hiding is automatically unpleasant, then you must *hate* calling len() on a list, because that uses private data inaccessible to Python code. That's data hiding. It will probably take a decade of experiments to find a way to get as many of the benefits of data hiding as possible with as few of the costs as we can get away with. It may even be that it is impossible to do so, that you can't get the safety of data hiding without the pain. Who knows? I think it's an experiment worth trying. And for all those who insist that Python will never have data hiding except by convention, a few years ago I was saying that Python would never have static types, because of fundamental design choices to make Python a dynamic typed language. And now Python has ABCs, and optional type annotations, and Guido is encouraging people to experiment with tools that do things with those type annotations, things like type inference, and if they become popular and useful, they may end up in the language itself. As has been frequently pointed out, Python is not Java. Java is obsessed with the past, while Python is forward-looking. http://cafe.elharo.com/programming/java-is-dead-long-live-python/ Thank goodness for that. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
