Re: [Python-3000] What do do about IDLE?
Ronald Oussoren wrote: > On 8-mei-2006, at 4:07, Bill Janssen wrote: > > > > Much as we might like to think otherwise, there's no standard GUI in > > the Python core, and IDLE (or anything else that depends on it) won't > > work in some cases where it should work. > > Yes there is. Some distributors are lame enough to think they know > better and ship parts of the standard library seperately, but that's not a > valid reason for removing parts of the stdlib. Well, Tk is available on the "big three" (Windows, Mac, UNIX), but if you venture onto other platforms, don't expect to find it there. People may argue that the "big three" are all that matter, but that argument usually ends up with the "big two" and then total incoherence: eg. "this works on the Windows and Mac, whereas this works on Windows and UNIX"; something that has gradually (and thankfully) been eradicated over the past few years in parts of the standard library. Paul P.S. I thought Python 3000 had quite a lot to say on the tidying up of the standard library, or is it now the case that everyone wants to make language changes instead? ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] back with more GUI planning in a few days...
Talin wrote: > > There are two reasons why I think that bundling a GUI library with > Python is a good idea: > > -- It makes it possible to include GUI-based tools and applications > in the base distribution. I agree with this, although how ambitious are such tools? If you're just popping a dialogue asking for user input, there are typically other means of doing that without bringing in a whole GUI framework. > -- By reducing the dependency on downloading and installing > a UI framework, it lowers the friction for developing small, one-off > UI tools. This is not so much an issue with large apps, since the > cost of choosing and installing the optimal UI package is small > compared to the development cost of the project. But for small > tools (for example, a configuration control panel), the extra step > of installing a UI framework may be significant. I think the reduced friction is less about the installation and a lot more to do with which API you use: this being a point that the Web frameworks debate still hasn't caught up with. In other words, given that whichever toolkit is likely to be a click-install away, you're likely to be spending more time looking up how to write the GUI code, and a standard in this domain hopefully makes such work a lot more obvious. Scaling a standard up to complicated, integrated applications is a mostly unsolved problem, though. > However, there are some significant obstacles to be overcome before > this can happen. > > First, there's no such thing as a "simple" UI toolkit. Certainly, some > toolkits are simpler than others. But as I have argued before, UIs are > a language, and that language has evolved over time, to the point > where it has a rich vocabulary of appearances and behaviors. True. And the more complicated applications become, the more likely it is that you'll want to consider other things, such as the environment in which the applications operate. Opening a special toolkit file chooser dialogue may be acceptable for some kinds of applications, but together with other "platform agnostic" features it can also provide a huge disincentive to use those applications. (Personally, I dislike the Gtk+ and GNOME file choosers, partly because they have been ruined by usability "experts" with nostalgia for NeXTStep, but I really dislike them when they pop up in KDE, especially since KDE applications and the environment generally provide better solutions.) In fact, this topic conveniently highlights an issue I see with the way this and other topics are approached by parts of the Python community. In this community, the attitude to something like cross-platform user interfaces often involves glossing over the diversity of actual environments in favour of having something that does the job passably, often manifesting itself in some people's interpretation of what support for Linux or UNIX actually is: "Gtk+ support covers Linux, right?" Unfortunately, despite noise from various desktop environment proponents, the real world is a lot more complicated and a lot more interesting; neglecting this reality causes the kind of frustration and disenchantment described above. People in this community often used to point at Java and claim how isolationist the technology was (and largely still is), how Java user interfaces were so unlike the environments they run in, how Java has so many poor abstractions for system functionality that get in the way, and how Python seems to encourage cooperation and integration with the environment. However, parts of the Python community seem to behave like Java technology: preferring to abstract away diversity, isolating "Pythonic" solutions from the outside world, looking inside itself for solutions to problems that others have already solved. Indeed, the wider Python community should be more aware and more willing to work with other communities. For example, Python already works well with both KDE and GNOME, and there is an increasing (if arguably belated) interest in dynamic languages in the communities around those environments. Instead of pretending that Python somehow doesn't need those technologies to be successful or important (perhaps related to the sentiment that "I use Windows/Mac and don't care about anything else"), perhaps a mutual recognition in each community of the other would be beneficial. None of this provides a simple answer to the question, "How do I write a complicated, integrated, cross-platform GUI application in Python?" However, we shouldn't seek to mislead by providing simple answers where in practice there are none. And given that people actively working on such issues don't have simple answers to such questions, we shouldn't be dishonest in pretending we have something they don't. > (One of my concerns about PyGUI is that the postings by its > proponents on this list seem to be somewhat dismissive of this > point - in other words, I get the impression that fac
Re: [Python-3000] back with more GUI planning in a few days...
On Monday 08 May 2006 15:30, Greg Ewing wrote: > Paul Boddie wrote: > > Promoting a successor to stdwin doesn't seem like progress to me. > > It's a bit hard to sort out what you're actually saying > in all that. Are you arguing for or against something > like PyGUI? I'm not against PyGUI. Actually, it seems like a nice project, and given that I believe that everyone should try and develop different things if only to see where it takes them, it will be interesting to see where you take it (and where it takes you). I think there needs to be more innovation in graphical user interfaces and visualisation, and that isn't going to happen if everyone waits for Microsoft, Apple and others to do the legwork. And as I said, unifying different technologies is an interesting topic that I personally find compelling if it can be done reasonably. > The Gnome vs. KDE issue seems like an argument in > favour to me. Because the alternative is only being able > to write an app that blends in with Gnome *or* KDE > but not both. One of my points, probably not made explicitly or at least very well, is that because there are two main UNIX desktop camps (ignoring legacy desktops and the minor players), people have been confronted with the "how do I get the right print dialogue up?" question already, and there are groups of people working on cross-desktop issues. Sure, the solutions aren't always very pleasant, and perhaps one has to forego a certain level of integration in order to cover all the target environments. Nevertheless, I think it would be a bad thing if something in the standard library claimed to provide, or just gave the vague impression of providing, a definitive solution for all environments (the "simple answer" I alluded to) when to achieve a satisfactory result involves a bit more work. People entrenched in the desktop standards debate are seemingly reconciled to the multitude of toolkits and technologies currently available - picking winners doesn't acknowledge the sophistication of the situation. My rant about communities perhaps offers a few different ways forward: to keep up with possible solutions to integration issues; to consider people who know which desktop technologies they want to use and to provide them with some kind of coherent roadmap. On the former, I believe it's possible to write a cross-platform application using technologies such as PyGtk and PyQt, even styling them to look mostly consistent with the host desktop environment, but there's a certain amount of deeper integration work still to be done (and that doesn't even cover stuff like desktop integration): we should be aware of what the state of the art is, perhaps incorporating it into projects like PyGUI, or perhaps offering desktop integration and GUI abstraction in other ways. On the latter, we should also examine the process of choosing toolkits and languages from the direction usually not considered by existing Python users and developers: what if I want to write a GNOME application; which language should I choose? Until now, Python hasn't really been promoted to people coming from that direction, but I'd argue that it's possibly more significant as a market than that which covers those people already using Python who are looking for some kind of cross-platform toolkit. As to whether PyGUI or anything else of that nature should be in the standard library, my feeling is that if it (PyGUI or anything else) cannot deliver the desired functionality without leaving various kinds of users looking for another toolkit at some level of ambition (eg. providing a file chooser or print dialogue in their application), then we should leave such things out of the standard library and spell out the options in a clear fashion, acknowledging that more than one choice exists but the means of choosing one is not some kind of magic ritual. Remember that with Tkinter as a mostly informal standard for years, people have had to deal with this issue continuously, mostly abandoning Tkinter and going with something else. Providing another API which only gets you so far before you have to go and learn another one, just to get access to some aspects of the environment, isn't necessarily progress; as I wrote, this particular lesson is quite similar to those currently floating upwind of the Web technologies debate. Paul ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] back with more GUI planning in a few days...
On Monday 08 May 2006 16:20, Jim Jewett wrote: > On 5/8/06, Paul Boddie <[EMAIL PROTECTED]> wrote: > > > > I agree with this, although how ambitious are such tools? If you're just > > popping a dialogue asking for user input, there are typically other means > > of doing that without bringing in a whole GUI framework. > > And what are those ways, cross-platform? Well, you'd have to provide access to platform-specific programs or services through an API, since I doubt that kdialog or xdialog are provided with Windows, for example, although it would be surprising if nothing of that nature was shipped with Windows. Additionally, if you treat the GUI usage in a functional way - ie. you consider what you want the GUI to show, not the details of laying things out, plotting stuff, and so on - then I imagine a number of other domain-specific services could be provided, such as command line argument editors and so on (as has already been shown elsewhere). Not that any domain-specific services are likely to provide a full answer, but if you consider the examples given above, in addition to simple things like webbrowser or alternatives such as os.startfile (and my desktop module), it is evident that there's a certain amount of scope for simple desktop integration that doesn't require a full toolkit and the complexity which it entails. > > > But for small tools (for example, a configuration control panel), > > > the extra step of installing a UI framework may be significant. > > > > I think the reduced friction is less about the installation and a lot > > more to do with which API you use: > > It's both. That's why I wrote "less about" rather than "not about". ;-) > > Scaling a standard up to complicated, > > integrated applications is a mostly unsolved problem, though. > > So accept that complicated integrated applications will need to go > beyond the standard library's offerings, and (almost) stop worrying > about them. Perhaps you can say that "I'm going to do a small project which only needs the standard library API" or instead that "I'm going to write a mega-application which needs a complicated API" but even if no-one ever needs to migrate their half-finished applications between the two APIs, you still provide a confusing message to developers. Paul ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] back with more GUI planning in a few days...
On Tuesday 09 May 2006 02:42, Greg Ewing wrote: > Paul Boddie wrote: > > I think it would be > > a bad thing if something in the standard library claimed to provide, or > > just gave the vague impression of providing, a definitive solution for > > all environments > > I would never claim that PyGUI provided a definitive solution > for all environments (and as has been pointed out, no such > claim is made for anything else in the stdlib either). True: as noted, Tkinter only covers the "big three". However, even if we discard QNX, BeOS, OS/2, AtheOS, RISC OS and the Amiga as reasonable candidates for running any standard GUI, limiting our attention to the "big three", there's a lot of variation especially in the UNIX area that I feel needs to be addressed. Perhaps "definitive" should mean "substantially better than Tkinter", where this includes a "look and feel" appropriate to the target environment, theming, the possibility for bringing in appropriate dialogues without having to maintain lookalikes (or at least some kind of roadmap to better desktop integration, perhaps like PyGtk -> PyGNOME and PyQt -> PyKDE), and a huge list of features that would certainly put me off writing a GUI framework. > First and foremost, I'm creating PyGUI because *I* want it, > for programs that I write. The most important thing about > PyGUI for me is the API. I've used quite a number of other > Python GUI APIs, and I've never found one that wasn't too > complicated or unpythonic or generally cruddy for my liking. > I want an API that fits in my brain along with the rest of > Python. And, as I said, you should go for it! > The next most important thing is to have it work easily on a > reasonably wide range of platforms, so that I can share my > programs with others without requiring them to jump through > hoops to get them working. And I can appreciate that. Indeed, there is a need for such an API beyond something like PyGame, and the controversy is limited only to a standard library context when people need more than what that API provides and have to think about how to advise them. > I don't particularly mind whether it gets into the standard > library. From my point of view it would be nice, but I'm > happy to include it along with the applications I distribute > if necessary. I'm hoping to keep it small enough to make > that practicable. My worry would be that if another toolkit were dropped into "pole position" to replace Tkinter, and then people ignored it just as much as they ignored Tkinter, choosing other toolkits, then this would involve a lot of maintenance to keep the replacement relevant (or to make it appeal to people) and a lot of education to steer people around the toolkit where it doesn't meet their needs. This last part is often underestimated, and as I mentioned a few times, you see the effects in the Web development subcommunity where an arguably less ambitious standardisation effort has given way to seeing who can shout the loudest, rather than people giving up a fraction of their shouting time to contribute to a coherent overview of where all the solutions fit together. [...] > > what if I want to write a GNOME application; which > > > > language should I choose? > > This is more or less the opposite question to the one > PyGUI addresses, which is: I want to write a GUI application > in Python -- what toolkit do I use? PyGUI's answer is: > Use one that's specifically designed for writing GUI > applications in Python. And I don't have a problem with that. I was merely pointing out that people do have other motivations for considering Python plus a GUI library and that Python isn't exactly well-promoted in official circles to appeal to such people. It's continuously surprising to me where Python shows up, yet you wouldn't hear about many of these solutions in comp.lang.python and the related mailing list universe, mostly because people there are thinking about Python foremost with the environment as an afterthought, if that. Python was once described as a glue language, but sometimes I wonder if the tube is blocked up. > Such a thing currently does not exist. That is what > PyGUI is meant to be. I'll leave that point for others to contend. ;-) Paul ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Type annotations: annotating generators
Guido van Rossum wrote: > > I'm not convinced that we need all this for the likely intended use, > since static type checking isn't really high on the agenda anyway. I know I'll get into trouble for quoting this out of context, and I accept that there's a difference between static typing and writing declarations that look like static type declarations but which operate at run-time. However, I keep wondering whether we're missing out on something by adopting a type description language that will either prove to be inadequately expressive or evolve to something on the level of a full programming language in its own right. What's the general opinion on systems which attempt to infer and predict inappropriate type usage? (Which I'm guessing is the main motivation here, rather than performance, which if I recall correctly, was downplayed in the context of "optional" type declarations.) By "predict", I mean something that operates before run-time; not something which tells you 100ns before an exception is raised. Couldn't such systems be a better aid to program reliability? Would "optional" type declarations be relevant to the operation of such systems? Paul ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Type annotations: annotating generators
Tony Lownds wrote: > > Paul Boddie wrote: > > > > What's the general opinion on systems which attempt to infer and > > predict inappropriate type usage? [...] > > Couldn't such systems be a better aid to program reliability? > > Would "optional" type declarations be relevant to the operation > > of such systems? > > I've been hacking on such a system, called "t_types". It is in pre- > release form right now. It actually deduces type usage using bytecode > simulation, before run-time. I've been working on something similar, which is partly why I asked the question. See here: http://www.python.org/pypi/analysis However, it's not that similar: it traverses the AST (from the compiler module) for want of a representation that doesn't drop useful information from the program. For a more efficient approach, I can imagine a virtual machine which operates on types and constraints as opposed to actual data, and I imagine that the PyPy "flow object space" might do something like this, but finding some kind of concise confirmation of such suspicions in the PyPy documentation is often a challenge. There are other systems which take similar approaches: Shedskin, Starkiller, Pylint (not the Logilab one), along with various other experiments. It makes me think that a common framework, possibly involving some of the Logilab projects (as previously suggested to me by one of their developers), may provide a good opportunity for consolidation here. > For t_types, starting the simulation with types more specific than > "anything" is important for reasonable results. In general I think > optional type declarations are relevant to such systems, whether a > special syntax is adopted or decorators are used. Is there some kind of unstated consensus on whole-program analysis? Collin Winter expressed some reservations in a private communication, but I'd be interested to hear why people seem to disregard that approach so lightly. I don't doubt that accurate type inference is a hard problem - Mark Dufour's thesis provides some level of confirmation of that - but I'm inclined to believe that there's a wide open space between today's Python and ubiquitous type declarations that could hold a more appropriate solution. [...] > from t_types import t > > @t.signature(t.int|t.None, returns=t.int) > def test43(foo=None): >if None is 1: > # should be dead code > return '' >if 1 is None: > # should be dead code > return '' >if foo is None: > return 1 >else: > # foo should have type of t.int here > return foo > > @t.signature(returns=t.list[t.int]) > def test26(): >x = [] >x[0] = 1 >return x Stripping the import and decorators from this and running it through the analysis tools doesn't identify dead code, mostly because I haven't implemented optimisations for the identity operators in the way envisaged above (although it is done for isinstance calls), but it does tell you what the return types are, provided there are some calls to the above functions. Whilst that is almost like declaring the types, it is only necessary to provide usage of a function at the top of a "call hierarchy" - you wouldn't write an explicit call to test26 if such invocations already existed in other places. Accurate prediction of the contents of things like lists can be hard, though, but instead of declaring such things everywhere, one thing I mentioned in my communications with Collin Winter was the possibility of "semantic" marking of such types: instead of stating list[int], or to take a more illustrative example, instead of stating list[Element|Text], you refer to an ElementList (possibly by subclassing list) and then have the inferencer work out that only Element and Text objects are ever stored in such objects. Shedskin manages to find such things out all by itself, but I'm not certain that it can always do so. Having some level of abstract type annotation, whilst not as nice as having the system work everything out by itself, is certainly better than the maintenance nightmare of going round adjusting type declarations upon a minor type-related modification to a program, however. Paul ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] PEP 3108: Standard Library Reorganization
Brett Cannon wrote: > As part of my New Years resolution to get all of my current and planned PEPs > actually written, accepted, and implemented for 2007, here is the stdlib > reorg PEP. I have already checked it into svn but I have inlined it below > for comments. There's a document on the python.org Wiki which goes into some of the same areas as those addressed in the PEP, although things like hierarchy reorganisation are presumably beyond what is desired for Python 3.0. See here for more: http://wiki.python.org/moin/CodingProjectIdeas/StandardLibrary/RestructuredStandardLibrary Paul ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
