Yes. Seriously. As these tools evolve, there is much that is new and good and much that is old that should be (gracefully) deprecated for a few years and then retired. Some modules are interesting only for backward compatibility. Also, the organization of modules in the LIB manual makes very little sense to new users. Clearly, this organization evolved organically with the language, but perhaps it is time to refactor that module tree. Reaching back a few decades - I read in my history books that the Algol 68 effort fragmented into a flame war after the very successful Algol 60 effort. The flame war lead to three parallel efforts that eventually gave us Algol 68 (any users?), PL/1 and Pascal. Which had the biggest user base? I think it was Pascal, the one that went for the fewest-best features. (Or possibly it was the French mathematician after whom it was named, hard to say for sure.) I do not suggest that Python usage will fragment; rather I suggest that a focus on a few important features is the most beneficial. --- 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?

</F>

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

===== -- S. Lott, CCP :-{) S_LOTT@YAHOO.COM http://www.mindspring.com/~slott1 Buccaneer #468: KaDiMa Macintosh user: drinking upstream from the herd. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

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

The one difference is that <> is favored by some people close to Guido's heart. He'd never piss off his brother or his sysadmin. :)

But in Python 3, only != will be supported. Fortunately, it's a simple mechanical translation to fix this. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, May 29, 2002 at 11:16:55AM -0400, Raymond Hettinger wrote:

Premise 1:

...

...

The one difference is that <> is favored by some people close to Guido's heart. He'd never piss off his brother or his sysadmin. :)

Premise 2:

...

But in Python 3, only != will be supported.

Conclusion: Python 3 will never happen.

Agree :) I don't understand what is wrong with <> syntax. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

On Wed, May 29, 2002 at 11:28:02AM -0400, Guido van Rossum wrote:

Even people who are used to <> can learn to type !=.

Then why not the other way? :) Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

From: "Peter Funk"

nnorwitz just fixed a >>> dir(__builtin__) screen shot in the Python tutorial to add 'PendingDeprecationWarning' there.

I built a patch to fill the tp_iter slot for lists. Right away, the regression test test_descrtut.py failed because __iter__ showed up on the dir(list) example. I think everytime we use a dir() example in the docs or in the testsuite, we're creating unnecessary dependencies. It's not a big deal, but if the example or test can make its point without the dir(), it would lower the PITA factor. Raymond Hettinger

...

...

...

...

"OB" == Oleg Broytmann writes:

OB> Agree :) I don't understand what is wrong with <> syntax. It's an anti-Timbot measure. He'll be forced to retire when he has to write !wink= :) -Barry