tidy project file organization (modules and tests)
What's the customary way to organize your project files -- particularly modules? Does the following look correct? my_project/ main_script.py doc/ [...] whatever/ [...] lib/ mymod1.py mymod2.py test/ test_mymod1.py test_mymod2.py some_pkg/ __init__.py goodmod1.py goodmod2.py test/ test_goodmod1.py test_goodmod2.py That is, my project may contain some local project-specific modules (mymod1, mymod2), but also some in a package that I reuse here and there in other projects too (some_pkg.goodmod1, some_pkg.goodmod2). What's the usual name and placement of the file that runs all the tests? Finally, if anyone could point me toward any exemplary modules in the cheeshop that have a tidy project file layout, it would be most helpful. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a good Python environment
On Nov 10, 4:48 am, Paul Rudin <[EMAIL PROTECTED]> wrote: > jwelby <[EMAIL PROTECTED]> writes: > > > The main reason I have used Eclipse for larger, team based, projects > > is for the source control plug-ins. Eclipse has plug-in support for > > cvs and svn. PyScripter may have this too - perhaps I've missed it. > > (I'm away from my Windows box at the moment, otherwise I would check). > > Of course, there are other ways to implement source control without it > > needing to be integrated in the IDE, so even this need not put off > > anyone who wants to use PyScripter with source control. > > > [snip] > > I'm not sure if you count emacs as "lightweight" but it's certainly > less resource hungry than eclipse/pydev, and does have integrated > cvs/svn functionality. I've never understood the desire for using your version control software via your IDE. Why not just Alt-Tab over to your terminal window and run the svn/bzr/hg/git/whatever commands yourself right from there? -- http://mail.python.org/mailman/listinfo/python-list
Re: why there is no pythonscript insine web browsers?
On Nov 13, 3:07 am, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > On Mon, 12 Nov 2007 20:07:38 +0200, Timuçin K?z?lay > <[EMAIL PROTECTED]> declaimed the following in comp.lang.python: > > > python support? there is even a vbscript support inside MS-IE but there > > is no python support. it would be really nice and easy for me to use > > python instead of javascript to write those ajax scripts. > > Javascript is meant to, basically, control the browser and the > contents of HTML pages sent to it. [snip] Python can not > be safely sand-boxed (and the early restricted mode modules have been > removed for that reason). > Why can't it be safely sandboxed? That is, why not just have a Python interpreter and some safe subset of the Python standard library run with the browser? I mean, aside from the work involved with combing out the unneeded or dangerous parts of the standard lib, it seems like it would be much nicer to just use Python syntax and modules rather than having to fool around with Javascript. -- http://mail.python.org/mailman/listinfo/python-list
Re: Cross-platform GUI development
On Oct 25, 6:32 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> On 10/24/07, bramble <[EMAIL PROTECTED]> wrote:
>
> > In the end, GTK+ is themable, and it's a free software project, so if
> > the MS Windows port has warts, anyone can come along and polish it up
> > for that platform.
>
> There's been plenty to say about this in the past, so I will be brief:
> Being able to use the native theme API is necessary but not sufficient
> for native look and feel. Gtk doesn't even try for anything other than
> a cursory attempt at "look", and as far as I know doesn't have any
> real interest in doing so.
>
> I don't have any problem than that, but I don't like people
> misrepresenting what you get from using Gtk.
Sorry, I didn't mean to misrepresent GTK+. I clumsily jammed 2 ideas
into one sentence: one, that theming can mitigate some issues with
differences in L&F ("look and feel"), and two, that it's free
software, so contributors can try and make the L&F more native if it's
really that big a deal.
One reason I'm not crazy about wx because I don't like the idea of
adding yet another API layer into the mix. Wx seems quite large, and
if issues arise, debugging a GUI that calls another GUI does not seem
like a fun way to spend your time. Anyhow, my opinion is, pick one
good enough native GNU/Linux GUI toolkit that the community can
somewhat standardize on (and GTK+/PyGTK seems to fit that bill pretty
well), write your apps in that so they run really well on GNU/Linux
distros, and *then* get your apps running on secondary OS's as-needed.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Cross-platform GUI development
On Oct 12, 6:30 am, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: > > I'd recommend wxPython over those becase > > 1) native look and feel on all platforms > 2) doesn't require expensive licensing for non-commercial apps (QT) > 3) Isn't a pain to install on windows (GTK) > > That said, times change and 1-3 may have changed since I last looked > at it! My impression has always been that a number of people use wx because of its API similarities to some MS Windows GUI toolkit or other. -- http://mail.python.org/mailman/listinfo/python-list
Re: Cross-platform GUI development
On Oct 23, 2:59 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > On 10/23/07, maco <[EMAIL PROTECTED]> wrote: > > > > On Oct 13, 12:34 am, Michael L Torrie <[EMAIL PROTECTED]> wrote: > > > > Qt doesn't look very native on my desktop. In fact, Qt apps have always > > > looked out of place on a Gnome desktop. > > > > On Windows and Mac, no question, they look pretty native. You do have > > > to take pains to make the app "feel" native, though. Like follow the UI > > > guidelines of the platform, etc. > > > > > Just a question of "feeling" I think; because most of those GUI > > > > framework, offer quiet the same functionality. > > > GTK (like Pidgin or the GIMP) looks pretty native on Windows to me. > > This can only be because you don't use these programs often, or you've > never actually looked at them. The GIMP in particular has almost > nothing in common with the native controls - it's got a different > background color, a different drawing model (note nasty delayed > repaints when resizing), clearly non-native dialogs like file pickers, > non-standard menu icons, just a huge list. > > Pidgin has a fairly minimal interface so it's flaws are less obvious, > but they're still there. > > If this doesn't bother you, more power to you, but don't make the > mistake of thinking that GIMP is any way "native" on windows. In the end, GTK+ is themable, and it's a free software project, so if the MS Windows port has warts, anyone can come along and polish it up for that platform. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 3, 1:39 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > On 10/3/07, Grant Edwards <[EMAIL PROTECTED]> wrote: > > > On 2007-10-03, Chris Mellon <[EMAIL PROTECTED]> wrote: > > > On 10/2/07, Grant Edwards <[EMAIL PROTECTED]> wrote: > > >> On 2007-10-02, Chris Mellon <[EMAIL PROTECTED]> wrote: > > > >> > PyGtk has poor cross platform support, a very large footprint (the > > >> > largest of all these libraries) > > > >> It's larger than wxWidgets on top of Gtk? > > > > No, but it's larger than wx on top of the native API, > > > A moot point for X11. > > wxWidgets actually does have a raw X11 implementation, Wait though. If I want to use wxPython, my python code calls wxWidgets code which calls gtk. So, it would seem simpler to remove 1 layer and just call the gtk code directly via PyGTK. > > > > so when you average it across all platforms it's quite a bit > > > larger. > > > I guess that's one of the costs of portability. > > Eh? The point is that wxWidgets, the more portable toolkit, is > *smaller* than Gtk. It's not really related to portability as much as > design considerations. Isn't wxWidgets smaller that GTK+ simply because it's a wrapper and doesn't do its own drawing? -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 2, 11:07 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > > PyGtk has poor cross platform support, a very large footprint (the > largest of all these libraries) as well as a complicated runtime > environment. What's complicated about it? -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 2, 7:33 am, Carsten Haese <[EMAIL PROTECTED]> wrote: > On Tue, 2007-10-02 at 03:04 +, bramble wrote: > > But Py3k is all about breaking compatibility > > That's a complete distortion of Python 3.0's mission. Python 3.0 breaks > backwards compatibility only where there exist good reasons to do so. As > Guido put it in a recent Python-3000 post, "Python 3000 is boldly > choosing to be backwards compatible, except in cases where a real > benefit can be obtained by being incompatible." > > So, unless you can make a case that a real benefit can be obtained by > removing Tkinter, it'll stay. Well, it of course wouldn't break backward compatibility by simply removing it from the standard library and providing it as an optional extra set of modules. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 2, 5:29 am, Paul Boddie <[EMAIL PROTECTED]> wrote: > On 2 Okt, 04:54, bramble <[EMAIL PROTECTED]> wrote: > > > Maybe the key I'm missing is this: maybe GvR and company think that a > > language absolutely should come off-the-shelf with GUI toolkit > > bindings. So, given that, they feel they've gotta pick just one, and > > they've already got Tkinter and it works, so that's that. Is that it? > > Yes. Ahh... Ok. Thanks, that explains it. At first, it hadn't ocurred to me that anyone would want to provide a GUI toolkit binding along with a popular general purpose programming language implementation. Moreover, it *really* wouldn't occur to me that they'd also want to provide an IDE (as Terry mentions in another reply). But then, I'm looking at Python today, in 2007, at a time when Python has multiple high-quality GUI toolkit bindings available, and when most editors and IDE's have excellent Python support built-in. Given that line of reasoning though, it seems odd to me that GvR and Co. would still regard shipping those as part of Python proper as a requirement for Py3k. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 1, 10:34 pm, Benjamin <[EMAIL PROTECTED]> wrote: > and they are still supported > not to break compatability. Hm. Ok. I can see that for the 2.x releases. But Py3k is all about breaking compatibility, so, it would seem there's more to the story. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 1, 10:54 pm, bramble <[EMAIL PROTECTED]> wrote: > > BTW, pulling Tkinter and related GUI stuff out of Py3k's standard > library wouldn't harm existing Tkinter users -- it would merely > require them to actually install it if they want it. Oops. I meant to put in there, after the "BTW,": "it seems to me that". -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 1, 9:14 pm, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > bramble <[EMAIL PROTECTED]> writes: > > Maybe a better question is, how has Tk managed to keep beating up the > > newer, more modern, more featureful, better documented toolkits > > encroaching on his territory? What's Tk's secret weapon? > > First-mover advantage. I don't know... As I meant to imply above, it's looking like Tkinter will be playing its expected role in Py3k as the GUI toolkit of choice. And from what I've seen of the Py3k effort, there's been really excellent work on pulling out stuff that should be pulled out. So, if it was *really* simply only first-mover advantage keeping it there, I'd expect to see talk of removing it from the standard library. BTW, pulling Tkinter and related GUI stuff out of Py3k's standard library wouldn't harm existing Tkinter users -- it would merely require them to actually install it if they want it. Maybe the key I'm missing is this: maybe GvR and company think that a language absolutely should come off-the-shelf with GUI toolkit bindings. So, given that, they feel they've gotta pick just one, and they've already got Tkinter and it works, so that's that. Is that it? -- http://mail.python.org/mailman/listinfo/python-list
gui toolkits: the real story? (Tkinter, PyGTK, etc.)
What is the backstory to why Python includes Tk bindings, as opposed to some other set of bindings? I've written a few little Tkinter-based apps, and it's nice and simple. I like it well enough. That said though, I keep feeling the gravitational pull toward GTK+. I've been meaning to get the whole glade+gtk+python thing happening with my own projects, as soon as time allows. Is there resistance in the upper Python echelons to GTK because of its LGPL licensing? Reading Alex's Nutshell book, right off the bat he comments that "The most popular Python GUI toolkit today is probably wxPython". But then he goes on for 45 pages on Tkinter... Seems like he wanted to write that chapter on wx instead... WxWidgets, the last time I looked at it, seemed awfully like MS Window's MFC. The licensing seemed vague at the time, and it looks like wx contains an extra layer of GUI library, so I didn't spend any real time on it. But, regardless, it seems to get good press among python folk (I think I remember ESR noting how it was his GUI toolkit of choice). PyQt has had that issue (IIRC) about needing to pay for it for commercial apps, so I can see how there might be resistance to it being considered the "standard Python GUI toolkit". So, it would seem to me that Tkinter *might* remain in Python proper, but that I probably wouldn't see much effort put into it. Well, the Python standard library docs tell a different story. There's stuff in there about Tix, ScrolledText, turtle, and then the "other GUI packages" doc page goes on about Python megawidgets (Tk-based) and Tkinter3000 Widget Construction Kit (WCK). Wow. Looks like Tkinter is still having serious support -- even though in that same doc at the bottom notes, "PyGTK, PyQt, and wxPython, all have a modern look and feel and far more widgets and better documentation than Tkinter." So, that leaves me wondering, why is Tkinter still getting so much focus in the Python standard library? Maybe a better question is, how has Tk managed to keep beating up the newer, more modern, more featureful, better documented toolkits encroaching on his territory? What's Tk's secret weapon? -- http://mail.python.org/mailman/listinfo/python-list
