Re: strange results

[Alexander Kapps]

On 17.09.2011 01:09, Fig wrote:

I took out all of the color commands that were in the shape functions
and all of the features to the 'draw_house' function showed showed up.
I started putting the color commands back into the shape functions and
have no problems with some of them but when I put the color command
back into others, some of the features start to disappear. As far as I
can see, all of the code is right but I'm just a beginner so I am not
for sure. Can anyone tell me why this is doing what it is.



Just tried your program on Ubuntu 10.04 with Python 2.6.5 and GASP 
0.3.3 and it worked fine. What OS, Python version and GASP version 
are you using?


If you don't get an answer here, try asking on the Launchpad project 
site:


https://launchpad.net/gasp
--
http://mail.python.org/mailman/listinfo/python-list

Re: Accessing matplotlib-users discussion group?

[John Ladasky]

On Sep 16, 10:29 am, Martin Schöön  wrote:
> On 2011-09-15, John Ladasky  wrote:
>
> > Hate to bump this, but... I found Sourceforge's IRC, and tried to ask
> > for help there, and it doesn't look like I can get any help until
> > business hours tomorrow.  Anyone?
>
> No help really but I 'joined' Sourceforge about a year ago and
> had no problems whatsoever.
>
> Could it be some anti-robot filter that's gotten overly picky?
>
> /Martin

Well, I got through to Sourceforge today, and succeeded in
subscribing.  A support person said that their site's registration web
page has compatibility issues with certain web browsers and/or their
extensions.  I was using Chrome.  They asked me to try another
browser, I tried Firefox, and it worked.

Personally, I find that to be pretty bizarre -- but it worked.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: multiprocessing.Pool, its queue, and pre-emption

[John Ladasky]

Hey, this pretty easy hack appears to work!

[code]

from multiprocessing.pool import Pool, RUN, MapResult, mapstar

class PriorityPool(Pool):

def map_async_nowait(self, func, iterable, chunksize=None, \
callback=None):
"""
Same as map_async(), except uses put_nowait() and
thus posts tasks to the head of the task queue
rather than its tail.
"""
assert self._state == RUN
if not hasattr(iterable, '__len__'):
iterable = list(iterable)

if chunksize is None:
chunksize, extra = divmod(len(iterable), len(self._pool) *
4)
if extra:
chunksize += 1

task_batches = Pool._get_tasks(func, iterable, chunksize)
result = MapResult(self._cache, chunksize, len(iterable), \
callback)
self._taskqueue.put_nowaitresult._job, i, mapstar, (x,),
{}) \
for i, x in enumerate(task_batches)), None))
return result

def size(self):
"""
This is not an essential function, but I use it in the
demo to ensure that I initially create enough tasks to
occupy every Process.
"""
return len(self._pool)

####

if __name__ == "__main__":

from time import sleep

def demo_task(args):
num, time = args
sleep(time)
print num, time

pool = PriorityPool()
size = pool.size()
print "\nConstructed a pool which contains", size, "Processes."
print "Queueing", 2*size, "normal-priority tasks."
normal = enumerate([3.0 + t for t in range(2*size)])
pool.map_async(demo_task, normal, chunksize = 1)
print "Queueing", size, "high-priority tasks."
high = [(2*size + t, 0.2 + 0.1*t) for t in range(size)]
pool.map_async_nowait(demo_task, high, chunksize = 1)
sleep(30) # Give all tasks on the queue time to complete.
print "Complete."

[/code]

Below is a typical output from my six-core CPU system.  The output
differs slightly from run to run -- that's multiprocessing for you,
it's asynchronous.

The tasks are given numbers which correspond to the order that they
are added to the queue.  The high-priority tasks are added last and
are thus numbered 12-17 (I place asterisks next to these in the
output, below).  Each task prints its number and its time when it
completes.  I expect the normal-priority tasks 0-5 to finish before
any high-priority tasks, and they always do.  Tasks 6 and 7 are then
interleaved among the high-priority tasks -- not quite what I expect,
but that may have something to do with my rather arbitrary choices of
sleep times.  But tasks 8-11 always get pushed to the back, and
complete last.

[output]

Constructed a pool which contains 6 Processes.
Queueing 12 normal-priority tasks.
Queueing 6 high-priority tasks.
0 3.0
1 4.0
2 5.0
3 6.0
4 7.0
5 8.0
6 9.0
12 0.2 *
13 0.3 *
14 0.4 *
15 0.5 *
7 10.0
16 0.6 *
17 0.7 *
8 11.0
9 12.0
10 13.0
11 14.0

[/output]

Please feel free to use this, though I would appreciate an
acknowledgment in your code if you do.  :^)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Code Review

[Philipp Hagemeister]

Instead of comments, you can often use docstrings
(http://www.python.org/dev/peps/pep-0257/ ):

This is hard to read due to the indentation, and cannot be accessed
programmatically:

#Update the GUI
def update_gui(self, new_word):

Instead, use this:

def update_gui(self, new_word):
"Update the GUI."

Now, you can use help(Message) to get information about the method.
You'll notice "Update the GUI." is not helpfull at all for a method
called update_gui. Comments (and docstrings) that reproduce the method
name are not useful.

A couple of minor things:

* If you delete code, delete it, don't comment it out.
* Use newlines between two methods. Compare
def a(self):
  pass
def b(self):
  pass
def c(self):
  pass

with

def a(self):
  pass

def b(self):
  pass

def c(self):
  pass

The latter looks neat and not nearly as crammed as the former.
* Don't use newlines where they shouldn't be, for example in
if val == 0:

  label.unbind('')
* Even if it's just the comments, typos make a very bad impression of a
coder and the code. I'd automatically assume lots of bugs and untested
code when I see more than the occasional typo.
* GUI programming is fun, but does not lend itself to structured
programming and good practices. You should never use global. Instead,
have an object encapsulating the state and pass that object to the
method itself or its object.
* Don't commit .pyc files, they're totally useless. Since python 2.6,
you can add the following in your .bashrc to make python not create them:

export "PYTHONDONTWRITEBYTECODE=dont"

In git, you can add the following in your project's .gitignore or
~/.gitignore_global:

*.pyc

[More on .gitignore: http://help.github.com/ignore-files/ ]
* Otherwise, the code looks pretty good for a beginner. You may,
however, want to replace

def word_not_found(word):
  if word in searchedwordset:
return 0
  else:
return 1

with just:

def word_not_found(word):
  return word not in searchedwordset

(or just skip this method and write word not in searchedwordset).

Cheers,

Philipp



Emeka wrote:
> Hello All,
> 
> While learning Python I put together another Text Twist. I would want
> somebody to go through it and comment.
> https://github.com/janus/Text-Twist
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: create a directory structure

[Rafael Durán Castañeda]

2011/9/16 Andrea Crotti 

> After some research, I think that paste-script is the best choice in this
> case.
>
> I can define templates and I'll get my directory structure nicely populated
> for me.
>
> --
> http://mail.python.org/**mailman/listinfo/python-list
>
I think you might want to look at
Fabricor
vagrant 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Code Review

[Emeka]

Philipp,

Thanks so much for your time and comment. I will re-work my code
accordingly.

Regards,
Emeka

On Sat, Sep 17, 2011 at 12:19 PM, Philipp Hagemeister wrote:

> Instead of comments, you can often use docstrings
> (http://www.python.org/dev/peps/pep-0257/ ):
>
> This is hard to read due to the indentation, and cannot be accessed
> programmatically:
>
> #Update the GUI
>def update_gui(self, new_word):
>
> Instead, use this:
>
>def update_gui(self, new_word):
>"Update the GUI."
>
> Now, you can use help(Message) to get information about the method.
> You'll notice "Update the GUI." is not helpfull at all for a method
> called update_gui. Comments (and docstrings) that reproduce the method
> name are not useful.
>
> A couple of minor things:
>
> * If you delete code, delete it, don't comment it out.
> * Use newlines between two methods. Compare
> def a(self):
>  pass
> def b(self):
>  pass
> def c(self):
>  pass
>
> with
>
> def a(self):
>  pass
>
> def b(self):
>  pass
>
> def c(self):
>  pass
>
> The latter looks neat and not nearly as crammed as the former.
> * Don't use newlines where they shouldn't be, for example in
>if val == 0:
>
>  label.unbind('')
> * Even if it's just the comments, typos make a very bad impression of a
> coder and the code. I'd automatically assume lots of bugs and untested
> code when I see more than the occasional typo.
> * GUI programming is fun, but does not lend itself to structured
> programming and good practices. You should never use global. Instead,
> have an object encapsulating the state and pass that object to the
> method itself or its object.
> * Don't commit .pyc files, they're totally useless. Since python 2.6,
> you can add the following in your .bashrc to make python not create them:
>
> export "PYTHONDONTWRITEBYTECODE=dont"
>
> In git, you can add the following in your project's .gitignore or
> ~/.gitignore_global:
>
> *.pyc
>
> [More on .gitignore: http://help.github.com/ignore-files/ ]
> * Otherwise, the code looks pretty good for a beginner. You may,
> however, want to replace
>
> def word_not_found(word):
>  if word in searchedwordset:
>return 0
>  else:
>return 1
>
> with just:
>
> def word_not_found(word):
>  return word not in searchedwordset
>
> (or just skip this method and write word not in searchedwordset).
>
> Cheers,
>
> Philipp
>
>
>
> Emeka wrote:
> > Hello All,
> >
> > While learning Python I put together another Text Twist. I would want
> > somebody to go through it and comment.
> > https://github.com/janus/Text-Twist
> >
> >
>
>
>


-- 
*Satajanus  Nig. Ltd


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

Re: strange results

[Fig]

On Sep 17, 1:59 am, Alexander Kapps  wrote:
> On 17.09.2011 01:09, Fig wrote:
>
> > I took out all of the color commands that were in the shape functions
> > and all of the features to the 'draw_house' function showed showed up.
> > I started putting the color commands back into the shape functions and
> > have no problems with some of them but when I put the color command
> > back into others, some of the features start to disappear. As far as I
> > can see, all of the code is right but I'm just a beginner so I am not
> > for sure. Can anyone tell me why this is doing what it is.
>
> Just tried your program on Ubuntu 10.04 with Python 2.6.5 and GASP
> 0.3.3 and it worked fine. What OS, Python version and GASP version
> are you using?
>
> If you don't get an answer here, try asking on the Launchpad project
> site:
>
> https://launchpad.net/gasp

My OS is Windows 7, Python 2.7.2, I downloaded and installed the
python-gasp-0.2.0beta1.win32.exe file, and I also have these
installed: Python 2.7 pygame-1.9.2a0 and Python 2.7 pywin32-216
-- 
http://mail.python.org/mailman/listinfo/python-list

Modifiying __getattribute__ of an instance

[Yaşar Arabacı]

I am trying to modify __getattribute__() method for an instance, as you may
already know,__getattirbute__ is read-only attribute in Python. What I have
in mind is, create a new object like this:

def create_new_instace(old_instance):
class temp(old_instance.__class__):
def __init__(self,*args,**kwargs):
"Since we will copy an already inited instance"
pass
def __getattribute__(self,attr):
   # do stuff
new_instance = temp()
# magically copy all attrs of old_instance to new_instance
return new_instance

Is this kind of thing possible?
-- 
http://yasar.serveblog.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: strange results

[Anssi Saari]

Fig  writes:

> My OS is Windows 7, Python 2.7.2, I downloaded and installed the
> python-gasp-0.2.0beta1.win32.exe file, and I also have these
> installed: Python 2.7 pygame-1.9.2a0 and Python 2.7 pywin32-216

Then maybe that old beta version is your problem? For the record, your
code works for me too in Linux and python-gasp 0.3.3. 

Looks like there's no Windows installer for newer python-gasp. Maybe you
could install with easy_install as they describe on the site?
-- 
http://mail.python.org/mailman/listinfo/python-list

os independent rename

[Lee Harr]

I just got a bug report the heart of which is the
difference between unix and windows in using
os.rename

(ie, "On Windows, if dst already exists, OSError will be raised")

Hmm, I thought, maybe I'm supposed to use
shutil here. That is the "high-level" operations.
Unfortunately, shutil.move says it depends on
os.rename

So, what is the best way to do this that will
behave the same across operating systems?

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

Re: os independent rename

[Ian Kelly]

On Sat, Sep 17, 2011 at 9:58 AM, Lee Harr  wrote:
>
> I just got a bug report the heart of which is the
> difference between unix and windows in using
> os.rename
>
> (ie, "On Windows, if dst already exists, OSError will be raised")
>
> Hmm, I thought, maybe I'm supposed to use
> shutil here. That is the "high-level" operations.
> Unfortunately, shutil.move says it depends on
> os.rename
>
> So, what is the best way to do this that will
> behave the same across operating systems?

shutil.move works for me, at least in Python 2.7.  The docstring
doesn't seem to match the code here:

try:
os.rename(src, real_dst)
except OSError:
if os.path.isdir(src):
if _destinsrc(src, dst):
raise Error, "Cannot move a directory '%s' into itself
'%s'." % (src, dst)
copytree(src, real_dst, symlinks=True)
rmtree(src)
else:
copy2(src, real_dst)
os.unlink(src)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: way to calculate 2**1000 without expanding it?

[Grant Edwards]

On 2011-09-17, Ian Kelly  wrote:
> On Fri, Sep 16, 2011 at 8:19 PM, Grant Edwards  
> wrote:
>>> Here's another one-liner using a generator instead of map:
>>>
>>> ? ? ?sum(int(c) for c in str(2**1000))
>>
>> Just in case you can't spare the 3KB required for the list of integers
>> that map creates. :)
>>
>> In this case it doesn't matter, but it's not hard to find problems
>> where the difference between the memory requirements for a generator
>> and a map/list-comprehension are significant enough to worry about.
>
> Unless otherwise specified, I generally assume that code on this list
> is for Python 3, and map in Python 3 returns an iterator.

Indeed, I forgot about that (I'm still using Python 2 since I use some
libraries that haven't been ported).

-- 
Grant


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

Python bug in Windows 8--report now, or later?

[Kevin Walzer]

I have been testing my Python application on the just-released developer 
preview of Windows 8 and have noted an error: the application does not 
create an app folder in the user's "application data" directory. This 
causes the app to crash on startup. Manually creating the directory 
solves the problem. Since the app uses an os.mkdir() call to create the 
directory, and since the app runs fine on Windows 7, my guess is that 
the bug lies somewhere in the interaction between Python (I'm using 
ActivePython 2.7) and Windows.


Here's the relevant code:

#make preferences directory if it does not exist
def makePrefsDir(self):
self.appdir = os.path.join(os.path.join(os.environ['APPDATA'], 
'MyApp'))

if not os.path.exists(self.appdir):
os.mkdir(self.appdir)

I realize that this developer preview of Windows is still at somewhere 
between alpha- and beta-level, and it's possible things will get better. 
Should I wait to report this as a bug until Windows 8 is released, or do 
the Python developers test Python on pre-release versions of Windows?

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

Re: os independent rename

[Lee Harr]

> shutil.move works for me, at least in Python 2.7.  The docstring> doesn't 
> seem to match the code
Thanks for checking that.
Looks like there is a closed report about the misleading 
docs:http://bugs.python.org/issue12577
Closed a couple of months ago, but the docs have not madeit to the web yet
  -- 
http://mail.python.org/mailman/listinfo/python-list

Re: Cancel or timeout a long running regular expression

[Nobody]

On Fri, 16 Sep 2011 18:01:27 -0400, Terry Reedy wrote:

> Now, can you write that as a heuristic *algorithm*
> def dangerous_re(some_re):?

return re.search(r'\\\d', some_re) is not None

That will handle the most extreme case ;)

If the OP is serious about analysing regexps, sre_parse.parse() will
decompose a regexp to a more convenient form.

However, I wouldn't rely upon being able to catch every possible bad case.
The only robust solution is to use a separate process (threads won't
suffice, as they don't have a .kill() method).

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

Re: os independent rename

[Nobody]

On Sat, 17 Sep 2011 20:28:32 +0430, Lee Harr wrote:

> So, what is the best way to do this that will
> behave the same across operating systems?

Delete the destination first, but after checking that it isn't the same as
the source.

On Windows, that last bit is harder than it seems. A string-based
comparison won't work. Even if you ignore case, there's the issue of 8.3
filenames, and some other odd cases.

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

Re: Python bug in Windows 8--report now, or later?

[Terry Reedy]

On 9/17/2011 2:01 PM, Kevin Walzer wrote:

I have been testing my Python application on the just-released developer
preview of Windows 8 and have noted an error: the application does not
create an app folder in the user's "application data" directory. This
causes the app to crash on startup. Manually creating the directory
solves the problem. Since the app uses an os.mkdir() call to create the
directory, and since the app runs fine on Windows 7, my guess is that
the bug lies somewhere in the interaction between Python (I'm using
ActivePython 2.7) and Windows.


We need more that guesses to act. I think is premature to call this a 
'Python bug'.



Here's the relevant code:

#make preferences directory if it does not exist
def makePrefsDir(self):
self.appdir = os.path.join(os.path.join(os.environ['APPDATA'], 'MyApp'))
if not os.path.exists(self.appdir):
os.mkdir(self.appdir)

I realize that this developer preview of Windows is still at somewhere
between alpha- and beta-level, and it's possible things will get better.
Should I wait to report this as a bug until Windows 8 is released, or do
the Python developers test Python on pre-release versions of Windows?


3 days ago (Sept 14) someone asked about 'Windows 8 support' on pydev 
list. The answers were 1) 2.7 and 3.2 appear to run fine on the Dev 
release (but there was no report of test suite results); 2) Python 
directly uses so little of the Win interface that problems are not 
anticipated; 3) applications might have to make Win 8 specific 
adjustments and should test before the release.


Of course, if MS accidentally changes thinly wrapped system calls such 
as os.environ, .exists, and .makedir, there will be a problem but that 
is their bug. My impression is that they are not intentionally breaking 
such things.


I anticipate 3.3 and some future 2.7.z will be officially supported (and 
tested) on Win 8.


--
Terry Jan Reedy

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

Re: Python bug in Windows 8--report now, or later?

[Chris Angelico]

On Sun, Sep 18, 2011 at 4:01 AM, Kevin Walzer  wrote:
> I realize that this developer preview of Windows is still at somewhere
> between alpha- and beta-level, and it's possible things will get better.
> Should I wait to report this as a bug until Windows 8 is released, or do the
> Python developers test Python on pre-release versions of Windows?

I would consider reporting it as a bug in Windows 8, not a bug in Python.

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

Killing threads (was Re: Cancel or timeout a long running regular expression)

[Chris Angelico]

On Sun, Sep 18, 2011 at 5:00 AM, Nobody  wrote:
> The only robust solution is to use a separate process (threads won't
> suffice, as they don't have a .kill() method).
>

Forking a thread to discuss threads ahem.

Why is it that threads can't be killed? Do Python threads correspond
to OS-provided threads (eg POSIX threads on Linux)? Every OS threading
library I've seen has some way of killing threads, although I've not
looked in detail into POSIX threads there (there seem to be two
options, pthread_kill and pthread_cancel, that could be used, but I've
not used either). If nothing else, it ought to be possible to
implement a high level kill simply by setting a flag that the
interpreter will inspect every few commands, the same way that
KeyboardInterrupt is checked for.

Is it just that nobody's implemented it, or is there a good reason for
avoiding offering this sort of thing?

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

Re: Killing threads (was Re: Cancel or timeout a long running regular expression)

[Chris Rebert]

On Sat, Sep 17, 2011 at 2:35 PM, Chris Angelico  wrote:
> On Sun, Sep 18, 2011 at 5:00 AM, Nobody  wrote:
>> The only robust solution is to use a separate process (threads won't
>> suffice, as they don't have a .kill() method).
>
> Forking a thread to discuss threads ahem.
>
> Why is it that threads can't be killed? Do Python threads correspond
> to OS-provided threads (eg POSIX threads on Linux)? Every OS threading
> library I've seen has some way of killing threads, although I've not
> looked in detail into POSIX threads there (there seem to be two
> options, pthread_kill and pthread_cancel, that could be used, but I've
> not used either). If nothing else, it ought to be possible to
> implement a high level kill simply by setting a flag that the
> interpreter will inspect every few commands, the same way that
> KeyboardInterrupt is checked for.
>
> Is it just that nobody's implemented it, or is there a good reason for
> avoiding offering this sort of thing?

It's possible that the reason is analogous to why Java has deprecated
its equivalent, Thread.stop():
http://download.oracle.com/javase/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

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

Re: Killing threads (was Re: Cancel or timeout a long running regular expression)

[Chris Angelico]

On Sun, Sep 18, 2011 at 8:27 AM, Chris Rebert  wrote:
> It's possible that the reason is analogous to why Java has deprecated
> its equivalent, Thread.stop():
> http://download.oracle.com/javase/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

Interesting. The main argument against having a way to raise an
arbitrary exception in a different thread is that it gets around
Java's requirement to declare all exceptions that a routine might
throw - a requirement that Python doesn't have. So does that mean it'd
be reasonable to have a way to trigger a "TerminateThread" exception
(like SystemExit but for one thread) remotely? The above article
recommends polling a variable, but that's the exact sort of thing that
exceptions are meant to save you from doing.

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

Re: Killing threads (was Re: Cancel or timeout a long running regular expression)

[Cameron Simpson]

On 17Sep2011 15:27, Chris Rebert  wrote:
| On Sat, Sep 17, 2011 at 2:35 PM, Chris Angelico  wrote:
| > On Sun, Sep 18, 2011 at 5:00 AM, Nobody  wrote:
| >> The only robust solution is to use a separate process (threads won't
| >> suffice, as they don't have a .kill() method).
| >
| > Forking a thread to discuss threads ahem.
| >
| > Why is it that threads can't be killed? Do Python threads correspond
| > to OS-provided threads (eg POSIX threads on Linux)? Every OS threading
| > library I've seen has some way of killing threads, although I've not
| > looked in detail into POSIX threads there (there seem to be two
| > options, pthread_kill and pthread_cancel, that could be used, but I've
| > not used either). If nothing else, it ought to be possible to
| > implement a high level kill simply by setting a flag that the
| > interpreter will inspect every few commands, the same way that
| > KeyboardInterrupt is checked for.
| >
| > Is it just that nobody's implemented it, or is there a good reason for
| > avoiding offering this sort of thing?
| 
| It's possible that the reason is analogous to why Java has deprecated
| its equivalent, Thread.stop():
| 
http://download.oracle.com/javase/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

Interesting. A lot of that discussion concerns exceptions that the Java
app is unprepared for. Java's strong typing includes the throwable
exceptions, so that's a quite legitimate concern. The aborting mutex
regions thing is also very real. Conversely, Python can have unexpected
exceptions anywhere, anytime because it is not strongly typed in this
way. That doesn't make it magicly robust against this, but does mean
this is _already_ an issue in Python programs, threaded or otherwise.

Context managers can help a lot here, in that they offer a reliable
exception handler in a less ad hoc fashion than try/except because it
is tied to the locking object; but they won't magicly step in save
your basic:

  with my_lock:
stuff...

Personally I'm of the view that thread stopping should be part of the
overt program logic, not a low level facility (such as causing a
ThreadDeath exception asynchronously). The latter has all the troubles
in the cited URL. Doing it overtly would go like this:

  ... outside ...
  that_thread.stop()# sets the "stopping" flag on the thread object
  that_thread.join()# and now maybe we wait for it...

  ... thread code ...
  ... do stuff, eg:
  with my_lock:
muck about ...
  if thread.stopping:
abort now, _outside_ the mutex
  ...

This avoids the issue of aborting in the middle of supposedly mutex-safe
code. It still requires scattering checks on thread.stopping through
library code such as the OP's rogue regexp evaluator.

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

One measure of `programming complexity' is the number of mental objects you
have to keep in mind simultaneously in order to understand a program.  The
mental juggling act is one of the most difficult aspects of programming and
is the reason programming requires more concentration than other activities.
It is the reason programmers get upset about `quick interruptions' -- such
interruptions are tantamount to asking a juggler to keep three balls in the
air and hold your groceries at the same time.
- Steve McConnell, _Code Complete_
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: os independent rename

[Cameron Simpson]

On 17Sep2011 20:18, Nobody  wrote:
| On Sat, 17 Sep 2011 20:28:32 +0430, Lee Harr wrote:
| > So, what is the best way to do this that will
| > behave the same across operating systems?
| 
| Delete the destination first, but after checking that it isn't the same as
| the source.

This is usually a step that the UNIX os.rename is designed to avoid.
By deleting first, there is a window where the destination doesn't exist
at all. Also, if the subsequent rename fails, the destination is missing
long term. os.rename() on UNIX specifies that after the call either the
new items is at destination (success) or the old item is (failure).
Either way you still have a valid destination object.

So you're breaking the model that os.rename() strives explicitly to
provide.

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

Q: How many user support people does it take to change a light bulb?
A: We have an exact copy of the light bulb here and it seems to be
   working fine.  Can you tell me what kind of system you have?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Killing threads (was Re: Cancel or timeout a long running regular expression)

[Terry Reedy]

On 9/17/2011 7:19 PM, Chris Angelico wrote:

On Sun, Sep 18, 2011 at 8:27 AM, Chris Rebert  wrote:

It's possible that the reason is analogous to why Java has deprecated
its equivalent, Thread.stop():
http://download.oracle.com/javase/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html


Interesting. The main argument against having a way to raise an
arbitrary exception in a different thread is that it gets around
Java's requirement to declare all exceptions that a routine might
throw - a requirement that Python doesn't have.


I saw the main argument as being that stopping a thread at an arbitrary 
point can have an arbitrary, unpredictable effect on all other threads. 
And more so that shutting down an independent process.


--
Terry Jan Reedy

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

Re: Killing threads (was Re: Cancel or timeout a long running regular expression)

[Chris Angelico]

On Sun, Sep 18, 2011 at 9:26 AM, Dennis Lee Bieber
 wrote:
> def threadWork(lock, a1, a2, rate):
>        while True:
>                time.sleep(rate)
>                lock.lock()
>                t = a2.balance / 2
>                a1.balance += t
>                #say a thread.kill kills at this point
>                a2.balance -= t
>                lock.release()
>

It's obviously going to be an issue with killing processes too, which
is why database engines have so much code specifically to protect
against this. But if it's done as an exception, all you need is to
catch that exception and reraise it:

def threadWork(lock, a1, a2, rate):
   try:
   while True:
   time.sleep(rate)
   lock.lock()
   t = a2.balance / 2
   a1.balance += t
   #say a thread.kill kills at this point
   a2.balance -= t
   lock.release()
  except:
  # roll back the transaction in some way
  lock.release()
  raise

It'd require some care in coding, but it could be done. And if the
lock/transaction object can be coded for it, it could even be done
automatically:

def threadWork(lock, a1, a2, rate):
   while True:
   time.sleep(rate)
   transaction.begin()
   t = a2.balance / 2
   transaction.apply(a1.balance,t)
   #say a thread.kill kills at this point
   transaction.apply(a2.balance,-t)
   transaction.commit()

If the transaction object doesn't get its commit() called, it does no
actions at all, thus eliminating all issues of locks.

Obviously there won't be any problem with the Python interpreter
itself (refcounts etc) if the kill is done by exception - that would
be a potential risk if using OS-level kills.

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

Re: Killing threads (was Re: Cancel or timeout a long running regular expression)

[MRAB]

On 18/09/2011 00:26, Dennis Lee Bieber wrote:

On Sun, 18 Sep 2011 07:35:01 +1000, Chris Angelico
declaimed the following in gmane.comp.python.general:


Is it just that nobody's implemented it, or is there a good reason for
avoiding offering this sort of thing?


Any asynchronous "kill" runs the risk of leaving shared data
structures in a corrupt state. {Stupid example, but, in pseudo-Python:

import time

class Account(object):
def __init__(self, initial=0.0)
self.balance = initial

myAccount = Account(100.0)
yourAccount = Account(100.0)

accountLock = threading.Lock()

def threadWork(lock, a1, a2, rate):
while True:
time.sleep(rate)
lock.lock()
t = a2.balance / 2
a1.balance += t
#say a thread.kill kills at this point
a2.balance -= t
lock.release()

# create/start thread1 passing (accountLock, myAccount, yourAccount, 60)
# create/start thread2 passing (accountLock, yourAccount, myAccount,
120)

time.sleep(300)
thread1.kill()

So... Thread1 may be killed after one account gets incremented but
before the other is decremented... And what happens to the lock? If it
doesn't get released as part of the .kill() processing, they program is
dead-locked (and the magically appearing money will never be seen). If
it does get released, then the sum total of "money" in the system will
have increased.


[snip]
The lock won't be released if an exception is raised, for example, if
'a1' isn't an Account instance and has no 'balance' attribute. Using a
context manager would help in that case.
--
http://mail.python.org/mailman/listinfo/python-list

Re: os independent rename

[Dave Angel]

On 01/-10/-28163 02:59 PM, Nobody wrote:

On Sat, 17 Sep 2011 20:28:32 +0430, Lee Harr wrote:


So, what is the best way to do this that will
behave the same across operating systems?

Delete the destination first, but after checking that it isn't the same as
the source.

On Windows, that last bit is harder than it seems. A string-based
comparison won't work. Even if you ignore case, there's the issue of 8.3
filenames, and some other odd cases.


Or rename it twice, with the intermediate file being something that does 
not exist.  For example, generate a random name, and if it exists, 
repeat till you come up with one that does not.  Once the first rename 
has succeeded, you can safely delete the destination.


Even this approach can have problems in the face of symlinks or multiple 
partitions.


DaveA

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

Re: Python bug in Windows 8--report now, or later?

[John Ladasky]

On Sep 17, 2:20 pm, Chris Angelico  wrote:

> I would consider reporting it as a bug in Windows 8, not a bug in Python.
>
> Chris Angelico

+1, beat me to it.  :^)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python bug in Windows 8--report now, or later?

[Grant Edwards]

On 2011-09-17, Chris Angelico  wrote:

> I would consider reporting it as a bug in Windows 8, not a bug in 

Good luck with that plan.  ;)

[I don't know anything about this particular issue, but I do know that
when there is a bug in Windows, it's usually everyboyd else that has
to change to work around it.]


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

Re: Python bug in Windows 8--report now, or later?

[Westley Martínez]

On Sun, Sep 18, 2011 at 04:15:57AM +, Grant Edwards wrote:
> On 2011-09-17, Chris Angelico  wrote:
> 
> > I would consider reporting it as a bug in Windows 8, not a bug in 
> 
> Good luck with that plan.  ;)
> 
> [I don't know anything about this particular issue, but I do know that
> when there is a bug in Windows, it's usually everyboyd else that has
> to change to work around it.]
> 
>

Actually Microsoft usually goes out of its way to ensure backwards-
compatibily, even when the app developer is DOING IT WRONG.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python bug in Windows 8--report now, or later?

[Alec Taylor]

On Sun, Sep 18, 2011 at 2:40 PM, Westley Martínez  wrote:
> On Sun, Sep 18, 2011 at 04:15:57AM +, Grant Edwards wrote:
>> On 2011-09-17, Chris Angelico  wrote:
>>
>> > I would consider reporting it as a bug in Windows 8, not a bug in 
>> > 
>>
>> Good luck with that plan.  ;)
>>
>> [I don't know anything about this particular issue, but I do know that
>> when there is a bug in Windows, it's usually everyboyd else that has
>> to change to work around it.]
>>
>>
>
> Actually Microsoft usually goes out of its way to ensure backwards-
> compatibily, even when the app developer is DOING IT WRONG.
> --
> http://mail.python.org/mailman/listinfo/python-list
>

For those interested, Windows 8 is available here:
http://msdn.microsoft.com/windows/apps/br229516/
-- 
http://mail.python.org/mailman/listinfo/python-list