On Wednesday 29 May 2002 02:35 pm, Fredrik Lundh wrote: > Steven Lott wrote: > > The true majority are the "yet to start" users, for whom the > > String class will be the only thing they ever use; irrespective > > of the deprecation state of string. > > you mean we should burn all existing python books, and > start over from scratch? All author of Python books should heartily second this recommendation -- unless the book is right in the sweet spot of its lifecycle curve, where it's selling well without needing any edits and updates, of course (so, please let's do it AT ONCE, before the Cookbook and Nutshell come out, or better wait a hopefully long while for their sales to get on a downward slope). After all, in terms of editing work, moving any reference to the string module to an appendix on "old deprecated stuff that you only need to know when migrating old code to new Python releases" is pretty modest, and yet it will let us make "new importantly updated editions" and sell a bunch more to suck^H^H^H^H discerning book buyers who _know_ they must always have fully updated tomes. Then when THAT sales boost has died down, we can make another killing by introducing, say, a boolean type with two constants True and False that act just about the same as 1 and 0 but also let us make another crucially updated edition (with a gain in readability for our prose, too). Hmmm, maybe _this_ one is a bit too obvious as a ploy to sell new updated editions. But I'm sure we can come up with something. Seriously for a sec: I'd _love_ not to have to explain why most but not all string methods are ALSO in a string module without making it sound as if Python's so encrusted with "needless but backwards-compatible cruft" to make it a match for C++ -- which it isn't, by a long shot, but that ain't easy to communicate. On the other hand, using False and True in explanations instead of 0 and 1 _does_ enhance prose readability -- interesting side effect I guess:-). I'd just love it if old cruft could be removed, but each time that is mooted, there's an uproar. So I guess we just have to live with a slow accumulation of "more than one way to do it" (at least until the mythical will-never-come backwards-incompatible Python 3000, of course) despite the obvious costs (each time two coders get used to different idioms for the same task, they will have a slightly harder time maintaining each other's code). The costs always look small (for each single issue -- there are many small things...), and are spread over time; the benefits always appear more obvious (don't break MY code, let me keep some backwards compatibility with 1.5.2, let me keep my own habits...) and immediate. So, no matter what the actual value of the cruft-removing proposal might be, the uproar against it is inevitably loud, and cruft stays and keeps piling up. Languages always grow, never shrink. I love it when Python manages to do otherwise once in a while (e.g., xrange's cleanup), but I doubt it can happen often enough to make a difference. Oh well. Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4