File handle not being released by close

Discussion in 'Python' started by bg_ie@yahoo.com, Jul 30, 2007.

  1. Guest

    Hi,

    I'm in the process of writing some code and noticed a strange problem
    while doing so. I'm working with PythonWin 210 built for Python 2.5. I
    noticed the problem for the last py file processed by this script,
    where the concerned tmp file is only actually written to when
    PythonWin is closed. In other words, after I run this script, one of
    the generated tmp files has a size of 0kB. I then close PythonWin and
    it is then written to.

    I'm guessing the garbage collector is causing the file to be written,
    but shouldn't close do this?

    /Barry

    import os, time, string

    dir = 'c:\\temp1'

    def listAllFile(fileNames,dir,files):
    def f1(a,dir=dir): return os.path.join(dir,a)
    files2 = map(f1, files)
    fileNames.extend(files2)

    fileNames = []
    os.path.walk(dir,listAllFile,fileNames)

    for fileName in fileNames:
    fileBeginning = os.path.splitext(fileName)[0]
    fileEnd = os.path.splitext(fileName)[1]

    if fileEnd == ".py":
    print fileName
    f=open(fileBeginning+".tmp", 'w')
    f.write("Hello")
    f.close
    , Jul 30, 2007
    #1
    1. Advertising

  2. <> wrote in message
    news:...

    > I'm guessing the garbage collector is causing the file to be written,
    > but shouldn't close do this?


    Only if you call it ;)
    Richard Brodie, Jul 30, 2007
    #2
    1. Advertising

  3. Peter Otten Guest

    wrote:

    > I'm in the process of writing some code and noticed a strange problem
    > while doing so. I'm working with PythonWin 210 built for Python 2.5. I
    > noticed the problem for the last py file processed by this script,
    > where the concerned tmp file is only actually written to when
    > PythonWin is closed. In other words, after I run this script, one of
    > the generated tmp files has a size of 0kB. I then close PythonWin and
    > it is then written to.
    >
    > I'm guessing the garbage collector is causing the file to be written,
    > but shouldn't close do this?


    Yes.

    > f=open(fileBeginning+".tmp", 'w')
    > f.write("Hello")
    > f.close


    In Python () is nessary to call a parameterless function or method:

    >>> def f(): print "Hi Barry"

    ....
    >>> f

    <function f at 0xb7cf2374>
    >>> f()

    Hi Barry

    This allows it to treat functions as variables consistently:

    >>> def f(write):

    .... write("Hello")
    ....
    >>> def write_upper(s): print s.upper()

    ....
    >>> import sys
    >>> write_to_stdout = sys.stdout.write
    >>>
    >>> f(write_upper)

    HELLO
    >>> f(write_to_stdout)

    Hello>>>

    Peter
    Peter Otten, Jul 30, 2007
    #3
  4. Eric Brunel Guest

    On Mon, 30 Jul 2007 16:36:00 +0200, <> wrote:

    > Hi,
    >
    > I'm in the process of writing some code and noticed a strange problem
    > while doing so. I'm working with PythonWin 210 built for Python 2.5. I
    > noticed the problem for the last py file processed by this script,
    > where the concerned tmp file is only actually written to when
    > PythonWin is closed. In other words, after I run this script, one of
    > the generated tmp files has a size of 0kB. I then close PythonWin and
    > it is then written to.
    >
    > I'm guessing the garbage collector is causing the file to be written,
    > but shouldn't close do this?
    >
    > /Barry
    >
    > import os, time, string
    >
    > dir = 'c:\\temp1'
    >
    > def listAllFile(fileNames,dir,files):
    > def f1(a,dir=dir): return os.path.join(dir,a)
    > files2 = map(f1, files)
    > fileNames.extend(files2)
    >
    > fileNames = []
    > os.path.walk(dir,listAllFile,fileNames)
    >
    > for fileName in fileNames:
    > fileBeginning = os.path.splitext(fileName)[0]
    > fileEnd = os.path.splitext(fileName)[1]
    >
    > if fileEnd == ".py":
    > print fileName
    > f=open(fileBeginning+".tmp", 'w')
    > f.write("Hello")
    > f.close


    f.close()

    HTH...
    --
    python -c "print ''.join([chr(154 - ord(c)) for c in
    'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
    Eric Brunel, Jul 30, 2007
    #4
  5. Gary Duzan Guest

    In article <>,
    <> wrote:
    >
    > [ ... ]
    >
    >for fileName in fileNames:
    > fileBeginning = os.path.splitext(fileName)[0]
    > fileEnd = os.path.splitext(fileName)[1]
    >
    > if fileEnd == ".py":
    > print fileName
    > f=open(fileBeginning+".tmp", 'w')
    > f.write("Hello")
    > f.close

    f.close()

    Gary Duzan
    Motorola CHS
    Gary Duzan, Jul 30, 2007
    #5
  6. Re: Tkinter or wxpython?

    On Aug 3, 1:00 am, "wang frank" <> wrote:
    > I want to build a GUI to execut python script. I found TKinter and
    > wxpython. Which one is easier for a newbie? and which one is better?


    Well, Tkinter comes with Python, so newbies can get up and running
    straight away without having to download and install anything else.
    And there are probably lots more examples out there that a newbie can
    look at and learn from. As for *better*, wxPython has a lot more
    kinds of widgets in it, which will make writing GUIs less tedious in
    the long run, and the widgets look a lot nicer too.

    Glenn
    Glenn Hutchings, Aug 3, 2007
    #6
  7. Guest

    Re: Tkinter or wxpython?

    On Aug 2, 7:00 pm, "wang frank" <> wrote:
    > Hi,
    >
    > I want to build a GUI to execut python script. I found TKinter and
    > wxpython. Which one is easier for a newbie? and which one is better?
    >
    > Thanks
    >
    > Frank
    >
    > _________________________________________________________________
    >
    > http://clk.atdmt.com/GBL/go/msnjpqjl0060000010gbl/direct/01/


    I've read that Tkinter doesn't scale well if you're writing complex
    GUIs. I haven't been able to test this hypothesis though. However,
    since I had to rewrite VBA apps into Python, to get the right "look
    and feel" I needed the widgets that wxPython provided. Since I started
    out with C++, I find wxPython better than Tkinter, but it's all pretty
    subjective. Try them both!

    Mike
    , Aug 6, 2007
    #7
  8. Paul Rubin Guest

    Re: Tkinter or wxpython?

    writes:
    > I've read that Tkinter doesn't scale well if you're writing complex
    > GUIs. I haven't been able to test this hypothesis though. However,
    > since I had to rewrite VBA apps into Python, to get the right "look
    > and feel" I needed the widgets that wxPython provided. Since I started
    > out with C++, I find wxPython better than Tkinter, but it's all pretty
    > subjective. Try them both!


    Tkinteger (dang, I always end up typing it that way, I won't even
    bother fixing the error) is easy to use for simple gui's, and it's
    part of the standard python distro which for me is a big advantage (no
    extra crap to download). However, the widget set is rather ugly and
    doesn't blend in well with anyone's native widgets; the widget
    selection itself is rather narrow, and I think kyosohma may be right
    that it doesn't scale well to complex gui's. I've looked at the code
    for IDLE's gui and it's terrifying.

    At this point I think nobody should write desktop gui apps without a
    good reason. There is a fairly flexible and easy to program gui
    already running on almost every desktop, namely the web browser.
    Before you write a gui using some client side toolkit, ask yourself
    whether you can instead embed a web server in your application and
    write an HTML gui. That approach is not always the answer, but it has
    considerable advantages when you can do it that way.
    Paul Rubin, Aug 6, 2007
    #8
  9. Guest

    Re: Tkinter or wxpython?

    On Aug 6, 9:39 am, Paul Rubin <http://> wrote:
    > writes:
    > > I've read that Tkinter doesn't scale well if you're writing complex
    > > GUIs. I haven't been able to test this hypothesis though. However,
    > > since I had to rewrite VBA apps into Python, to get the right "look
    > > and feel" I needed the widgets that wxPython provided. Since I started
    > > out with C++, I find wxPython better than Tkinter, but it's all pretty
    > > subjective. Try them both!

    >
    > Tkinteger (dang, I always end up typing it that way, I won't even
    > bother fixing the error) is easy to use for simple gui's, and it's
    > part of the standard python distro which for me is a big advantage (no
    > extra crap to download). However, the widget set is rather ugly and
    > doesn't blend in well with anyone's native widgets; the widget
    > selection itself is rather narrow, and I think kyosohma may be right
    > that it doesn't scale well to complex gui's. I've looked at the code
    > for IDLE's gui and it's terrifying.
    >
    > At this point I think nobody should write desktop gui apps without a
    > good reason. There is a fairly flexible and easy to program gui
    > already running on almost every desktop, namely the web browser.
    > Before you write a gui using some client side toolkit, ask yourself
    > whether you can instead embed a web server in your application and
    > write an HTML gui. That approach is not always the answer, but it has
    > considerable advantages when you can do it that way.


    I agree that making web apps is probably the way of the future.
    However, there are lots of security risks involved with it that need
    to be understood. One of the problems that raging is about AJAX, see
    here: http://arstechnica.com/news.ars/pos...bout-the-risks-of-premature-ajax-ulation.html

    Desktop apps have security issues too, of course.

    Mike
    , Aug 6, 2007
    #9
  10. Chris Mellon Guest

    Re: Tkinter or wxpython?

    On 06 Aug 2007 07:39:12 -0700, Paul Rubin
    <"http://phr.cx"@nospam.invalid> wrote:
    > writes:
    > > I've read that Tkinter doesn't scale well if you're writing complex
    > > GUIs. I haven't been able to test this hypothesis though. However,
    > > since I had to rewrite VBA apps into Python, to get the right "look
    > > and feel" I needed the widgets that wxPython provided. Since I started
    > > out with C++, I find wxPython better than Tkinter, but it's all pretty
    > > subjective. Try them both!

    >
    > Tkinteger (dang, I always end up typing it that way, I won't even
    > bother fixing the error) is easy to use for simple gui's, and it's
    > part of the standard python distro which for me is a big advantage (no
    > extra crap to download). However, the widget set is rather ugly and
    > doesn't blend in well with anyone's native widgets; the widget
    > selection itself is rather narrow, and I think kyosohma may be right
    > that it doesn't scale well to complex gui's. I've looked at the code
    > for IDLE's gui and it's terrifying.
    >
    > At this point I think nobody should write desktop gui apps without a
    > good reason. There is a fairly flexible and easy to program gui
    > already running on almost every desktop, namely the web browser.
    > Before you write a gui using some client side toolkit, ask yourself
    > whether you can instead embed a web server in your application and
    > write an HTML gui. That approach is not always the answer, but it has
    > considerable advantages when you can do it that way.


    Some disadvantages of the web based platform:

    No native look and feel - constrained by the browser.
    No control over browser UI idioms. I had to write this post twice
    because the text control lost focus and I hit backspace, going back in
    the history and losing my work.
    No native integration - no "open file", no "browse the filesystem", no
    rich drag and drop, no copy/paste.
    No or poor dialogs. Poor multiple window support.
    More platforms to develop on and test with.
    Limited to CSS box model for layout.


    You can mitigate some of these constraints if you *require* the local
    web browser technique, rather than supporting local or remote access.
    You can mitigate more if you write your own browser host (along the
    lines of the dashboard in OS X), but then you get to write 3
    applications instead of one.

    The web is a terrible application platform. There is not a single web
    application in existence which has even half the UI functionality of a
    rich client application. There are some (even many) applications for
    which the benefit of global access and easy deployment makes up for
    the lack in functionality, but statements like "At this point I think
    nobody should write desktop gui apps without a good reason" are simply
    ludicrously misguided.
    Chris Mellon, Aug 6, 2007
    #10
  11. Paul Rubin Guest

    Re: Tkinter or wxpython?

    writes:
    > I agree that making web apps is probably the way of the future.
    > However, there are lots of security risks involved with it that need
    > to be understood. One of the problems that raging is about AJAX, see
    > here: http://arstechnica.com/news.ars/pos...bout-the-risks-of-premature-ajax-ulation.html


    Yes, do be careful of ajax, and of internet programming in general.
    However, the usual use of a desktop app is deployment within one
    company, so if you write it as a web app you can ease the security
    issue by firewalling the server so that it can't be accessed through
    the outside internet. That still makes deployment a lot easier, since
    there are zero desktop installations required, and you can upgrade the
    software whenever you want at the server side.
    Paul Rubin, Aug 6, 2007
    #11
  12. Paul Rubin Guest

    Re: Tkinter or wxpython?

    "Chris Mellon" <> writes:
    > No native look and feel - constrained by the browser.


    Might or might not matter for the application, especially considering
    that tkinter is part of the discussion.

    > No control over browser UI idioms. I had to write this post twice
    > because the text control lost focus and I hit backspace, going back in
    > the history and losing my work.


    Sounds weird, I'm used to having stuff in text boxes stay in the
    browser, and why did backspace have that effect anyway?

    > No native integration - no "open file", no "browse the filesystem", no
    > rich drag and drop, no copy/paste.


    File i/o and file system browsing are available from javascript if the
    user grants permission. File system browsing for the limited purpose
    of file upload is available in regular html. Copy/paste of ordinary
    text is always available. However, this type of requirement is what I
    mean by a "good reason" to write a desktop gui. It applies to some
    applications, not all.

    > No or poor dialogs. Poor multiple window support.


    Might or might not matter depending on the application. Most dialogs
    can be done with html. Multiple windows are evil most of the time,
    and should instead by done with multiple panes or cells in a single
    window.

    > More platforms to develop on and test with.


    Compared to a desktop app? I don't think so.

    > Limited to CSS box model for layout.


    Might or might not matter depending on the application. If you're
    doing a consumer app that has to look slick, you have no choice but to
    use something like wxwidgets (tkinter won't cut it either). If you're
    doing a special purpose office or industrial app, slickness isn't
    important.

    > The web is a terrible application platform. There is not a single web
    > application in existence which has even half the UI functionality of a
    > rich client application.


    Some of us consider simple interfaces with consistent, familiar
    (i.e. web) elements to be a good thing. Fancy client interfaces are
    ok if you feel you need to make a style statement, but are often
    unnecessary if you just want to get something done.

    > There are some (even many) applications for which the benefit of
    > global access and easy deployment makes up for the lack in
    > functionality, but statements like "At this point I think nobody
    > should write desktop gui apps without a good reason" are simply
    > ludicrously misguided.


    Well, I don't say that good reasons don't exist, I just see a lot of
    desktop apps that could be done just as well as web apps, i.e. for
    those, the good reason didn't exist.
    Paul Rubin, Aug 6, 2007
    #12
  13. Guest

    Re: Tkinter or wxpython?

    On Aug 6, 9:58 am, "Chris Mellon" <> wrote:
    > On 06 Aug 2007 07:39:12 -0700, Paul Rubin
    >
    >
    >
    > <"http://phr.cx"@nospam.invalid> wrote:
    > > writes:
    > > > I've read that Tkinter doesn't scale well if you're writing complex
    > > > GUIs. I haven't been able to test this hypothesis though. However,
    > > > since I had to rewrite VBA apps into Python, to get the right "look
    > > > and feel" I needed the widgets that wxPython provided. Since I started
    > > > out with C++, I find wxPython better than Tkinter, but it's all pretty
    > > > subjective. Try them both!

    >
    > > Tkinteger (dang, I always end up typing it that way, I won't even
    > > bother fixing the error) is easy to use for simple gui's, and it's
    > > part of the standard python distro which for me is a big advantage (no
    > > extra crap to download). However, the widget set is rather ugly and
    > > doesn't blend in well with anyone's native widgets; the widget
    > > selection itself is rather narrow, and I think kyosohma may be right
    > > that it doesn't scale well to complex gui's. I've looked at the code
    > > for IDLE's gui and it's terrifying.

    >
    > > At this point I think nobody should write desktop gui apps without a
    > > good reason. There is a fairly flexible and easy to program gui
    > > already running on almost every desktop, namely the web browser.
    > > Before you write a gui using some client side toolkit, ask yourself
    > > whether you can instead embed a web server in your application and
    > > write an HTML gui. That approach is not always the answer, but it has
    > > considerable advantages when you can do it that way.

    >
    > Some disadvantages of the web based platform:
    >
    > No native look and feel - constrained by the browser.
    > No control over browser UI idioms. I had to write this post twice
    > because the text control lost focus and I hit backspace, going back in
    > the history and losing my work.
    > No native integration - no "open file", no "browse the filesystem", no
    > rich drag and drop, no copy/paste.
    > No or poor dialogs. Poor multiple window support.
    > More platforms to develop on and test with.
    > Limited to CSS box model for layout.
    >
    > You can mitigate some of these constraints if you *require* the local
    > web browser technique, rather than supporting local or remote access.
    > You can mitigate more if you write your own browser host (along the
    > lines of the dashboard in OS X), but then you get to write 3
    > applications instead of one.
    >
    > The web is a terrible application platform. There is not a single web
    > application in existence which has even half the UI functionality of a
    > rich client application. There are some (even many) applications for
    > which the benefit of global access and easy deployment makes up for
    > the lack in functionality, but statements like "At this point I think
    > nobody should write desktop gui apps without a good reason" are simply
    > ludicrously misguided.


    If you could use Python's antiquated Grail web browser and write
    plugin applications, then that would be awesome! There are trade offs
    with anything though.

    Mike
    , Aug 6, 2007
    #13
  14. Kevin Walzer Guest

    Re: Tkinter or wxpython?

    Paul Rubin wrote:

    >
    > Tkinteger (dang, I always end up typing it that way, I won't even
    > bother fixing the error) is easy to use for simple gui's, and it's
    > part of the standard python distro which for me is a big advantage (no
    > extra crap to download). However, the widget set is rather ugly and
    > doesn't blend in well with anyone's native widgets; the widget
    > selection itself is rather narrow, and I think kyosohma may be right
    > that it doesn't scale well to complex gui's. I've looked at the code
    > for IDLE's gui and it's terrifying.


    It's entirely possible to make sophisticated GUI's in Tkinter, but you
    are right, most people don't. Part of the issue is that Tkinter
    developers haven't kept up with what's going on in Tk and instead use
    outdated, ugly widget sets like Tix, PMW, and so on. Making use of the
    available wrappers for current Tk libraries such as BWidgets, Tile,
    Tablelist, TkTreeCtrl, and so on allows you to make UI's every bit as
    polished as what comes with wxPython: tree views, multi-column lists,
    notebook tabs, comboboxes, etc., with platform-specific theming
    (XP/Vista, Aqua/OS X, and X11).

    For more references, see:

    http://tkinter.unpythonic.net/wiki/TileWrapper
    http://tkinter.unpythonic.net/wiki/TableListWrapper
    http://tkinter.unpythonic.net/wiki/TableListTileWrapper
    http://tkinter.unpythonic.net/wiki/PyLocate
    http://tkinter.unpythonic.net/wiki/PyLocateTile
    http://tkinter.unpy.net/bwidget/
    http://tkinter.unpy.net/wiki/NoteBook
    http://klappnase.zexxo.net/TkinterTreectrl/index.html

    >
    > At this point I think nobody should write desktop gui apps without a
    > good reason. There is a fairly flexible and easy to program gui
    > already running on almost every desktop, namely the web browser.
    > Before you write a gui using some client side toolkit, ask yourself
    > whether you can instead embed a web server in your application and
    > write an HTML gui. That approach is not always the answer, but it has
    > considerable advantages when you can do it that way.


    Given a choice between a rich desktop client and a web app, I'd choose
    the desktop client in most cases. It's just much more pleasant to work
    with .

    --
    Kevin Walzer
    Code by Kevin
    http://www.codebykevin.com
    Kevin Walzer, Aug 6, 2007
    #14
  15. Chris Mellon Guest

    Re: Tkinter or wxpython?

    On 06 Aug 2007 08:20:20 -0700, Paul Rubin
    <"http://phr.cx"@nospam.invalid> wrote:
    > "Chris Mellon" <> writes:
    > > No native look and feel - constrained by the browser.

    >
    > Might or might not matter for the application, especially considering
    > that tkinter is part of the discussion.
    >


    The point is that you have no option with the browser - even Tkinter
    has platform theming support now.

    > > No control over browser UI idioms. I had to write this post twice
    > > because the text control lost focus and I hit backspace, going back in
    > > the history and losing my work.

    >
    > Sounds weird, I'm used to having stuff in text boxes stay in the
    > browser, and why did backspace have that effect anyway?
    >


    On Windows, backspace is a browser global hotkey that means "go back
    once in the history". When the text box lost focus, hitting backspace
    navigated back. Gmail uses ajax instead of a page load when you start
    typing a reply, and the fragile tricks it uses to try to keep the
    browser history and the ajax state in sync don't work in this case.
    It's a specific example of the general problems of the browser as
    application platform.

    > > No native integration - no "open file", no "browse the filesystem", no
    > > rich drag and drop, no copy/paste.

    >
    > File i/o and file system browsing are available from javascript if the
    > user grants permission.


    Which they won't (I don't even know how, from Firefox), so you can't
    rely on it working. You can mitigate with your own browser host, or if
    you write all your own file browsing in HTML and move it into your
    local browser. Poor solutions all around.

    > File system browsing for the limited purpose
    > of file upload is available in regular html.
    >Copy/paste of ordinary
    > text is always available.


    But not of anything else. I've often wanted to drag & drop a file onto
    the file upload box in gmail, for example.

    >However, this type of requirement is what I
    > mean by a "good reason" to write a desktop gui. It applies to some
    > applications, not all.
    >


    How about something as simple as context menus? You can't reliably
    override the browser context menu from a web page unless, again, you
    provide your own browser host. This is a good thing, because a browser
    needs to be wary of arbitrary malicious web pages. They aren't good
    application hosts.

    Keyboard shortcuts that happen to conflict with whatever the browser
    or any of its plugins happen to use, too. Although I notice that
    Firefox now allows web pages to override that, which is a little sad.

    > > No or poor dialogs. Poor multiple window support.

    >
    > Might or might not matter depending on the application. Most dialogs
    > can be done with html. Multiple windows are evil most of the time,
    > and should instead by done with multiple panes or cells in a single
    > window.
    >


    Multiple windows are the common case on the mac. They're not rare on
    other platforms as well. The fact that your windows are constrained to
    the browser and can't be torn off is a large limitation. No toolbars,
    no palettes, no modal dialogs (except on IE, or if you constrain them
    to the browser). Lots of unnecessary chrome on your extra windows, too
    (see below).

    > > More platforms to develop on and test with.

    >
    > Compared to a desktop app? I don't think so.
    >


    Did you ever try counting? X browsers * Y browser versions * Z
    platforms. There are javascript and CSS bugs and differences between
    all of these. From my own professional experience, it's not any easier
    to account for browser differences than it is for platform
    differences. It's getting better as more people jump on the web
    bandwagon and CSS and JS abstraction libraries show up, but it's not
    even good as the available platform abstraction libraries like
    wxWidgets or Qt.

    > > Limited to CSS box model for layout.

    >
    > Might or might not matter depending on the application. If you're
    > doing a consumer app that has to look slick, you have no choice but to
    > use something like wxwidgets (tkinter won't cut it either). If you're
    > doing a special purpose office or industrial app, slickness isn't
    > important.
    >


    I'm not talking about chrome and slickness. I'm talking about basic
    usability concerns like "will this work with a higher font size" and
    "will it reflow in a sensible way if I change the window size". The
    CSS box model works okay for text, it's not so good for widgets. More
    than a few web apps end up writing their own layout engines in dynamic
    javascript. This is sad. While I'm talking about chrome, add "wasted
    screenspace due to browser chrome" to a limitation of web apps, again
    unless you write your own browser host. This is another example of a
    feature that makes a good browser (don't let arbitrary web pages mess
    with my web browser functionality) clashing with the desires of a good
    application (don't waste screen space with irrelevant functionality).

    > > The web is a terrible application platform. There is not a single web
    > > application in existence which has even half the UI functionality of a
    > > rich client application.

    >
    > Some of us consider simple interfaces with consistent, familiar
    > (i.e. web) elements to be a good thing. Fancy client interfaces are
    > ok if you feel you need to make a style statement, but are often
    > unnecessary if you just want to get something done.
    >


    Man, you should be in PR with the way you spin things. You can't
    implement anything except the most trivial of applications using only
    the simple, familiar web elements like HTML forms. Anything more
    complicated than that needs to be done with DHTML and probably AJAX,
    and those UI elements don't look anything like the familiar ones. You
    go in one breath from saying that you can implement dialogs in HTML to
    saying that the rich client is the *less* familiar of the interfaces?

    > > There are some (even many) applications for which the benefit of
    > > global access and easy deployment makes up for the lack in
    > > functionality, but statements like "At this point I think nobody
    > > should write desktop gui apps without a good reason" are simply
    > > ludicrously misguided.

    >
    > Well, I don't say that good reasons don't exist, I just see a lot of
    > desktop apps that could be done just as well as web apps, i.e. for
    > those, the good reason didn't exist.
    > --


    If you'd said "if you're making something really simple that has
    limited rich UI or data entry needs, consider a web application
    instead" I wouldn't have posted. A web application is something you
    make because the deployment and access benefits outweigh the UI and
    integration limitations, not as your default "go to" whenever you
    create an application.

    I'd like an example you have of a desktop application that could have
    just as easily been a web application. Bonus points if it's not a CRUD
    screen, and double bonus if you don't just handwave away things like
    file browsing. Although there are benefits even for the crud screen -
    I've written screens and applications for data entry professionals and
    they almost always prefer the speed optimizations you can make in a
    client application.
    Chris Mellon, Aug 6, 2007
    #15
  16. Paul Rubin Guest

    Re: Tkinter or wxpython?

    Paul Rubin <http://> writes:
    > > No native integration - no "open file", no "browse the filesystem", no
    > > rich drag and drop, no copy/paste.

    >
    > File i/o and file system browsing are available from javascript if the
    > user grants permission. File system browsing for the limited purpose
    > of file upload is available in regular html. Copy/paste of ordinary
    > text is always available. However, this type of requirement is what I
    > mean by a "good reason" to write a desktop gui. It applies to some
    > applications, not all.


    I should also add: there is also the possibility of running a Python
    program with an embedded http server on the same desktop as the
    browser, using the browser purely as a gui, but with the Python
    program having complete access to the file system and so forth. This
    could be seen as combining the disadvantages of both the remote web
    server approach (i.e. gui elements constrained by the browser) and the
    all-desktop approach (deployment issues). However, a lot of the time
    it's still just plain easier to do. Whenever I've written a desktop
    gui app I've always just been shocked at how much time goes into
    making the gui look decent and do the right stuff, even though none of
    mine have been even slightly slick (they've all been for industrial
    applications). When I do a web gui, it's been just a matter of
    tossing some html into a file or into some print statements, viewing
    it in a browser, and tweaking it a little as needed. Maybe that's
    mostly a matter of the lousy state of gui toolkits, and we actually
    need a toolkit that's more like an embedded browser. But we don't
    have that at the moment.
    Paul Rubin, Aug 6, 2007
    #16
  17. Paul Rubin Guest

    Re: Tkinter or wxpython?

    "Chris Mellon" <> writes:
    > > Might or might not matter for the application, especially considering
    > > that tkinter is part of the discussion.

    > The point is that you have no option with the browser - even Tkinter
    > has platform theming support now.


    Hmm, I don't know anything about that. I'm taking the view that for a
    lot of apps, the requirement is to just put some functionality on the
    screen, with slick visual appearance having little value or even
    negative value.

    > ...Gmail uses ajax instead of a page load when you start
    > typing a reply,


    I see, the answer to what caused your problem is approximately "ajax
    is evil", or alternatively, the gmail app attempts slickness with a
    tool that doesn't support slickness that well. OK, I can accept that
    using browsers for slick interfaces has its problems, but the answer
    (a lot of the time, not always) is to just decide you don't need
    slickness.

    > > File i/o and file system browsing are available from javascript if the
    > > user grants permission.

    > Which they won't (I don't even know how, from Firefox), so you can't
    > rely on it working.


    The application javascript pops a dialog asking for permission and the
    user clicks yes or no. If you can get them to install a desktop app
    (gah!!) then you can certainly get them to click yes in a browser.
    The permission mechanism is admittedly browser dependent.

    > But not of anything else. I've often wanted to drag & drop a file onto
    > the file upload box in gmail, for example.


    Well, ok, that's a slick feature that your app might need. None of
    mine have needed it so far.

    > How about something as simple as context menus?


    Unnecessary slickness for many apps. I've never needed it.

    > > Multiple windows are evil most of the time,

    > Multiple windows are the common case on the mac. They're not rare on
    > other platforms as well. The fact that your windows are constrained to
    > the browser and can't be torn off is a large limitation. No toolbars,
    > no palettes, no modal dialogs (except on IE, or if you constrain them
    > to the browser). Lots of unnecessary chrome on your extra windows, too
    > (see below).


    You can get rid of the chrome with javascript, but the extra windows
    are still usually evil and unnecessary. Just because they get used a
    lot doesn't change that. A heck of a lot of deployed interfaces, web
    or desktop, simply suck.

    > > > More platforms to develop on and test with.

    > > Compared to a desktop app? I don't think so.

    > Did you ever try counting? X browsers * Y browser versions * Z
    > platforms. There are javascript and CSS bugs and differences between
    > all of these.


    If you can tell them to install a desktop app, you can alternatively
    tell them what browser to use. For example we use a complicated
    firefox-only browser app where I work, that relies heavily on canvas
    objects. But if you write your application with straightforward html
    you tend to have very few platform problems.

    > From my own professional experience, it's not any easier
    > to account for browser differences than it is for platform
    > differences. It's getting better as more people jump on the web
    > bandwagon and CSS and JS abstraction libraries show up,


    I guess I see that stuff as mostly-evil and prefer straightforward
    html.

    > I'm not talking about chrome and slickness. I'm talking about basic
    > usability concerns like "will this work with a higher font size" and
    > "will it reflow in a sensible way if I change the window size". The
    > CSS box model works okay for text, it's not so good for widgets.


    I just haven't had this problem with HTML interfaces. I've never even
    used CSS, though that makes me a bit of a lamer. An interface that
    needs to fill the whole screen with widgets is probably too
    complicated.

    > More than a few web apps end up writing their own layout engines in
    > dynamic javascript. This is sad. While I'm talking about chrome, add
    > "wasted screenspace due to browser chrome" to a limitation of web
    > apps, again unless you write your own browser host. This is another
    > example of a feature that makes a good browser (don't let arbitrary
    > web pages mess with my web browser functionality) clashing with the
    > desires of a good application (don't waste screen space with
    > irrelevant functionality).


    I guess the term I'd use to describe all these effects is "slick" and
    a heck of a lot of the time it's just not needed. Anyway you can pop
    a chromeless browser window with a simple javascript call.

    > Man, you should be in PR with the way you spin things. You can't
    > implement anything except the most trivial of applications using only
    > the simple, familiar web elements like HTML forms. Anything more
    > complicated than that needs to be done with DHTML and probably AJAX,
    > and those UI elements don't look anything like the familiar ones. You
    > go in one breath from saying that you can implement dialogs in HTML to
    > saying that the rich client is the *less* familiar of the interfaces?


    I don't see the contradiction--with HTML you have just a few widgets
    that everyone understands and you get an interface that's almost
    always self-explanatory. Yes you could call those interfaces trivial,
    but the little secret that I'm trying to convey is that very often,
    trivial is all that's needed.

    > If you'd said "if you're making something really simple that has
    > limited rich UI or data entry needs, consider a web application
    > instead" I wouldn't have posted. A web application is something you
    > make because the deployment and access benefits outweigh the UI and
    > integration limitations, not as your default "go to" whenever you
    > create an application.


    Well, I could back off to somewhere between the two. Like, "ask
    yourself whether your application really needs a rich gui or complex
    data entry features. If you can get by with a simple HTML interface,
    and a lot of the time you can, you'll probably have an easier time
    doing it that way and that should be the default".

    > I'd like an example you have of a desktop application that could have
    > just as easily been a web application. Bonus points if it's not a CRUD
    > screen, and double bonus if you don't just handwave away things like
    > file browsing. Although there are benefits even for the crud screen -
    > I've written screens and applications for data entry professionals and
    > they almost always prefer the speed optimizations you can make in a
    > client application.


    I guess I've written 4 or 5 nontrivial desktop gui apps and ZERO of
    them had file browsing. One of them did need access to the pc's
    serial port, which means there had to be application code on the
    desktop, but the gui could have been a browser (talking to an
    application-embedded http server) if browsers were available in those
    days. Another one of them saved some state to a local file but it did
    that without file browsing, and could have instead saved the state on
    a remote server if it were written as a remote app.

    I'm not saying file browsing is never needed, just that from
    experimental observation, it's quite often not needed.

    Again, it all depends on what you're trying to do. For data entry
    stuff you probably want the data on a remote server anyway, and you
    can do basic CRUD validation with fairly simple javascript. Maybe
    that departs from pure HTML but it's nothing like the ajax/dhtml
    madness that causes the problems you've described.
    Paul Rubin, Aug 6, 2007
    #17
  18. Guest

    Re: Tkinter or wxpython?

    On Aug 6, 10:27 am, Kevin Walzer <> wrote:
    > Paul Rubin wrote:
    >
    > > Tkinteger (dang, I always end up typing it that way, I won't even
    > > bother fixing the error) is easy to use for simple gui's, and it's
    > > part of the standard python distro which for me is a big advantage (no
    > > extra crap to download). However, the widget set is rather ugly and
    > > doesn't blend in well with anyone's native widgets; the widget
    > > selection itself is rather narrow, and I think kyosohma may be right
    > > that it doesn't scale well to complex gui's. I've looked at the code
    > > for IDLE's gui and it's terrifying.

    >
    > It's entirely possible to make sophisticated GUI's in Tkinter, but you
    > are right, most people don't. Part of the issue is that Tkinter
    > developers haven't kept up with what's going on in Tk and instead use
    > outdated, ugly widget sets like Tix, PMW, and so on. Making use of the
    > available wrappers for current Tk libraries such as BWidgets, Tile,
    > Tablelist, TkTreeCtrl, and so on allows you to make UI's every bit as
    > polished as what comes with wxPython: tree views, multi-column lists,
    > notebook tabs, comboboxes, etc., with platform-specific theming
    > (XP/Vista, Aqua/OS X, and X11).
    >
    > For more references, see:
    >
    > http://tkinter.unpythonic.net/wiki/...lappnase.zexxo.net/TkinterTreectrl/index.html
    >
    >
    >
    >


    I tried the PMW widget toolkit. It was ok, but it seemed kind of
    buggy. I found out about Tix on a forum of some sort. When I tried to
    find out how to get it and use it, all I found was conflicting
    information. I finally got it downloaded only to find I had to compile
    it and I didn't have the right version of TCL. So I switched to
    wxPython then. Months later I found out that Tix is now included with
    Python.

    I still don't know how to use it though. As with most external Tkinter
    widget sets, Tix doesn't have examples. The docs look less inviting
    than man pages...but I realize that's probably just me. I just don't
    like man pages much.

    Thanks for the info though. You never know when you might need another
    toolkit for a specialized job.

    Mike
    , Aug 6, 2007
    #18
  19. Chris Mellon Guest

    Re: Tkinter or wxpython?

    On 06 Aug 2007 09:44:15 -0700, Paul Rubin
    <"http://phr.cx"@nospam.invalid> wrote:
    > "Chris Mellon" <> writes:
    > > > Might or might not matter for the application, especially considering
    > > > that tkinter is part of the discussion.

    > > The point is that you have no option with the browser - even Tkinter
    > > has platform theming support now.

    >
    > Hmm, I don't know anything about that. I'm taking the view that for a
    > lot of apps, the requirement is to just put some functionality on the
    > screen, with slick visual appearance having little value or even
    > negative value.
    >


    Define "functionality". From the rest of your posts, that seems to be
    limited to "press buttons" and "type small amounts of non-formatted
    text" on the interaction side and "display small amounts of simply
    formatted text" on the output side. I'm not denying that you can get
    by with this functionality in a large number of cases, but it's
    certainly not optimal in general. If it were, we'd all still be using
    VT100 terminals.

    > > ...Gmail uses ajax instead of a page load when you start
    > > typing a reply,

    >
    > I see, the answer to what caused your problem is approximately "ajax
    > is evil", or alternatively, the gmail app attempts slickness with a
    > tool that doesn't support slickness that well. OK, I can accept that
    > using browsers for slick interfaces has its problems, but the answer
    > (a lot of the time, not always) is to just decide you don't need
    > slickness.
    >


    What you're calling "slickness" is what other people call "usable".
    Obviously it could be done without the ajax, but you lose features and
    usability. It's slower, because it takes a full page load, and I lose
    the context of the discussion.

    > > > File i/o and file system browsing are available from javascript if the
    > > > user grants permission.

    > > Which they won't (I don't even know how, from Firefox), so you can't
    > > rely on it working.

    >
    > The application javascript pops a dialog asking for permission and the
    > user clicks yes or no. If you can get them to install a desktop app
    > (gah!!) then you can certainly get them to click yes in a browser.
    > The permission mechanism is admittedly browser dependent.
    >


    My out of the box firefox install simply denies the operation and
    raises a javascript error.

    > > But not of anything else. I've often wanted to drag & drop a file onto
    > > the file upload box in gmail, for example.

    >
    > Well, ok, that's a slick feature that your app might need. None of
    > mine have needed it so far.
    >
    > > How about something as simple as context menus?

    >
    > Unnecessary slickness for many apps. I've never needed it.
    >


    How have you decided that you've never needed it? Have you ever worked
    with a UI designer or workflow expert? Or have you just never bothered
    to implement it and you never heard anything from your users? How
    closely have you worked with the users of your applications?

    > > > Multiple windows are evil most of the time,

    > > Multiple windows are the common case on the mac. They're not rare on
    > > other platforms as well. The fact that your windows are constrained to
    > > the browser and can't be torn off is a large limitation. No toolbars,
    > > no palettes, no modal dialogs (except on IE, or if you constrain them
    > > to the browser). Lots of unnecessary chrome on your extra windows, too
    > > (see below).

    >
    > You can get rid of the chrome with javascript, but the extra windows
    > are still usually evil and unnecessary. Just because they get used a
    > lot doesn't change that. A heck of a lot of deployed interfaces, web
    > or desktop, simply suck.
    >


    As phishing attacks become more common, browsing are restricting the
    ability to remove or modify chrome. Again, a good feature for a
    browser, not so much for an application platform.

    > > > > More platforms to develop on and test with.
    > > > Compared to a desktop app? I don't think so.

    > > Did you ever try counting? X browsers * Y browser versions * Z
    > > platforms. There are javascript and CSS bugs and differences between
    > > all of these.

    >
    > If you can tell them to install a desktop app, you can alternatively
    > tell them what browser to use. For example we use a complicated
    > firefox-only browser app where I work, that relies heavily on canvas
    > objects. But if you write your application with straightforward html
    > you tend to have very few platform problems.
    >


    It depends on your target audience and deployment arena. The context
    is cross platform applications, so at least 2 browsers and at least 2
    platforms are required. Don't forget browser versioning, too - IE 5 is
    different than IE 6 is different than IE 7. Even "straightforward"
    HTML has non-trivial cross browser differences.

    > > From my own professional experience, it's not any easier
    > > to account for browser differences than it is for platform
    > > differences. It's getting better as more people jump on the web
    > > bandwagon and CSS and JS abstraction libraries show up,

    >
    > I guess I see that stuff as mostly-evil and prefer straightforward
    > html.
    >


    You simply can't do much of anything beyond display text and basic
    crud with straightforward HTML without stying. If that is the sole
    limit of your UI needs, then bully for you but that's hardly the
    common case and I'd venture that you don't have the experience to
    support the rather sweeping claim you made.

    > > I'm not talking about chrome and slickness. I'm talking about basic
    > > usability concerns like "will this work with a higher font size" and
    > > "will it reflow in a sensible way if I change the window size". The
    > > CSS box model works okay for text, it's not so good for widgets.

    >
    > I just haven't had this problem with HTML interfaces. I've never even
    > used CSS, though that makes me a bit of a lamer. An interface that
    > needs to fill the whole screen with widgets is probably too
    > complicated.
    >


    An application is not a book. Of course you fill the whole "screen"
    with widgets - your application is defined by the widgets that it has,
    and the amount of space those widgets take up is your screen space.

    > > More than a few web apps end up writing their own layout engines in
    > > dynamic javascript. This is sad. While I'm talking about chrome, add
    > > "wasted screenspace due to browser chrome" to a limitation of web
    > > apps, again unless you write your own browser host. This is another
    > > example of a feature that makes a good browser (don't let arbitrary
    > > web pages mess with my web browser functionality) clashing with the
    > > desires of a good application (don't waste screen space with
    > > irrelevant functionality).

    >
    > I guess the term I'd use to describe all these effects is "slick" and
    > a heck of a lot of the time it's just not needed. Anyway you can pop
    > a chromeless browser window with a simple javascript call.
    >
    > > Man, you should be in PR with the way you spin things. You can't
    > > implement anything except the most trivial of applications using only
    > > the simple, familiar web elements like HTML forms. Anything more
    > > complicated than that needs to be done with DHTML and probably AJAX,
    > > and those UI elements don't look anything like the familiar ones. You
    > > go in one breath from saying that you can implement dialogs in HTML to
    > > saying that the rich client is the *less* familiar of the interfaces?

    >
    > I don't see the contradiction--with HTML you have just a few widgets
    > that everyone understands and you get an interface that's almost
    > always self-explanatory. Yes you could call those interfaces trivial,
    > but the little secret that I'm trying to convey is that very often,
    > trivial is all that's needed.
    >


    That's simply not true, and I don't think you can objectively justify
    it. Besides, you specifically claimed HTML dialogs as being a
    replacement for "real" ones, and that can't be done using trivial
    interfaces. It requires DHTML, sometimes ajax, and/or browser support.

    > > If you'd said "if you're making something really simple that has
    > > limited rich UI or data entry needs, consider a web application
    > > instead" I wouldn't have posted. A web application is something you
    > > make because the deployment and access benefits outweigh the UI and
    > > integration limitations, not as your default "go to" whenever you
    > > create an application.

    >
    > Well, I could back off to somewhere between the two. Like, "ask
    > yourself whether your application really needs a rich gui or complex
    > data entry features. If you can get by with a simple HTML interface,
    > and a lot of the time you can, you'll probably have an easier time
    > doing it that way and that should be the default".
    >


    I would challenge the assumption that, starting from zero, it is less
    complicated to write a web application, much less a "pretend" web app
    using a local web server, than a desktop application using Tkinter
    (ick) or wxPython or pyQt. I would also challenge the assumption that
    'a lot of the time' you can get away with a simple HTML interface, at
    least by my personal definition of 'get away with'. I've worked a lot
    with data entry people, where the actual requirements in terms of
    slickness and flash are quite small. But "basic html" simply does not
    fit the bill. There is a real cost in terms of how fast and how
    accurately they can enter data in this environment.

    Moreover, if you *don't* need global access or zero-deployment
    (zero-deployment is always nice but most environments where you can
    reasonably force a specific browser and version also have IT
    infrastructure), then you should ask yourself if forcing your
    application in the web app model (I haven't even touched on the whole
    stateless HTTP being mapped to a stateful environment issue, or the
    need to manage the local web server) actually buys you anything. I
    simply do not buy the claim that HTML interfaces are necessarily
    simpler in any but the most trivial of cases, and even in those
    super-trivial applications there are often hidden concerns that don't
    filter up to management.

    > > I'd like an example you have of a desktop application that could have
    > > just as easily been a web application. Bonus points if it's not a CRUD
    > > screen, and double bonus if you don't just handwave away things like
    > > file browsing. Although there are benefits even for the crud screen -
    > > I've written screens and applications for data entry professionals and
    > > they almost always prefer the speed optimizations you can make in a
    > > client application.

    >
    > I guess I've written 4 or 5 nontrivial desktop gui apps and ZERO of
    > them had file browsing. One of them did need access to the pc's
    > serial port, which means there had to be application code on the
    > desktop, but the gui could have been a browser (talking to an
    > application-embedded http server) if browsers were available in those
    > days. Another one of them saved some state to a local file but it did
    > that without file browsing, and could have instead saved the state on
    > a remote server if it were written as a remote app.
    >


    Exactly how much time do you think using an HTML interface with an
    embedded server would have saved you, especially considering the
    careful care you have to take with access to the serial port? For the
    record, I've written over a dozen client applications, many of which I
    would consider trivial (but used features that would be expensive or
    impossible to implement in the browser) and probably twice that many
    web apps.

    > I'm not saying file browsing is never needed, just that from
    > experimental observation, it's quite often not needed.
    >


    Plural of anecdote and all that. Make a survey of every application
    that you interact with and see how many of them need to interact with
    arbitrary files from the filesystem.

    > Again, it all depends on what you're trying to do. For data entry
    > stuff you probably want the data on a remote server anyway, and you
    > can do basic CRUD validation with fairly simple javascript. Maybe
    > that departs from pure HTML but it's nothing like the ajax/dhtml
    > madness that causes the problems you've described.
    > --


    CRUD with javascript is something I actually have a lot of experience
    with. Deficiencies in the data entry UI have real consequences because
    you get invalid data and slow data entry speeds. The auto-completing
    combo-box, for example, is simply impossible in a browser without
    quite complicated (and slow) DHTML and is a huge boon for data entry.

    I'm not trying to claim that there are no benefits to web
    applications. But I often see people touting the web as a *superior
    application platform*, which is simply false, and as innately simpler
    to develop for, which is also false.
    Chris Mellon, Aug 6, 2007
    #19
  20. Kevin Walzer Guest

    Re: Tkinter or wxpython?

    wrote:

    >
    > I tried the PMW widget toolkit. It was ok, but it seemed kind of
    > buggy. I found out about Tix on a forum of some sort. When I tried to
    > find out how to get it and use it, all I found was conflicting
    > information. I finally got it downloaded only to find I had to compile
    > it and I didn't have the right version of TCL. So I switched to
    > wxPython then. Months later I found out that Tix is now included with
    > Python.
    >
    > I still don't know how to use it though. As with most external Tkinter
    > widget sets, Tix doesn't have examples. The docs look less inviting
    > than man pages...but I realize that's probably just me. I just don't
    > like man pages much.


    Tkinter comes more naturally to me than other toolkits because I'm also
    a Tcl developer. I just haven't felt the need to learn wxPython because
    I can get what I need from Tkinter, even the more complicated GUI layouts.

    --
    Kevin Walzer
    Code by Kevin
    http://www.codebykevin.com
    Kevin Walzer, Aug 6, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dietrich
    Replies:
    1
    Views:
    625
    Joe Smith
    Jul 22, 2004
  2. Dani
    Replies:
    3
    Views:
    465
  3. dotnet_ottawa
    Replies:
    1
    Views:
    679
    dotnet_ottawa
    Mar 11, 2010
  4. Iñaki Baz Castillo
    Replies:
    7
    Views:
    819
    Iñaki Baz Castillo
    Jan 12, 2010
  5. Moshe Katz
    Replies:
    2
    Views:
    133
    Moshe Katz
    May 2, 2004
Loading...

Share This Page