date:20120712

On Thu, 12 Jul 2012 09:44:15 +, Alister wrote:

> On Wed, 11 Jul 2012 08:43:11 +0200, Daniel Fetchinson wrote:
> 
>>> funcs = [ lambda x: x**i for i in range( 5 ) ] 
[...]
> Having read Steve's explanation in the other thread (which I think has
> finally flipped the light switch on lambda for me) it only requires a
> minor change
> 
> funcs=[ lambda x,y=i:x**y for i in range(5) ]
> 
> although I cant actually think why this construct would be needed in
> practice, how are you actually using it

I would expect that the example given is just sample code demonstrating 
the problem. A slightly more realistic case might be something like 
defining a bunch of callbacks for, say, a GUI application.

For example, the good ol' calculator app, where you have ten buttons for 
digits 0-9. So you might give each button a callback function that 
inserts its own digit into the text field:

buttons = [make_button(name=str(i)) for i in range(10)]

That works fine. So now you go to add a callback to each one:

buttons = [make_button(name=str(i), callback=lambda: FIELD.insert(i))
   for i in range(10)]

and lo and behold, the ten buttons named "0" through "9" all insert 9. 
The reason is that the callback functions aren't given the value of i, 
but only the name[1] "i". By the time the callbacks are actually used, 
i == 9 and all the buttons share the same value.

[1] Technically closures may not store values by name, but the principle 
is sound: the function, when called later, looks up the current value of 
variable i, which is not necessarily the same as it was when the closure 
was originally defined.

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file




You are contradicting yourself. Either the OS is providing a fully
atomic rename or it doesn't. All POSIX compatible OS provide an atomic
rename functionality that renames the file atomically or fails without
loosing the target side. On POSIX OS it doesn't matter if the target exists.
This is not a contradiction. Although the rename operation is atomic, 
the whole "change status" process is not. It is because there are two 
operations: #1 delete old status file and #2. rename the new status 
file. And because there are two operations, there is still a race 
condition. I see no contradiction here.


You don't need locks or any other fancy stuff. You just need to make
sure that you flush the data and metadata correctly to the disk and
force a re-write of the directory inode, too. It's a standard pattern on
POSIX platforms and well documented in e.g. the maildir RFC.
It is not entirely true. We are talking about two processes. One is 
reading a file, another one is writting it. They can run at the same 
time, so flushing disk cache forcedly won't help.


--
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file




Renaming files is the wrong way to synchronize a
crawler.  Use a database that has ACID properties, such as
SQLite.  Far fewer I/O operations are required for small updates.
It's not the 1980s any more.
I agree with this approach. However, the OP specifically asked about 
"how to update status file".

--
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: PollyReports 1.5 -- Band-oriented PDF Report Generator

2012-07-12 Thread Chris Gonnerman

Apparently my test hasn't kept up with my update.  I'll get it revised 
soon and make a new release.


BTW... who is Simon?  I wrote the tutorial.  (Solomoriah is an old 
handle I still use a lot since it's less common than Chris.)


-- Chris.


On 07/12/2012 03:32 AM, Johann Spies wrote:
On 12 July 2012 10:27, Johann Spies > wrote:



I get the same error when running the example code from
Simon's tutorial (sample02 - sample07).


Thanks Simon for your tutorial.

Changing 'right = 1'  in all the example code to 'align = "right" '  
solved the problem.


I suspect the example code was not updated after recent changes.

Regards
Johann
--
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: PollyReports 1.5 -- Band-oriented PDF Report Generator

2012-07-12 Thread Rodrick Brown

On Jul 11, 2012, at 8:44 PM, Simon Cropper
 wrote:

> On 12/07/12 00:06, Chris Gonnerman wrote:
>> I've held off announcing this until I was sure it was really stable;
>> it's been 19 days since I made the last change to it, so here goes.
>> PollyReports is my Python module for report generation. It is designed
>> to be, quite literally, the "simplest thing that can possibly work" in
>> the field of PDF generation from a database record set.  There is a
>> somewhat vague resemblance to GeraldoReports; I had problems with
>> Geraldo's pagination which led me to develop PollyReports in a brief
>> flurry of intense activity.
>>
>> It's on PyPI: http://pypi.python.org/pypi/PollyReports
>> and on Github: https://github.com/Solomoriah/PollyReports
>> and I have a blog where I talk about it (like anyone cares):
>> http://opensource.gonnerman.org/?cat=4
>
> "I've noticed that acceptance of a new software module or package for 
> developers in the Open Source/Free Software world is greatly affected by the 
> availability of a good tutorial. I mean, it seems obvious, doesn't it? But 
> I've also noticed that the original author of a project rarely writes a good 
> tutorial." http://packages.python.org/PollyReports/tutorial.html
>

The author has made the code available on Git Hub so you can easily
contribute. Simple python classes and modules tend to be light on
providing examples or tutorials when the docstrings may be sufficient
for most.

> Well I thought it was a good tutorial. It certainly empowers me with enough 
> confidence to give it a try.
>
> That said... with more than a passing interest in software and content 
> licensing I looked at how the work was licensed. A none-standard license like 
> this makes most people stop and think "will this be a problem if I use this 
> in my work?" How compatible is your license with the main software licenses 
> currently available?
>

The BSD license has been around for many years even before GPL and
it's quite popular amongst the anti GNU crowd. I'm not sure what you
mean by non standard license?  Is because it's none GPL?

The BSD license is actually the most liberal open source license
format available when looking to integrate open source applications
into commercials ones. You're free to do as you will without tainting
your software or providing your modifications you've made.

> --
> Cheers Simon
>
>   Simon Cropper - Open Content Creator
>
>   Free and Open Source Software Workflow Guides
>   
>   Introduction   http://www.fossworkflowguides.com
>   GIS Packages   http://www.fossworkflowguides.com/gis
>   bash / Pythonhttp://www.fossworkflowguides.com/scripting
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file

2012-07-12 Thread Christian Heimes

Am 12.07.2012 14:30, schrieb Laszlo Nagy:
> This is not a contradiction. Although the rename operation is atomic,
> the whole "change status" process is not. It is because there are two
> operations: #1 delete old status file and #2. rename the new status
> file. And because there are two operations, there is still a race
> condition. I see no contradiction here.

Sorry, but you are wrong. It's just one operation that boils down to
"point name to a different inode". After the rename op the file name
either points to a different inode or still to the old name in case of
an error. The OS guarantees that all processes either see the first or
second state (in other words: atomic).

POSIX has no operation that actually deletes a file. It just has an
unlink() syscall that removes an associated name from an inode. As soon
as an inode has no names and is not references by a file descriptor, the
file content and inode is removed by the operating system. rename() is
more like a link() followed by an unlink() wrapped in a system wide
global lock.

> It is not entirely true. We are talking about two processes. One is
> reading a file, another one is writting it. They can run at the same
> time, so flushing disk cache forcedly won't help.

You need to flush the data to disk as well as the metadata of the file
and its directory in order to survive a system crash. The close()
syscall already makes sure that all data is flushed into the IO layer of
the operating system.

With POSIX semantics the reading process will either see the full
content before the rename op or the full content after the rename op.
The writing process can replace the name (rename op) while the reading
process reads the status file because its file descriptor still points
to the old status file.

Christian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file

2012-07-12 Thread Hans Mulder

On 12/07/12 14:30:41, Laszlo Nagy wrote:
>> You are contradicting yourself. Either the OS is providing a fully
>> atomic rename or it doesn't. All POSIX compatible OS provide an atomic
>> rename functionality that renames the file atomically or fails without
>> loosing the target side. On POSIX OS it doesn't matter if the target
>> exists.

> This is not a contradiction. Although the rename operation is atomic,
> the whole "change status" process is not. It is because there are two
> operations: #1 delete old status file and #2. rename the new status
> file. And because there are two operations, there is still a race
> condition. I see no contradiction here.

On Posix systems, you can avoid the race condition.  The trick is to
skip step #1.  The rename will implicitly delete the old file, and
it will still be atomic.  The whole process now consists of a single
stop, so the whole process is now atomic.

>> You don't need locks or any other fancy stuff. You just need to make
>> sure that you flush the data and metadata correctly to the disk and
>> force a re-write of the directory inode, too. It's a standard pattern on
>> POSIX platforms and well documented in e.g. the maildir RFC.

> It is not entirely true. We are talking about two processes. One is
> reading a file, another one is writting it. They can run at the same
> time, so flushing disk cache forcedly won't help.

On Posix systems, it will work, and be atomic, even if one process is
reading the old status file while another process is writing the new
one.  The old file will be atomically removed from the directory by
the rename operation; it will continue to exists on the hard drive, so
that the reading process can continue reading it.  The old file will
be deleted when the reader closes it.  Or, if the system crashed before
the old file is closed, it will deleted when the system is restarted.

On Windows, things are very different.

Hope this helps,

-- HansM

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: adding a simulation mode

One thing that I don't quite understand is why some calls even if I
catch the exception still makes the whole program quit.
For example this

try:
copytree('sjkdf', 'dsflkj')
Popen(['notfouhd'], shell=True)
except Exception as e:
print("here")


behaves differently from:

try:
Popen(['notfouhd'], shell=True)
copytree('sjkdf', 'dsflkj')
except Exception as e:
print("here")

because if copytree fails it quits anyway.
I also looked at the code but can't quite get why.. any idea?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: introduction and first question about multithreading

2012-07-12 Thread Dave Angel

On 07/11/2012 03:51 AM, Vojtěch Polášek wrote:
> Greetings,
> My name is Vojta and I am blind student. I am slowly learning Python for
> about 4 years and I like it alot, mostly its ability to run on various
> platforms.
> My primary system is Ubuntu 12.04, but I have Windows XP at hand. I am
> using python 2.7. I have learned basics from the book A byte of Python
> (for version 2.X) and something from Dive into Python. But most things I
> learned by trial and error and thanks to solutions on stackoverflow.com.
> I Don't know much about good programming concepts in Python, just in
> general, so feel free to educate me about them.
>
> I haven't created anything great yet, but I am working on a game for
> blind people. It is a simple game of reaction, but I have to start with
> something, my next plan is Sudoku game.
> I am using Pygame for handling of sounds and keyboard events, speech
> dispatcher under Linux and pyttsx under Windows to provide speech
> output, numpy for sound cutting and my two little and simple modules for
> providing menu system and unified interface for both speech engines.
> During the development, I discovered, that I have to use multithreading
> to be able to check for key presses and manage the game at the same
> time. I tried threading module but this wasn't enough for me, because
> function running in the separate thread needed to access variables in
> the main thread at least I couldn't find the way how to do that. So I
> switched to multiprocessing and started using pipes for communication
> between processes. All is working well, except for one thing.
> My menu module uses a loop to check for keyboard events through pygame.
> I don't import pygame into my module directly, but rather pass it
> through my main module like this:
> menu.pygame = pygame
> All was working well until I started using multiprocessing. I may have a
> probable cause but I need your help.
> In my main module I am running a similar loop for checking keyboard
> input in separate process. When a player loses, the loop finishes and I
> join the process. Then the menu module kicks in and should launch its
> own loop checking for pygame keyboard events, but right after doing it
> it prints:
> [xcb] Unknown sequence number while processing queue
> [xcb] Most likely this is a multi-threaded client and XInitThreads has
> not been called
> [xcb] Aborting, sorry about that.
> python: ../../src/xcb_io.c:273: poll_for_event: Assertion
> `!xcb_xlib_threads_sequence_lost' failed
> received SigAbrt - core dumped
> Are atachments allowed here? I can send you my whole code.
> Please help me, if you can.
> Thank you very much,
> Vojta

Welcome to python-list.  I'm glad you're enjoying Python.

I haven't used pygame, but I know that (like almost all GUI toolkits) it
uses an event loop for interacting with at least the keyboard.  You
should be able to add other code to that event loop in some manner,
without going to the trouble of either multiple threads or multiple
processes.

But I'll ignore that and talk about multithreading.  You say

>function running in the separate thread needed to access variables in
>the main thread at least I couldn't find the way how to do that

but there is nothing special about threads.  If you can figure out what
namespace a variable is in, you can access it.  In fact, one large
reason people switch from multithread to multiple processes is to avoid
the accidental reuse of variables.

As for posting large code, you can upload it to a site like  pastebin,
and put a link in your message here.  Don't expect too much, however, as
most of us are averse at looking at a large fragment of somebody else's
code.





-- 

DaveA

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: adding a simulation mode

One way instead that might actually work is this

def default_mock_action(func_name):
def _default_mock_action(*args, **kwargs):
print("running {} with args {} and {}".format(func_name, args, kwargs))

return _default_mock_action


def mock_fs_actions(to_run):
"""Take a function to run, and run it in an environment which
mocks all the possibly dangerous operations
"""
side_effect = [
'copytree',
'copy',
]

acts = dict((s, default_mock_action(s)) for s in side_effect)

with patch('pytest.runner.commands.ShellCommand.run',
default_mock_action('run')):
with patch.multiple('shutil', **acts):
to_run()


So I can just pass the main function inside the mock like
mock_fs_actions(main)

and it seems to do the job, but I have to list manually all the things
to mock and I'm not sure is the best idea anyway..
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: adding a simulation mode

2012-07-12 Thread John Gordon

In  andrea crotti 
 writes:

> try:
> copytree('sjkdf', 'dsflkj')
> Popen(['notfouhd'], shell=True)
> except Exception as e:
> print("here")

> behaves differently from:

> try:
> Popen(['notfouhd'], shell=True)
> copytree('sjkdf', 'dsflkj')
> except Exception as e:
> print("here")

> because if copytree fails it quits anyway.
> I also looked at the code but can't quite get why.. any idea?

copytree() could contain a call to sys.exit(), although that seems like
a rude thing to do.

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: PollyReports 1.5 -- Band-oriented PDF Report Generator

2012-07-12 Thread Chris Gonnerman

Wow, I posted this on Github weeks ago, and got no feedback; put it on 
PyPI at the same time, with the same results; but one day on the Python 
list and I have lots of excellent feedback.


I've just posted PollyReports 1.5.1, with no operational changes. The 
package includes a corrected testpolly.py file as well as corrected 
sample*.py files with "right = 1" changed to "align = 'right'".  The 
license information has been revised to include the text "BSD 2-Clause 
License" so that no one has to think about whether or not it's actually 
a BSD license.


If you downloaded the previous version, you don't really need the new 
one unless you're going through the tutorial.


Thanks!

-- Chris.

--
http://mail.python.org/mailman/listinfo/python-list

Re: adding a simulation mode

Well that's what I thought, but I can't find any explicit exit
anywhere in shutil, so what's going on there?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: adding a simulation mode

2012-07-12 Thread John Gordon

In  andrea crotti 
 writes:

> Well that's what I thought, but I can't find any explicit exit
> anywhere in shutil, so what's going on there?

Try catching SystemExit specifically (it doesn't inherit from Exception,
so "except Exception" won't catch it.)

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: adding a simulation mode

2012/7/12 John Gordon :
> In  andrea crotti 
>  writes:
>
>> Well that's what I thought, but I can't find any explicit exit
>> anywhere in shutil, so what's going on there?
>
> Try catching SystemExit specifically (it doesn't inherit from Exception,
> so "except Exception" won't catch it.)
>
> --

Ah yes that actually works, but I think is quite dodgy, why was it
done like this?
In shutil there is still no mention of SystemExit, and trying to raise
the single exceptions by and
doens't still make it exit, so I would still like to know how it is
possible just for curiosity..
-- 
http://mail.python.org/mailman/listinfo/python-list

PSF Python Brochure is ready to print: accepting ad orders now!

2012-07-12 Thread PSF Python Brochure Project Team

The PSF Python Brochure Project has finished the content and layout
phase. The first full format pre-production issues were shown at the
PSF booth during the EuroPython Conference 2012 in Florence, Italy,
and caused a lot of excitement - to print the brochure we now need
supporting sponsors.

Please visit our website for more information about the brochure
project:
http://brochure.getpython.info/

This announcement is also available for online reading:
http://brochure.getpython.info/news/newsletter-4-ready-to-print-and-order-now

The Python brochure is ready to print
=

Now is the time to place your ad in the brochure!

You can benefit from the PSF Python Brochure by buying ads or a
reference entry in the brochure, to e.g. show case your company for
recruiting purposes or consulting services. With over 10,000 printed
copies distributed world-wide this is an excellent way to reach out to
new developers and customers.

>>> Don't miss the opportunity to place your ad in the very first
>>> Python image brochure.

Ads
===

The brochure will have an addendum with 2 double pages for ads. You
can buy a half page or a full page ad.

You will receive a box of around 120 free copies of the printed
brochure after production.

We have already sold 4 ads. There is still room for up to 4 half page
ads.

Reference Entry
---

You can also buy a reference entry with a fixed layout on the last two
pages of the Python Brochure including your full color logo and
contact details. There is room for more than 30 entries.

Pricing
---

* A half page ad costs EUR 2,650.00 (+ 19% German VAT, if
applicable).

* A full page ad costs EUR 5,300.00 (+ 19% German VAT, if
applicable).

* A reference entry can be purchased for EUR 500.00 (+ 19% German
VAT, if applicable).

Ad Placement

We follow "first pay, first serve" until all ad slots are
booked. Subsequent orders will be placed on a waiting list for the
next edition.

Individual ad placement is not possible.

Deadline for Data & Approval

The deadline for data delivery will be 2012 August 31st.

You will receive a professional software proof PDF of your page prior
to printing with 2 days left for approval and final corrections.

For full technical details regarding data submission, formats and
specifications for the ad content, please consult our Ad Guidelines.

Ordering Procedure
==

For the order you will be redirected to the secure SSL encrypted site
hosted by our production partner evenios publishing. The terms &
conditions and data privacy statement for the order are published on
encrypted.evenios.com .

Please note that the payment is not processed by the PSF! You will
receive an invoice issued by evenios publishing, the company producing
and distributing the brochure.

Order a half page ad

https://encrypted.evenios.com/en/mediadata/cart/order-forms/ad-sponsorship-order-form-1-2-page

Order a full page ad

https://encrypted.evenios.com/en/mediadata/cart/order-forms/ad-sponsorship-order-form-1-1-page

Order a reference entry sponsorship
---
https://encrypted.evenios.com/en/mediadata/cart/order-forms/reference-sponsorship-entry-order-form

Thanks,
--
Marc-Andre Lemburg
PSF Python Brochure Team
___
>>> Website:http://brochure.getpython.info/
>>> Twitter: https://twitter.com/pythonbrochure
>>> EMail: broch...@getpython.info
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file

2012-07-12 Thread Ross Ridge

Laszlo Nagy:
> This is not a contradiction. Although the rename operation is atomic,
> the whole "change status" process is not. It is because there are two
> operations: #1 delete old status file and #2. rename the new status
> file. And because there are two operations, there is still a race
> condition. I see no contradiction here.

Christian Heimes   wrote:
>Sorry, but you are wrong. It's just one operation that boils down to
>"point name to a different inode".

For some reason you're assuming POSIX semantics, an assumption that
Laszlo Nagy did not make.

Ross Ridge

-- 
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  rri...@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: lambda in list comprehension acting funny

2012-07-12 Thread Ian Kelly

On Wed, Jul 11, 2012 at 9:59 PM, Steven D'Aprano
 wrote:
> On Wed, 11 Jul 2012 08:41:57 +0200, Daniel Fetchinson wrote:
>
>> funcs = [ lambda x: x**i for i in range( 5 ) ]
>
> Here's another solution:
>
> from functools import partial
> funcs = [partial(lambda i, x: x**i, i) for i in range(5)]
>
>
> Notice that the arguments i and x are defined in the opposite order.
> That's because partial only applies positional arguments from the left.
> If there was a "right partial" that applies from the right, we could use
> the built-in instead:
>
> funcs = [rpartial(pow, i) for i in range(5)]

You know, partial does handle keyword arguments correctly:

funcs = [partial(lambda x, i: x ** i, i=i) for i in range(5)]

This might be bad practice though if there are other arguments to the
right of the keywords that the eventual caller might want to specify,
as those arguments would then effectively be keyword-only.  The error
message in that case is not particularly illuminating, either:

>>> def f(a, b, c):
...   return (a, b, c)
...
>>> g = partial(f, b=42)
>>> g(3, 14)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: f() got multiple values for keyword argument 'b'

It would be a bit clearer if it instead noted that 'c' were
keyword-only in the 'g' argspec.

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: lambda in list comprehension acting funny

2012-07-12 Thread Rotwang


On 12/07/2012 04:59, Steven D'Aprano wrote:

On Wed, 11 Jul 2012 08:41:57 +0200, Daniel Fetchinson wrote:


funcs = [ lambda x: x**i for i in range( 5 ) ]


Here's another solution:

from functools import partial
funcs = [partial(lambda i, x: x**i, i) for i in range(5)]


Notice that the arguments i and x are defined in the opposite order.
That's because partial only applies positional arguments from the left.
If there was a "right partial" that applies from the right, we could use
the built-in instead:

funcs = [rpartial(pow, i) for i in range(5)]


I don't think anyone has suggested this yet:

funcs = [(lambda i: lambda x: x**i)(i) for i in range(5)]

It's a bit more opaque than other solutions, but it fits in one line and 
avoids defining functions with an implicit second argument, if that's 
desirable for some reason.



--
I have made a thing that superficially resembles music:

http://soundcloud.com/eroneity/we-berated-our-own-crapiness
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file




Sorry, but you are wrong. It's just one operation that boils down to
"point name to a different inode". After the rename op the file name
either points to a different inode or still to the old name in case of
an error. The OS guarantees that all processes either see the first or
second state (in other words: atomic).

POSIX has no operation that actually deletes a file. It just has an
unlink() syscall that removes an associated name from an inode. As soon
as an inode has no names and is not references by a file descriptor, the
file content and inode is removed by the operating system. rename() is
more like a link() followed by an unlink() wrapped in a system wide
global lock.

Then please help me understand this.

"Good" case:

process #1:  unlink(old status file)
process #1: rename(new status file)
process#2: open(new status file)
process#2: read(new status file)

"Bad" case:

process #1:  unlink(old status file)
process#2: open(???) -- there is no file on disk here, this system call 
returns with an error!

process #1: rename(new status file)

If it would be possible to rename + unlink in one step, then it would be 
okay. Can you please explain what am I missing?


--
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file




This is not a contradiction. Although the rename operation is atomic,
the whole "change status" process is not. It is because there are two
operations: #1 delete old status file and #2. rename the new status
file. And because there are two operations, there is still a race
condition. I see no contradiction here.

On Posix systems, you can avoid the race condition.  The trick is to
skip step #1.  The rename will implicitly delete the old file, and
it will still be atomic.  The whole process now consists of a single
stop, so the whole process is now atomic.
Well, I didn't know that this is going to work. At least it does not 
work on Windows 7 (which should be POSIX compatible?)


>>> f = open("test.txt","wb+")
>>> f.close()
>>> f2 = open("test2.txt","wb+")
>>> f2.close()
>>> import os
>>> os.rename("test2.txt","test.txt")
Traceback (most recent call last):
  File "", line 1, in 
WindowsError: [Error 183] File already exists
>>>

I have also tried this on FreeBSD and it worked.

Now, let's go back to the original question:


This works well on Linux but Windows raises an error when status_file already 
exists.


It SEEMS that the op wanted a solution for Windows


--
http://mail.python.org/mailman/listinfo/python-list

syntax error message

2012-07-12 Thread John Magness

Using Python 3.2.3
In shell I made a simple program; dog=2,cat=3,cow=dog+cat
Entered cow and received 5 as answer
Saved-as Trial-1.py in a user folder
Went to folder and select "edit with shell" for that file
Trial-1.py displayed, clicked save, run and then run module to activate program
got message in box "syntax error" and after I clicked OK the #2 in the heading 
Python 3.2.3 was high-lighted
 in red and the "or" and "for" words were changed to red letters and program 
seems to be text only.
In other words, I am not able to re-use or change the program

Help needed.
John, a beginner-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file




Windows doesn't suppport atomic renames if the right side exists.  I
suggest that you implement two code paths:

if os.name == "posix":
 rename = os.rename
else:
 def rename(a, b):
 try:
 os.rename(a, b)
 except OSError, e:
 if e.errno != 183:
 raise
 os.unlink(b)
 os.rename(a, b)


Problem is if the process is stopped between unlink and rename there
would no status file.
Yes, and actually it does not need to be an abnormal termination. It is 
enough if the OS scheduler puts this process on hold for some time...


But using a lock file, the problem can be solved. However in that case, 
reading a status file can be a blocking operation.

--
http://mail.python.org/mailman/listinfo/python-list

Re: syntax error message

2012-07-12 Thread MRAB


On 12/07/2012 18:48, John Magness wrote:

Using Python 3.2.3
In shell I made a simple program; dog=2,cat=3,cow=dog+cat
Entered cow and received 5 as answer
Saved-as Trial-1.py in a user folder
Went to folder and select "edit with shell" for that file
Trial-1.py displayed, clicked save, run and then run module to activate
program
got message in box "syntax error" and after I clicked OK the #2 in the
heading Python 3.2.3 was high-lighted
  in red and the "or" and "for" words were changed to red letters and
program seems to be text only.
In other words, I am not able to re-use or change the program
Help needed.
John, a beginner


You were entering it in interactive mode. When you saved it as
"Trial-1.py" what you actually saved was all of the prompts and the
output, which isn't a valid program (it has lots of other bits mixed in
with it).

If you click File->New Window you will get an empty window into which
you can type your program.

You can just open the file and then edit it to remove the unwanted bits.
--
http://mail.python.org/mailman/listinfo/python-list

Re: adding a simulation mode

2012-07-12 Thread Dieter Maurer

andrea crotti wrote at 2012-7-12 14:20 +0100:
>One thing that I don't quite understand is why some calls even if I
>catch the exception still makes the whole program quit.
>For example this
>
>try:
>copytree('sjkdf', 'dsflkj')
>Popen(['notfouhd'], shell=True)
>except Exception as e:
>print("here")
>
>
>behaves differently from:
>
>try:
>Popen(['notfouhd'], shell=True)
>copytree('sjkdf', 'dsflkj')
>except Exception as e:
>print("here")
>
>because if copytree fails it quits anyway.
>I also looked at the code but can't quite get why.. any idea?

There are ways to quit a program immediately without giving
exception handlers a chance to intervene -- though Python does
not make this easy.

Your code above should not do this. If it does, there is likely a bug.


You told us, that the two alternatives above behaved differently --
I expect 'behaved differently with respect to the printing of "here"'.
If you tell us, which alternative printed "here" and which did not,
we would be able to deduce which of the "Popen" or "copytree"
caused the immediate exit.

"Popen" might contain a call to "os._exit" (one of the ways to immediately
quit) -- though it should only call it in the forked child not in the
calling process. "coyptree" might under exceptional circumstances (extremely
deeply nested structures -- surely not for non-existent source and target)
cause a stack overflow (which, too, can lead to immediate death).


In addition, "Popen" and maybe even "copytree" may call platform
dependent functions. Thus, platform information could be relevant.

Under "*nix", you should be able to get some information from
the exit code of a suddenly quiting process. It tells whether
the process died from a fatal signal (a stack overflow would
result in the fatal SIGSEGV) or whether it existed willingly with
an exit code.

--
Dieter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file

2012-07-12 Thread Christian Heimes

Am 12.07.2012 19:43, schrieb Laszlo Nagy:
> Well, I didn't know that this is going to work. At least it does not
> work on Windows 7 (which should be POSIX compatible?)

Nope, Windows's file system layer is not POSIX compatible. For example
you can't remove or replace a file while it is opened by a process.
Lot's of small things work slightly differently on Windows or not at all.

Christian

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file

2012-07-12 Thread Rick Johnson

On Jul 12, 2:39 pm, Christian Heimes  wrote:
> Windows's file system layer is not POSIX compatible. For example
> you can't remove or replace a file while it is opened by a process.

Sounds like a reasonable fail-safe to me. Not much unlike a car
ignition that will not allow starting the engine if the transmission
is in any *other* gear besides "park" or "neutral", OR a governor (be
it mechanical or electrical) that will not allow the engine RPMs to
exceed a maximum safe limit, OR even, ABS systems which "pulse" the
brakes to prevent overzealous operators from loosing road-to-tire
traction when decelerating the vehicle.

You could say: "Hey, if someone is dumb enough to shoot themselves in
the foot then let them"... however, sometimes fail-safes not only save
the dummy from a life of limps, they also prevent catastrophic
"collateral damage" to rest of us.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and Qt4 Designer

2012-07-12 Thread Vincent Vande Vyvre

On 12/07/12 08:42, Jean Dubois wrote:
> On 12 jul, 02:59, Vincent Vande Vyvre 
> wrote:
>> On 11/07/12 17:37, Jean Dubois wrote:
>>
>>
>>
>>
>>
>>
>>
>>> I'm trying to combine python-code made with QT4 designer with plain
>>> python statements like
>>> file = open("test","w")
>>> Can anyone tell me what I have to  add to the following code just to
>>> open a file when clicking on the load-button and closing it by
>>> clicking on the save button.
>>> #!/usr/bin/env python
>>> # -*- coding: utf-8 -*-
>>> # Form implementation generated from reading ui file 'test.ui'
>>> #
>>> # Created: Wed Jul 11 17:21:35 2012
>>> #  by: PyQt4 UI code generator 4.8.3
>>> #
>>> # WARNING! All changes made in this file will be lost!
>>> from PyQt4 import QtCore, QtGui
>>> try:
>>> _fromUtf8 = QtCore.QString.fromUtf8
>>> except AttributeError:
>>> _fromUtf8 = lambda s: s
>>> class Ui_Form(object):
>>> def setupUi(self, Form):
>>> Form.setObjectName(_fromUtf8("Form"))
>>> Form.resize(400, 300)
>>> self.widget = QtGui.QWidget(Form)
>>> self.widget.setGeometry(QtCore.QRect(10, 20, 146, 25))
>>> self.widget.setObjectName(_fromUtf8("widget"))
>>> self.horizontalLayout = QtGui.QHBoxLayout(self.widget)
>>> self.horizontalLayout.setMargin(0)
>>> self.horizontalLayout.setObjectName(_fromUtf8("horizontalLayout"))
>>> self.pushButton_2 = QtGui.QPushButton(self.widget)
>>> self.pushButton_2.setObjectName(_fromUtf8("pushButton_2"))
>>> self.horizontalLayout.addWidget(self.pushButton_2)
>>> self.pushButton = QtGui.QPushButton(self.widget)
>>> self.pushButton.setObjectName(_fromUtf8("pushButton"))
>>> self.horizontalLayout.addWidget(self.pushButton)
>>> self.retranslateUi(Form)
>>> QtCore.QMetaObject.connectSlotsByName(Form)
>>> def retranslateUi(self, Form):
>>> Form.setWindowTitle(QtGui.QApplication.translate("Form",
>>> "Form", None, QtGui.QApplication.UnicodeUTF8))
>>> self.pushButton_2.setText(QtGui.QApplication.translate("Form",
>>> "Save file", None, QtGui.QApplication.UnicodeUTF8))
>>> self.pushButton.setText(QtGui.QApplication.translate("Form",
>>> "Load file", None, QtGui.QApplication.UnicodeUTF8))
>>> if __name__ == "__main__":
>>> import sys
>>> app = QtGui.QApplication(sys.argv)
>>> Form = QtGui.QWidget()
>>> ui = Ui_Form()
>>> ui.setupUi(Form)
>>> Form.show()
>>> sys.exit(app.exec_())
>>> thanks in advance
>>> jean
>> Connect the signal clicked of your's buttons to your's functions.
>>
>> self.pushButton.clicked.connect(self.my_func)
>>
>> Here's all the truth:
>>
>> http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/new_style_...
>>
>> --
>> Vincent V.V.
>> Oqapy  . Qarte+7
>>  . PaQager 
> thanks for the reference, could you just supply a small example for
> the code above to get me started?
>
> thanks in advance
> jean
Just add the connection at the end of the Ui_Form class and, of course,
your function.

You can find numbers of examples in your PyQt4 install folder.
On my machine is located at /usr/share/doc/python-qt4-doc/examples

And, for more inspiration, have a look at this site:
   http://diotavelli.net/PyQtWiki/

-- 
Vincent V.V.
Oqapy  . Qarte
 . PaQager 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file

On Thu, 12 Jul 2012 15:05:26 +0200, Christian Heimes wrote:

> You need to flush the data to disk as well as the metadata of the file
> and its directory in order to survive a system crash. The close()
> syscall already makes sure that all data is flushed into the IO layer of
> the operating system.

And some storage devices (e.g. hard drives, USB sticks) don't actually 
write data permanently even when you sync the device. They just write to 
a temporary cache, then report that they are done (liar liar pants on 
fire). Only when the cache is full, or at some random time at the 
device's choosing, do they actually write data to the physical media. 

The result of this is that even when the device tells you that the data 
is synched, it may not be.

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: adding a simulation mode

On Thu, 12 Jul 2012 15:17:03 +0100, andrea crotti wrote:

> Well that's what I thought, but I can't find any explicit exit anywhere
> in shutil, so what's going on there?

Hard to say, since you don't give any context to your question.

When replying to posts, please leave enough quoted to establish context. 
Neither email nor usenet are guaranteed delivery services, and they 
certainly don't guarantee to deliver messages in order. Assume that your 
readers may not have seen the message you are replying to, and you will 
probably get more and better responses.

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file

2012-07-12 Thread Chris Angelico

On Fri, Jul 13, 2012 at 11:20 AM, Rick Johnson
 wrote:
> On Jul 12, 2:39 pm, Christian Heimes  wrote:
>> Windows's file system layer is not POSIX compatible. For example
>> you can't remove or replace a file while it is opened by a process.
>
> Sounds like a reasonable fail-safe to me.

POSIX says that files and file names are independent. I can open a
file based on its name, delete the file based on its name, and still
have the open file there. When it's closed, it'll be wiped from the
disk.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: adding a simulation mode

On Thu, 12 Jul 2012 16:37:42 +0100, andrea crotti wrote:

> 2012/7/12 John Gordon :
>> In  andrea crotti
>>  writes:
>>
>>> Well that's what I thought, but I can't find any explicit exit
>>> anywhere in shutil, so what's going on there?
>>
>> Try catching SystemExit specifically (it doesn't inherit from
>> Exception, so "except Exception" won't catch it.)
>>
> 
> Ah yes that actually works, but I think is quite dodgy, why was it done
> like this?

Built-in exceptions SystemExit, KeyboardInterrupt and GeneratorExit 
deliberately do not inherit from Exception since they are not meant to be 
caught by "catch-all" try...except Exception clauses.

You can see the exception hierarchy here:

http://docs.python.org/library/exceptions.html#exception-hierarchy

Please do NOT catch BaseException, since that is the wrong thing to do. 
If you must catch SystemExit, KeyboardInterrupt, etc. they you should do 
so as separate catch clauses:

try:
main()
except SystemExit as e:
print(e)  # see if we can find out who is raising this
except KeyboardInterrupt:
print("Mwahahaha my pretty, you cannot cancel this!!!")
print("...er, now what do I do?")
except Exception:
print("why am I catching exceptions I can't recover from?")

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: adding a simulation mode

On Thu, 12 Jul 2012 14:20:18 +0100, andrea crotti wrote:

> One thing that I don't quite understand is why some calls even if I
> catch the exception still makes the whole program quit.

Without seeing your whole program, we can't possibly answer this. But by 
consulting my crystal ball, I bet you have something like this:

try:
do_stuff()  # run your program
except Exception as e:
# pointlessly catch exceptions I can't handle, which has the
# bonus of making debugging MUCH MUCH harder
print("here")
# end of file, nothing further to do

When do_stuff() fails, "here" gets printed, and then the program exits 
because there's nothing else to do.

Catching exceptions doesn't magically cause the code to continue from the 
point of the error. It doesn't work like that. Execution skips from where 
the error occurred to the except clause. Once the except clause has run, 
anything following the except clause runs, and then the program ends as 
normal.

If you haven't already done so, I recommend you go through the tutorial:

http://docs.python.org/py3k/tutorial/index.html

in particular the part about exception handling:

http://docs.python.org/py3k/tutorial/errors.html

> For example this
> 
> try:
> copytree('sjkdf', 'dsflkj')
> Popen(['notfouhd'], shell=True)
> except Exception as e:
> print("here")

What is "Popen" and where is it from?

My first guess was os.popen, but that doesn't take a shell argument:

py> os.popen(['ls', '-l'], shell=True)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: popen() got an unexpected keyword argument 'shell'

> behaves differently from:
> 
> try:
> Popen(['notfouhd'], shell=True)
> copytree('sjkdf', 'dsflkj')
> except Exception as e:
> print("here")
> 
> because if copytree fails it quits anyway. 

Well of course it does. If copytree fails, the try block ends and 
execution skips straight to the except block, which runs, and then the 
program halts because there's nothing else to be done.

That at least is my guess, based on the described symptoms.

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file

On Fri, 13 Jul 2012 12:12:01 +1000, Chris Angelico wrote:

> On Fri, Jul 13, 2012 at 11:20 AM, Rick Johnson
>  wrote:
>> On Jul 12, 2:39 pm, Christian Heimes  wrote:
>>> Windows's file system layer is not POSIX compatible. For example you
>>> can't remove or replace a file while it is opened by a process.
>>
>> Sounds like a reasonable fail-safe to me.

Rick has obviously never tried to open a file for reading when somebody 
else has it opened, also for reading, and discovered that despite Windows 
being allegedly a multi-user operating system, you can't actually have 
multiple users read the same files at the same time.

(At least not unless the application takes steps to allow it.)

Or tried to back-up files while some application has got them opened. Or 
open a file while an anti-virus scanner is oh-so-slowly scanning it.

Opening files for exclusive read *by default* is a pointless and silly 
limitation. It's also unsafe: if a process opens a file for exclusive 
read, and then dies, *no other process* can close that file.

At least on POSIX systems, not even root can override a mandatory 
exclusive lock (it would be pretty pointless if it could), so a rogue or 
buggy program could wreck havoc with mandatory exclusive file locks. 
That's why Linux, by default, treats exclusive file locks as advisory 
(cooperative), not mandatory.

In general, file locking is harder than it sounds, with many traps for 
the unwary, and of course the semantics are dependent on both the 
operating system and the file system.

https://en.wikipedia.org/wiki/File_locking

> POSIX says that files and file names are independent. I can open a file
> based on its name, delete the file based on its name, and still have the
> open file there. When it's closed, it'll be wiped from the disk.

One neat trick is to open a file, then delete it from disk while it is 
still open. So long as your process is still running, you can write to 
this ghost file, as normal, but no other process can (easily) see it. And 
when your process ends, the file contents is automatically deleted.

This is remarkably similar to what Python does with namespaces and dicts:

# create a fake "file system"
ns = {'a': [], 'b': [], 'c': []}
# open a file
myfile = ns['a']
# write to it
myfile.append('some data')
# delete it from the "file system"
del ns['a']
# but I can still read and write to it
myfile.append('more data')
print(myfile[0])
# but anyone else will get an error if they try
another_file = ns['a']

-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file

2012-07-12 Thread Gene Heskett

On Thursday 12 July 2012 23:21:16 Steven D'Aprano did opine:

> On Fri, 13 Jul 2012 12:12:01 +1000, Chris Angelico wrote:
> > On Fri, Jul 13, 2012 at 11:20 AM, Rick Johnson
> > 
> >  wrote:
> >> On Jul 12, 2:39 pm, Christian Heimes  wrote:
> >>> Windows's file system layer is not POSIX compatible. For example you
> >>> can't remove or replace a file while it is opened by a process.
> >> 
> >> Sounds like a reasonable fail-safe to me.
> 
> Rick has obviously never tried to open a file for reading when somebody
> else has it opened, also for reading, and discovered that despite
> Windows being allegedly a multi-user operating system, you can't
> actually have multiple users read the same files at the same time.
> 
Chuckle.  That was one of the 'features' that os9 on the trs-80 color 
computer had back in the 80's, and it was clean and well done because of 
the locking model the random block file manager had in OS9 for 6809 cpu's, 
no relation to the Mac OS9 other than a similar name.  That color computer 
has a separate, text only video card I could plug in and display on an 80 
column amber screen monitor.

When I wanted to impress the visiting frogs, I often did something I have 
never been able to do on any other operating system since, start assembling 
a long assembly language file on one of the screens on the color monitor, 
hit the clear key to advance to the amber screen and start a listing on it 
of the assemblers output listing file.

Because the file locking was applied only to the sector (256 bytes on that 
machine) being written at the instant, the listing would fly by till it 
caught up with the assemblers output, running into the lock and then 
dutifully following along, one sector behind the assemblers output, until 
the assembly was finished.  That was in 1986 folks, and in the year of our 
Lord 2012, 26 years later, I still cannot do that in linux.  When I ask why 
not, the replies seem to think I'm from outer space.  Its apparently a 
concept that is not even attempted to be understood by the linux code 
carvers.

Something is drastically wrong with that picture IMO.

> (At least not unless the application takes steps to allow it.)
> 
> Or tried to back-up files while some application has got them opened.

That in fact, ran me out of the amiga business in 1999, a 30Gb drive failed 
on my full blown 040 + 64 megs of dram A2000.  When the warranty drive 
arrived is when I found that due to file locks on the startup files, all of 
them involved with the booting of that machine, my high priced Diavolo Pro 
backup tapes didn't contain a single one of those files.  The linux box 
with Red Hat 5.0 on it that I had built in late 1998 to see what linux was 
all about found space under that desk yet that evening and I never looked 
back.

> Or
> open a file while an anti-virus scanner is oh-so-slowly scanning it.
> 
> Opening files for exclusive read *by default* is a pointless and silly
> limitation. It's also unsafe: if a process opens a file for exclusive
> read, and then dies, *no other process* can close that file.
> 
> At least on POSIX systems, not even root can override a mandatory
> exclusive lock (it would be pretty pointless if it could), so a rogue or
> buggy program could wreck havoc with mandatory exclusive file locks.
> That's why Linux, by default, treats exclusive file locks as advisory
> (cooperative), not mandatory.
> 
> In general, file locking is harder than it sounds, with many traps for
> the unwary, and of course the semantics are dependent on both the
> operating system and the file system.
> 
> https://en.wikipedia.org/wiki/File_locking
> 
> > POSIX says that files and file names are independent. I can open a
> > file based on its name, delete the file based on its name, and still
> > have the open file there. When it's closed, it'll be wiped from the
> > disk.
> 
> One neat trick is to open a file, then delete it from disk while it is
> still open. So long as your process is still running, you can write to
> this ghost file, as normal, but no other process can (easily) see it.
> And when your process ends, the file contents is automatically deleted.
> 
> This is remarkably similar to what Python does with namespaces and
> dicts:
> 
> # create a fake "file system"
> ns = {'a': [], 'b': [], 'c': []}
> # open a file
> myfile = ns['a']
> # write to it
> myfile.append('some data')
> # delete it from the "file system"
> del ns['a']
> # but I can still read and write to it
> myfile.append('more data')
> print(myfile[0])
> # but anyone else will get an error if they try
> another_file = ns['a']

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
You just wait, I'll sin till I blow up!
-- Dylan Thomas
-- 
http://mail.python.org/mailman/listinfo/python-list

Writing a wrapper - any tips?

2012-07-12 Thread Temia Eszteri

I'm going to be looking into writing a wrapper for the Allegro 5 game
development libraries, either with ctypes or Cython. They technically
have a basic 1:1 ctypes wrapper currently, but I wanted to make
something more pythonic, because it'd be next to impossible to deal
with the memory management cleanly in the script itself.

Anything I should keep in mind? Any tips to pass on to a first-time
module writer, pitfalls to watch out for, etc.?

~Temia

P.S. I know another game development library, SDL, was wrapped for
Python in the form of Pygame, but I *really* don't like SDL.
-- 
The amazing programming device: fuelled entirely by coffee, it codes while
awake and tests while asleep!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file

On Thu, 12 Jul 2012 23:49:02 -0400, Gene Heskett wrote:

> When I wanted to impress the visiting frogs, I often did something I
> have never been able to do on any other operating system since, start
> assembling a long assembly language file on one of the screens on the
> color monitor, hit the clear key to advance to the amber screen and
> start a listing on it of the assemblers output listing file.
> 
> Because the file locking was applied only to the sector (256 bytes on
> that machine) being written at the instant, the listing would fly by
> till it caught up with the assemblers output, running into the lock and
> then dutifully following along, one sector behind the assemblers output,
> until the assembly was finished.  That was in 1986 folks, and in the
> year of our Lord 2012, 26 years later, I still cannot do that in linux. 

Um, what you are describing sounds functionally equivalent to what 
tail -f does.


> When I ask why not, the replies seem to think I'm from outer space.  Its
> apparently a concept that is not even attempted to be understood by the
> linux code carvers.

You could certainly create a pair of cooperative programs, one which 
keeps a lock on only the last block of the file, and a tail-like reader 
which honours that lock. But why bother? Just have the assembler append 
to the file, and let people use any reader they like, such as tail.

Or have I misunderstood you?



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file

2012-07-12 Thread rantingrickjohnson

On Thursday, July 12, 2012 10:13:47 PM UTC-5, Steven D'Aprano wrote:
> Rick has obviously never tried to open a file for reading when somebody 
> else has it opened, also for reading, and discovered that despite Windows 
> being allegedly a multi-user operating system, you can't actually have 
> multiple users read the same files at the same time.

You misread my response. My comment was direct result of Christian stating:

(paraphrase) "On some systems you are not permitted to delete a file whilst the 
file is open "

...which seems to be consistent to me. Why would *anybody* want to delete a 
file whilst the file is open? Bringing back the car analogy again: Would you 
consider jumping from a moving vehicle a consistent interaction with the 
interface of a vehicle? Of course not. The interface for a vehicle is simple 
and consistent:

 1. You enter the vehicle at location A
 2. The vehicle transports you to location B
 3. You exit the vehicle

At no time during the trip would anyone expect you to leap from the vehicle. 
But when you delete open files, you are essentially leaping from the moving 
vehicle! This behavior goes against all expectations of consistency in an API 
-- and against all sanity when riding in a vehicle!

> Opening files for exclusive read *by default* is a pointless and silly 
> limitation. It's also unsafe: if a process opens a file for exclusive 
> read, and then dies, *no other process* can close that file.

Oh come on. Are you actually going to use "errors" or "unintended 
consequences", or even "Acts of God" to defend your argument? Okay. Okay. I 
suppose "IF" the car spontaneously combusted "THEN" the passengers would be 
wise to jump out, leaving the vehicle to the whims of inertia.

> One neat trick is to open a file, then delete it from disk while it is 
> still open. So long as your process is still running, you can write to 
> this ghost file, as normal, but no other process can (easily) see it. And 
> when your process ends, the file contents is automatically deleted.

Well "neat tricks" aside, I am of the firm belief that deleting files should 
never be possible whilst they are open. 

 * Opening files requires that data exist on disk
 * Reading and writing files requires an open file obj
 * Closing files requires an open file object
 * And deleting files requires that the file NOT be open

Would you also entertain the idea of reading or writing files that do not 
exist? (not including pseudo file objs like StringIO of course!).

Summary: Neat tricks and Easter eggs are real hoot, but consistency in APIs is 
the key.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: lambda in list comprehension acting funny

2012-07-12 Thread rusi

On Jul 11, 11:41 am, Daniel Fetchinson 
wrote:
> funcs = [ lambda x: x**i for i in range( 5 ) ]
> print funcs[0]( 2 )
> print funcs[1]( 2 )
> print funcs[2]( 2 )
>
> This gives me
>
> 16
> 16
> 16
>
> When I was excepting
>
> 1
> 2
> 4
>
> Does anyone know why?
>
> Cheers,
> Daniel

Your expectations are reasonable.  Heres the equivalent in Haskell
from which python has taken comprehensions.
-
GHCi, version 7.4.1: http://www.haskell.org/ghc/  :? for help

Prelude> let funcs = [ (\ x -> x ^ i)| i <- [0..4]]
Prelude> (funcs !! 0)(2)
1
Prelude> (funcs !! 1)(2)
2
Prelude> (funcs !! 2)(2)
4
Prelude>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to safely maintain a status file

2012-07-12 Thread Chris Angelico

On Fri, Jul 13, 2012 at 2:26 PM,   wrote:
> On Thursday, July 12, 2012 10:13:47 PM UTC-5, Steven D'Aprano wrote:
>> Rick has obviously never tried to open a file for reading when somebody
>> else has it opened, also for reading, and discovered that despite Windows
>> being allegedly a multi-user operating system, you can't actually have
>> multiple users read the same files at the same time.
>
> You misread my response. My comment was direct result of Christian stating:
>
> (paraphrase) "On some systems you are not permitted to delete a file whilst 
> the file is open "
>
> ...which seems to be consistent to me. Why would *anybody* want to delete a 
> file whilst the file is open?

POSIX doesn't let you delete files. It lets you dispose of filenames.
Python does the same with its 'del'. The object (file) exists until
the system decides otherwise.

Here's a simpler example: Hardlinks. Suppose you have two names
pointing to the same file; are you allowed to unlink one of them while
you have the "other" open?

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter.event.widget: handler gets name instead of widget.

2012-07-12 Thread Frederic Rentsch

On Tue, 2012-07-10 at 15:11 -0700, Rick Johnson wrote:
> I've tried to condense your code using the very limited info you have
> provided. I have removed unnecessarily configuring of widgets and
> exaggerated the widget borders to make debugging easier. Read below
> for Q&A.
> 
> ## START CONDENSED CODE ##
> records = range(4)
> 
> CNF_SUBFRAME = {
> 'bd':5, # rowFrame boder width.
> 'relief':RIDGE,
> }
> 
> CNF_LABEL = {
> 'anchor':W,
> 'width':10,
> 'bg':'gray',
> }
> 
> class FooFrame(tk.Frame):
> def __init__(self, master, **kw):
> tk.Frame.__init__(self, master, **kw)
> self.build_records()
> 
> def build_records(self):
> # Should this method be called by __init__???
> # Not sure if "records" is passed-in or global???
> for n in range(len(records)):
> record = records[n]
> rowFrame = tk.Frame(self, name='-%d-'%n, **CNF_SUBFRAME)
> rowFrame.bind ('', self.evtEnter)
> rowFrame.bind ('', self.evtLeave)
> rowFrame.bind ('',
> self.evtButtonOneRelease)
> rowFrame.bind ('',
> self.evtButtonThreeRelease)
> rowFrame.grid (row=n+2, column=1, padx=5, pady=5)
> for i in range(4):
> lbtext = 'Label_'+str(i)
> label = tk.Label(rowFrame, text=lbtext, **CNF_LABEL)
> label.grid (row=0, column=i, sticky=NW)
> 
> def evtEnter(self, event):
> w = event.widget
> print 'evtEnter', w.winfo_class()
> w.config(bg='magenta')
> 
> def evtLeave(self, event):
> w = event.widget
> print 'evtLeave', w.winfo_class()
> w.config(bg='SystemButtonFace')
> 
> def evtButtonOneRelease(self, event):
> w = event.widget
> print 'evtButtonOneRelease', w.winfo_class()
> w.config(bg='Green')
> 
> def evtButtonThreeRelease(self, event):
> w = event.widget
> print 'evtButtonThreeRelease', w.winfo_class()
> w.config(bg='Blue')
> 
> if __name__ == '__main__':
> root = tk.Tk()
> frame = FooFrame(root, width=100, height=100, bg='red', bd=1)
> frame.pack(padx=5, pady=5)
> root.mainloop()
> ## END CONDENSED CODE ##
> 
> 
> In the code sample provided, you will see that the label widgets
> stacked on each row will block "click" events on the containing
> "rowFrames" below them. You can get a click event (on the sub frames)
> to work by clicking the exaggerated border on the frames. All the
> events work properly for me, although this GUI interface seems
> unintuitive even with proper borders and colors.
> 
> Fredric, I can't help but feel that you are not attacking the problem
> correctly. Please explain the following questions in detail so that i
> may be able to provide help:
> 
It works for me too.

I spent another day running the offending class in a simplified
environment and it worked flawlessly. In what way the environment makes
the difference is anything but obvious. But it has got to be the
environment.

> Q1. You have subclassed a Tkinter.Frame and you are building "rows" of
> sub-frames into this toplevel frame; with each row holding
> horizontally stacked label widgets. Okay, I can see a need to wrap up
> a "RowFrame" object, but i don't see a need to create a
> "RowFrameFactory". Can you explain this design decision?
> 
I sent this same response yesterday with a screen shot attached. The
message didn't pass. It must have been rejected by a spam filter. So I
try again without the screen shot. (Too bad. A picture is worth a
thousand words).
   The "hit list" is a table of investment titles (stock, funds, bonds)
that displays upon entry of a search pattern into a respective template.
The table displays the matching records: name, symbol, ISIN, CUSIP, Sec.
Any line can be click-selected. So they are to look like buttons.
Representing the mentioned names and id codes in Label widgets was the
simplest way I could come up with to align them in columns, admittedly
without the benefit of much experience. But it does look good. the
layout is fine.
   I find the Tkinter system quite challenging. Doing a layout isn't so
much a matter of dimensioning and placing things as a struggle to trick
a number of automatic dimensioning and placing mechanisms into
obliging--mechanisms that are rather numerous and hard to remember.

> Q2. It seems odd to me that you want to engage the "rowFrame" widgets
> via events but NOT the Label widgets. Can you explain this design
> decision?
> 
Again, the labels serve to align the fields into columns. As to the
bindings, I just now found out, that  and  can be bound to
the line frame, but the mouse buttons don't act on the frame with the
labels covering it wall to wall. Entry will lighten up the background of
the line. Leave restores the normal color.  will select
the line, darkening the text. The coloring has to be done separately on
each label across the line, as the labels cover t

Re: lambda in list comprehension acting funny