On 7 Sep, 06:19, Kay Schluehr <[EMAIL PROTECTED]> wrote: > On Sep 6, 12:56 pm, Paul Boddie <[EMAIL PROTECTED]> wrote: > > > I think there's been a widespread "kitchen sink" mentality around the > > Python language for some time, which is where the multimethods > > proposal, amongst others, fits in here. > > Maybe that's one of two fixed points in the evolution of a programming > language? The other one might be an almost non-designed and small > language with a vast and flat library a la PHP and Zend. Apparently > even Scheme moves into the kitchen sink today with the new R6RS > specification.
My impression of PHP (before version 5), derived from anecdotes and general criticism, is that both the language and the most promoted libraries have accumulated features without much regard to how the end- user experience works out. In contrast, it is said that Python has been improved with more attention to the end-user experience (albeit with limitations related to the main implementation and backwards compatibility), with Python 3000 being the pinnacle of this user- centric process. Regardless of whether Python 3000 really tidies up the experience, it is notable that the promotional value of the standard library has diminished, perhaps because the core developers no longer feel that the language attracts embarrassing criticism which is best answered by deflecting the critic to standard library solutions. > Python is going to be the-right-thing with abandoning the print > statement or making lists a bit more monotyped with a type aware sort. > The worse-is-better philosophy on the other hand is indifferent > towards stylistic consistency and equipped with less nominalistic > pedantry ( "this is a list and therefore you only have to use it as a > list and not as a multiset..." ). I think you've swum into the philosophical "deep end" on this point. ;-) But of the different articles on the PythonWarts page I mentioned, Mertz's criticisms (which include notes on sorting heterogeneous collections) are certainly worth reading, partly because they do highlight awkward-to-address end-user expectations whilst being fairly modern criticisms. That's not to say that I agree with everything he writes, although I have some sympathy with his opinions on iterators vs. sequences and the current level of convenience in this area. > This explains also the lack of interest into the std library which > will be reduced to CPython services and basic datatypes. But there are > also organizational issues and I don't even think that a lib that > provides applications and domain specific services has to be > necessarily maintained and approved by python-dev. I'd go even further > and contend that's one of the issues where a rather large community > such as Pythons could grow up and set code review standards ( and I > mean *manual* code reviews of conscientous readers. I don't mean > cheesecake or up(down)moddings in Web 2.0 style, implementing the > "wisdom of the crowd" ). I can even live with Eggs and a not-so-common > code base but not with low quality. Once upon a time I wrote some thoughts down about marketing Python where one considers a number of things as the "product" or "solution". Certainly, in earlier times, adding stuff to the standard library was a way of positioning Python as a solution to problems in particular domains: if you needed to write a mail client, for example, Python provided a working solution as standard that would potentially be enough to persuade people to use Python for such a project. The belief that modules should be included in the standard library is a continuation of this "positioning" or advocacy-related sentiment, as well as being an issue of convenience, of course. As technical issues start to encourage other models for providing solutions based on Python, one has to consider the social aspects of such models. Where something in the standard library should have an implicit stamp of approval, although opinions are divided on whether some modules deserve their place, other models need to support notions of approval, credibility, quality, and so on. And there we have different approaches: repositories (optionally with rankings, noticing that Ubuntu seems to be adding support for such things), megaframeworks (where people effectively recommend a combination of solutions), "heavy" distributions (with a selection of popular packages in an enlarged standard library). In my opinion, such wider work on promoting Python's usability is possibly more beneficial to both potential and existing elements of the community than merely polishing the language and hoping that people are motivated to write great code because of the increased elegance. Paul -- http://mail.python.org/mailman/listinfo/python-list
