Peter Maas wrote: > Bruno Desthuilliers schrieb: > > Marc 'BlackJack' Rintsch wrote: > > (snip) > > Python itself is a RAD tool. > > > > +1 QOTW > > No, please stop self-assuring, self-pleasing QOTWs!
+1 QOTW! ;-) [Java, Ruby, JRuby, the hype] > To prevent this to happen parts of the Python community should have a > more critical attitude to the language. Too often I hear the same > mantras being repeated over and over again (GIL, self, IDE etc.). People who bring up stuff about self and indentation are just showing their ignorance, in my opinion, since Python isn't the first language to use self in such a way, and many C++ and Java programs use this pervasively in order to make attribute scope explicit, whereas the indentation matter is only troublesome with bad editing practices. I don't think the community should spend any more time on these criticisms. However, the GIL and issues of tools and IDEs should be considered in a more sophisticated way. I'm not advocating the removal of the GIL, but there needs to be a better story for people wanting to use more than one core or CPU within a single program on a multicore/multiprocessor system. My contribution in that field has been the pprocess module [1] which lets you play in a sort of multithreaded environment, although you're actually using multiple processes whose globals are only shared in a read-only sense, and the way forward may be to make this available to Windows users by adding an os.fork implementation for them to the standard library, as I suggested previously [2]. Meanwhile, whilst not an IDE advocate myself, there really does need to be further improvements in the analysis of Python source code so that people can build improved tools to check Python programs for obvious "compile-time" errors and to inspect the behaviour of large amounts of code. One reads occasionally on the python-dev or python-3000 mailing lists that some proposed change or other may or may not have an impact on "real world" systems such as the standard library, but that no-one can really say: we need to move beyond the "Python is just so dynamic" meme and develop tools like PyLint and PyChecker much further. > I don't say these mantras are all wrong but perhaps it would be good to > remove the GIL just to stop people talking about Python's lack of > multi-threading or polish Python's class syntax to stop people talking > about Python's OO being bolted on etc. Programmers often choose their > languages by very silly reasoning (silliest being the indentation issue) > and maybe we should take the silliness into account instead of laughing > about those silly folks. This kind of stuff can be tackled by providing better introductory, educational or promotional material, with the latter especially important to stop the uninformed "rubbishing" that advocates of certain other languages seem particularly inclined to indulge in. > I for my part would be happy to see a Delphi-like RAD tool for Python, > a reference implementation for web programming as part of the standard > library, Jython 2.5, Python for PHP or whatever attracts new programmers. As I noted in the "Python component model" thread [3], tools like Qt Designer seem to go a long way towards providing RAD-like solutions, even though they aren't "pure Python". Meanwhile, the Web programming standardisation scene remains stagnant. Sure, you can pretend that WSGI middleware is the future, and even I can see that layering components is an acceptable way of building Web applications, but I'm not using WSGI to do that because the whole exercise requires multiple trips to the Web technology supermarket (once for a server, again for a server adapter, again for stuff to make the WSGI API bearable, and so on, repeat when you find one or more components to be immature) and I doubt that people shopping around for an easy way to write applications are especially convinced either. But I largely agree with what you've written, and the cause of the symptoms is the excessive focus on changing the language rather than improving the libraries, the tools and the peripheral elements of the development experience. If you think the standard library is incoherent, jump into the proposal I've been writing [4] to suggest improvements and to help out, because this kind of work isn't going to happen otherwise, unfortunately. Returning to the lack of Python books, it's rather telling that a review of "Python in a Nutshell" that just caught my eye says the following: "Considering that the Zen of Python is barely being followed as the core language has feature upon feature heaped upon it, a book like this helps poor programmers simply wanting to use the language keep up with the changes." I know that certain other languages aren't exactly unchanging (and may possibly undergo further upheaval), and that publishers like having more books to sell on the very same topic, but after a while both authors and readers become tired of having to respectively write/update or buy new books because of relentless and seemingly frivolous changes to a language or technology. Paul [1] http://www.python.org/pypi/parallel [2] http://groups.google.com/group/comp.lang.python/msg/c6d8f8aa2cfb8562 [3] http://groups.google.com/group/comp.lang.python/msg/f678b500493a38f1 [4] http://wiki.python.org/moin/CodingProjectIdeas/StandardLibrary/RestructuredStandardLibrary -- http://mail.python.org/mailman/listinfo/python-list