File handle not being released by close

[bg_ie@yahoo.com]

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(fil eNames,dir,file s):
def f1(a,dir=dir): return os.path.join(di r,a)
files2 = map(f1, files)
fileNames.exten d(files2)

fileNames = []
os.path.walk(di r,listAllFile,f ileNames)

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

if fileEnd == ".py":
print fileName
f=open(fileBegi nning+".tmp", 'w')
f.write("Hello" )
f.close

[Richard Brodie]

Re: File handle not being released by close


<bg_ie@yahoo.co mwrote in message
news:1185806160 .161748.58910@d 55g2000hsg.goog legroups.com...

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

Only if you call it ;)

[Eric Brunel]

Re: File handle not being released by close

On Mon, 30 Jul 2007 16:36:00 +0200, <bg_ie@yahoo.co mwrote:

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(fil eNames,dir,file s):
def f1(a,dir=dir): return os.path.join(di r,a)
files2 = map(f1, files)
fileNames.exten d(files2)
>
fileNames = []
os.path.walk(di r,listAllFile,f ileNames)
>
for fileName in fileNames:
fileBeginning = os.path.splitex t(fileName)[0]
fileEnd = os.path.splitex t(fileName)[1]
>
if fileEnd == ".py":
print fileName
f=open(fileBegi nning+".tmp", 'w')
f.write("Hello" )
f.close

f.close()

HTH...
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz 5(17l8(%,5.Z*(9 3-965$l7+-'])"

[Peter Otten]

Re: File handle not being released by close

bg_ie@yahoo.com 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(fileBegi nning+".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_stdo ut = sys.stdout.writ e
>>>
>>f(write_upper )

HELLO

>>f(write_to_st dout)

Hello>>>

Peter

[Gary Duzan]

Re: File handle not being released by close

In article <1185806160.161 748.58910@d55g2 000hsg.googlegr oups.com>,
<bg_ie@yahoo.co mwrote:

>
[ ... ]
>
>for fileName in fileNames:
fileBeginning = os.path.splitex t(fileName)[0]
fileEnd = os.path.splitex t(fileName)[1]
>
if fileEnd == ".py":
print fileName
f=open(fileBegi nning+".tmp", 'w')
f.write("Hello" )
f.close

f.close()

Gary Duzan
Motorola CHS

[Glenn Hutchings]

Re: Tkinter or wxpython?

On Aug 3, 1:00 am, "wang frank" <f...@hotmail.c o.jpwrote:

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

[kyosohma@gmail.com]

Re: Tkinter or wxpython?

On Aug 2, 7:00 pm, "wang frank" <f...@hotmail.c o.jpwrote:

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/msnjpqjl...gbl/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

[Paul Rubin]

Re: Tkinter or wxpython?

kyosohma@gmail. com 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.

[kyosohma@gmail.com]

Re: Tkinter or wxpython?

On Aug 6, 9:39 am, Paul Rubin <http://phr...@NOSPAM.i nvalidwrote:

kyoso...@gmail. com 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/post...x-ulation.html

Desktop apps have security issues too, of course.

Mike

[Chris Mellon]

Re: Tkinter or wxpython?

On 06 Aug 2007 07:39:12 -0700, Paul Rubin
<"http://phr.cx"@nospam. invalidwrote:

kyosohma@gmail. com 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.

[Paul Rubin]

Re: Tkinter or wxpython?

kyosohma@gmail. com 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/post...x-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]

Re: Tkinter or wxpython?

"Chris Mellon" <arkanes@gmail. comwrites:

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.

[kyosohma@gmail.com]

Re: Tkinter or wxpython?

On Aug 6, 9:58 am, "Chris Mellon" <arka...@gmail. comwrote:

On 06 Aug 2007 07:39:12 -0700, Paul Rubin
>
>
>
<"http://phr.cx"@nospam. invalidwrote:

kyoso...@gmail. com 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

[Kevin Walzer]

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

[Chris Mellon]

Re: Tkinter or wxpython?

On 06 Aug 2007 08:20:20 -0700, Paul Rubin
<"http://phr.cx"@nospam. invalidwrote:

"Chris Mellon" <arkanes@gmail. comwrites:

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.