On 06/07/10 20:18, Adam Tauno Williams wrote: > On Mon, 2010-06-07 at 13:19 +1000, Lie Ryan wrote: >> On 06/07/10 12:18, Adam Tauno Williams wrote: >>> But then I don't know any of the local Python devs who use IDLE; the >>> IDE landscape for Python is very fragmented, which disincentives that >>> happening. >> I don't use IDLE either, but IDLE comes by default with standard >> distribution of python. >>>>>> .NET/C# has had preferred GUI APIs come and go and isn't exactly what >>>>>> I'd call crossplatform, >>>>> Well, if you use Gtk# for your GUI it is probably one of the [if not >>>>> "the"] most cross-platform development solution for complex fat-clients. >>>>>> Looking at the state of other languages and their GUI toolkit >>>>>> landscape, someone might even come to the conclusion that having one >>>>>> true GUI toolkit is potentially a bad thing for a language. >>>>> +1 In the end the relationships with GUI toolkits is far more about >>>>> tool-chain and documentation then it is about language. If there was an >>>>> awesome IDE that allowed RAD [of real complex applications] in toolkit X >>>>> then people will use toolkit X. [Monodevelop and it's awesome Gtk# >>>>> support for Mono/.NET is a good example; the tool makes the toolkit >>>>> east to use - people go with the toolkit]. >>>> The problem with the current GUI toolkits is their API is designed to be >>>> cross-language (i18n). I'd say, keep the current GUI toolkits, make >>>> their API easier to use (l10n). >>> Which is 'just' an implementation detail. >> Why is a GUI toolkit *API* an *implementation detail*? > > You are missing the point. PyQt, PyGtk, etc.. are wrappers/bindings > around Qt, Gtk, etc... respectively. So it *is* an implementation > detail of the wrapper/binding to make the API 'pythonic'. Changing > class names, rewriting method signatures, adding glue - is a binding > issue.
binding is part of the programmer-facing API, therefore it's not an implementation detail. >> They seems to be >> contradictory to me. The simplicity and ease of use of a library depends >> on how well-designed their API is, > > Yea. Which is an implementation detail. > >> and how "pythonic" the API appears to >> a python programmer (unittest, for example, looks more Java-ish than >> pythonic). > > So... improve the binding. That is a really silly reason to develop a > new toolkit. isn't that my whole point? -- http://mail.python.org/mailman/listinfo/python-list