date:20080210

On 2008-02-10, Elby <[EMAIL PROTECTED]> wrote:

> Matplotlib as some 3D capabilities too. You can have a look at
> these examples : http://scipy.org/Cookbook/Matplotlib/mplot3D

I use gnuplot.py for 3D stuff regularly.

-- 
Grant Edwards   grante Yow!  Alright,
  at   you!! Imitate a WOUNDED
   visi.comSEAL pleading for a PARKING
   SPACE!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OT: Speed of light [was Re: Why not a Python compiler?]

On 2008-02-09, Doug Morse <[EMAIL PROTECTED]> wrote:

>>  Or just the old particle/wave dichotomy... particles
>>  travel, waves propagate (that is, the wave form -- crest/dip
>>  -- changes position, but the material of the medium it is in
>>  just jiggles in place).

> So, showing of my physics ignorance: I presume then that this
> means that light, say from the sun, is actually sending
> particles to the earth, since the space between is mostly
> vacuum?  Or is there enough material in the near-vacuum of
> space for propogation to occur?

They act like both waves and as particles depending on what
experiment you do.  Though even if you consider them as waves
they don't depend on "jiggling" of a medium.  That medium was
called the "luminiferous aether" (aka ether), and in the 19th
century experiments showed conclusively that it doesn't exist:

http://en.wikipedia.org/wiki/Luminiferous_aether

-- 
Grant Edwards   grante Yow!  .. I think I'd
  at   better go back to my DESK
   visi.comand toy with a few common
   MISAPPREHENSIONS...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter equiv for setPalette

2008-02-10 Thread MASI

Il Sun, 10 Feb 2008 12:03:59 +0100, Helmut Jarausch ha scritto:

> Hi,
> 
> I am to convert an old Perl-Tk script to Python.
> It starts by
> my $MW= new MainWindow;
> $MW->setPalette(background => 'AntiqueWhite1', foreground => 'blue');
> 
> Is there an equivalent for Tkinter? How can I set default colors for
> background and foreground for the whole application (root window and its
> children)
> 
> Many thanks for a hint,
> Helmut.

You have two options:
1) put your preference in a file

eg

file 'tk_option':

*foreground: blue
*background: green
*Entry*background: red

and read it

root = Tkinter.Tk()
root.option_readfile('tk_option')

2) in your program whit option_add

eg

root = Tkinter.Tk()
root.option_add('*foreground', 'blue')
root.option_add('*background', 'green')
root.option_add('*Entry*background', 'red')
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

2008-02-10 Thread [EMAIL PROTECTED]

Would a wrapper function be out of the question here?

def MyDivision(num, denom):
if denom==0:
return "NaN"
else
return num / denom
-- 
http://mail.python.org/mailman/listinfo/python-list

Tkinter - tk_focusNext broken for years?

2008-02-10 Thread Helmut Jarausch

Hi,

I'd like to bind the '' event to a function
which does some calculations (like a database lookup)
and then invoke  tk_focusNext.
I get an exception as many others have reported earlier, see
http://bugs.python.org/issue799428
There has even a patch been suggested. Why hasn't it been fixed -
I haven't seen a fix.
The problem can be reproduced by the following tiny script
I'm using Python 2.5.1 .

Should I fixed the Tkinter source myself or is there a workaround?

Many thanks for your help,
Helmut.
---
import Tkinter as Tk

def Proc_Enter(Event) :
   print "Enter - normally lookup a database"
   Event.widget.tk_focusNext()

root= Tk.Tk()
Tk.Label(root,text='Name').grid(column=0,row=0,sticky=Tk.W)
Nm_input= Tk.StringVar()
Nm_entry= Tk.Entry(root,textvariable=Nm_input)
Nm_entry.bind('',Proc_Enter)
Nm_entry.grid(column=1,row=0,sticky=Tk.W)

Tk.Label(root,text='City').grid(column=0,row=1,sticky=Tk.W)
City_input= Tk.StringVar()
City_entry= Tk.Entry(root,textvariable=City_input)
City_entry.bind('',Proc_Enter)
City_entry.grid(column=1,row=1,sticky=Tk.W)

Tk.mainloop()
---
 
Exception in Tkinter callback
Traceback (most recent call last):
   File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
 return self.func(*args)
   File "FocusBug.py", line 6, in Proc_Enter
 Event.widget.tk_focusNext()
   File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 479, in tk_focusNext
 return self._nametowidget(name)
   File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1064, in nametowidget
 if name[0] == '.':
TypeError: '_tkinter.Tcl_Obj' object is unsubscriptable
---

-- 
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is there an easy way to sort a list by two criteria?

2008-02-10 Thread neocortex

Hello!
Thank you all, so much! Now I can do double-criteria sort in at least
three ways. More than I have expected.

Best,
PM
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

On Feb 9, 5:03 pm, Neal Becker <[EMAIL PROTECTED]> wrote:
> If I use C code to turn off the hardware signal, will that stop python from
> detecting the exception, or is python checking for 0 denominator on it's
> own (hope not, that would waste cycles).

Yes, Python does do an explicit check for a zero denominator.  Here's
an excerpt from floatdiv.c in Objects/floatobject.c:

if (b == 0.0) {
PyErr_SetString(PyExc_ZeroDivisionError, "float division");
return NULL;
}

This is probably the only sane way to deal with differences in
platform behaviour when doing float divisions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Better way to negate a boolean list?

2008-02-10 Thread David Trémouilles

Thanks to all of you for the prompt answer to my question.

Just a short feedback:
 >>> map(not_, boolean_list)
looks more readable to me
but:
 >>> [not elem for elem in boolean_list]
seems to be slightly faster (ipython timeit results)
(python 2.5.1 MacOS X)

Not a big deal anyway!
Most important for me was to understand the strange "not" behavior.

Thanks again,

David


Gary Herron a écrit :
> David Trémouilles wrote:
>> Hi,
>>
>>   Is there any better (shorter) way to negate a boolean list than:
>>  >>> negated_boolean_list = [not elem for elem in boolean_list]
>> ?
>>
>> I tried:
>>  >>> map(not, boolean_list)
>> but it seems that "not" is not a function.
>>
>> Thanks in advance,
>>
>> David
>>   
> But import module operator, and find operator.not_ which is a function
> and does what you want.
> 
> Gary Herron
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Better way to negate a boolean list?

2008-02-10 Thread Paddy

On Feb 10, 1:41 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> Paddy wrote:
> > On Feb 10, 7:46 am, David Trémouilles <[EMAIL PROTECTED]> wrote:
> >> Hi,
>
> >>   Is there any better (shorter) way to negate a boolean list than:
> >>  >>> negated_boolean_list = [not elem for elem in boolean_list]
> >> ?
>
> >> I tried:
> >>  >>> map(not, boolean_list)
> >> but it seems that "not" is not a function.
>
> >> Thanks in advance,
>
> >> David
>
> > Try [not x for x in boolean_list]
>
> This six-character shortening by renaming the comprehension's bound
> variable was a joke, right?
No,
Of course not!
It's much worse - I completely missed the line beginning negated_
on
first and second reading.
I am indeed getting older, although I had thought I was way off my
dotage.

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

Re: Plotting 3d points

2008-02-10 Thread Paul McGuire

On Feb 10, 4:37 am, Rasmus Kjeldsen <[EMAIL PROTECTED]> wrote:
> Anybody know of a simple way to plot 3d points? Nothing fancy, just points.
> I've tried looking into Mayavi, but can't really find out how to get get
> 3 arrays (x,y,z) into a vtk file. I've also seen mlab mentioned, but how
> do I install that, and import it? I can't get the examples i've seen of
> mlab to make any sense (the importing the module part, that is!).
>
> Rasmus Kjedlsen

A while back, I recommended using slut in this post:
http://mail.python.org/pipermail/python-list/2007-August/455309.html.

slut has a pretty hefty footprint, but once you have plotted the
points, you can also interact with the plot using mouse gestures.  My
website has a little Wink demo of the interaction with a series of
points plotted on the surface of a sphere, plus a path connecting
them: http://www.geocities.com/ptmcg/python/sphere1.htm

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

Re: Turn off ZeroDivisionError?

2008-02-10 Thread Dikkie Dik

Mark Dickinson wrote:
> On Feb 9, 5:03 pm, Neal Becker <[EMAIL PROTECTED]> wrote:
>> If I use C code to turn off the hardware signal, will that stop python from
>> detecting the exception, or is python checking for 0 denominator on it's
>> own (hope not, that would waste cycles).
> 
> Yes, Python does do an explicit check for a zero denominator.  Here's
> an excerpt from floatdiv.c in Objects/floatobject.c:
> 
> if (b == 0.0) {
> PyErr_SetString(PyExc_ZeroDivisionError, "float division");
> return NULL;
> }
> 
> This is probably the only sane way to deal with differences in
> platform behaviour when doing float divisions.
Are you sure?

It could very well be that 1/(smallest possible number)>(greatest 
possible number). So I would also trap any errors besides trapping for 
the obvious zero division.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sort functions in python

2008-02-10 Thread Jeff Schwab

Steven D'Aprano wrote:
> On Sat, 09 Feb 2008 14:28:15 -0800, Jeff Schwab wrote:
> 
>> Steven D'Aprano wrote:
>>> On Sat, 09 Feb 2008 13:37:23 -0800, Jeff Schwab wrote:
>>>
 Carl Banks wrote:
> On Feb 8, 10:09 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote:
>> If you expect your data to be pretty nearly sorted already, but you
>> just want to make sure (e.g. because a small number of elements may
>> have been inserted or removed since the last sort), bubble-sort is a
>> good choice.
> But if you're at that stage you probably were doing something wrong
> in the first place.
 How do you figure?  You don't always have control over the
 insertions/replacements, or where they happen.  As a silly example,
 assume you have a sorted list of children, by height.  Maybe you check
 your list once per school semester.  The new sort order for any given
 semester will likely be very close to the previous order; however, a
 few
   swaps may be in order, according to the different speeds at which
 children have grown.
>>> You check their heights once per semester, but you're worried about an
>>> extra ten or twenty microseconds to sort the data?
>> Are you serious?
>>
>> The fact that you wouldn't use a Python script for this is what makes it
>> a "silly" example in the first place.
> 
> 
> Okay, now you've broken my brain. Why on earth do you think Python isn't 
> suitable for processing a list of a few hundred, or even thousand, items?

Either you're joking, or we're definitely not getting anywhere.  I think 
we're through here.  See you else-thread.  No hard feelings.
-- 
http://mail.python.org/mailman/listinfo/python-list

python 3.0 memory leaking?

2008-02-10 Thread rupert.thurner

the edgewall trac release 0.11 is blocked now since more than one
month for a memory leak nobody is able to find, see
http://groups.google.com/group/trac-dev/browse_thread/thread/116e519da54f16b
.

does python-3.0 improve something to avoid writing memory leaking
applications?

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

Reducing types

2008-02-10 Thread bearophileHUGS

For me Python is useful to write code that gives *correct* results,
allowing me to write it in a short & simple way, with quick debugging
cycles (and for other purposes, like to write dynamic code, to use it
as glue language to use libraries, to create quick GUIs, as scripting
for data munging, etc). When I need more speed I use the D language,
or Psyco, or C, etc.

Python 2.5 has string, unicode, long, int, float, and Decimal types.
Python 3.0 reduces them to string (+ the byte type) int, float, and
Decimal. So why not adopt the Decimal (IEEE 854) as the standard
"float" for Python (if speed is a concern, than a mfloat type may be
introduced, it's a "machine float", it's essentially the "float" of
Python 2.5, operations between a float and a mfloat give a mfloat)? It
can reduce some FP bugs, and avoid those 5.89 + 3.99 =
9.879 bugs that puzzle newbies, that are okay in a very
fast low-level language like C++, but probably unfit for a high-level
one :-)

Bye,
bearophile
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reducing types

2008-02-10 Thread Paul McGuire

On Feb 10, 1:19 pm, [EMAIL PROTECTED] wrote:
> So why not adopt the Decimal (IEEE 854) as the standard
> "float" for Python (if speed is a concern, than a mfloat type may be
> introduced, it's a "machine float", it's essentially the "float" of
> Python 2.5, operations between a float and a mfloat give a mfloat)? It
> can reduce some FP bugs, and avoid those 5.89 + 3.99 =
> 9.879 bugs that puzzle newbies, that are okay in a very
> fast low-level language like C++, but probably unfit for a high-level
> one :-)
>
> Bye,
> bearophile

Sounds like you've been reading about Cobra...

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

Re: python 3.0 memory leaking?

2008-02-10 Thread Jeroen Ruigrok van der Werven

Hi Rupert,

-On [20080210 20:16], rupert.thurner ([EMAIL PROTECTED]) wrote:
>the edgewall trac release 0.11 is blocked now since more than one
>month for a memory leak nobody is able to find, see
>http://groups.google.com/group/trac-dev/browse_thread/thread/116e519da54f16b
>.

You are slightly mistaken that nobody is able to find anything. There is
currently a lot underway to fix this. The problem was not just one area, but
problems on a number of areas. Given the fact nobody uses a large enough
site with a 0.11 trunk installation these sort of things will start to show
during beta test, as it did. This is still beta period and I personally
would rather release a month later (even despite the already long release
time) than give our users a solution that eats away at their resources like
crazy. I am sure people will appreciate the latter more in the end. Already
the current fixes in trunk for Trac and Genshi stabilized a few large beta
deployment sites in terms of resource eating.

>does python-3.0 improve something to avoid writing memory leaking
>applications?

There are efforts underway to optimize the memory usage for 2.6 on a lot of
levels more than 2.5 already did. Check Python-dev of the last 2-3 weeks.
However, this is not interesting in the short term, since 2.4 and 2.5 (and
later on 2.6) will be versions that will be used for the coming 1-2 years
for sure. Avoidance is very difficult, especially given Python's dynamic
nature. But I'll let more knowledgeable minds talk about that.

For me, a relative newbie to Python, the entire memory allocation issue is
not transparent at all and information about it is scattered across the net.
One of the things I hope to contribute to in the coming year is to make sure
the entire area of Python memory use and proper coding is better understood.

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
What is to be, will be. And what isn't to be sometimes happens...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3.0 memory leaking?

Jeroen Ruigrok van der Werven wrote:
> For me, a relative newbie to Python, the entire memory allocation issue is
> not transparent at all and information about it is scattered across the net.
> One of the things I hope to contribute to in the coming year is to make sure
> the entire area of Python memory use and proper coding is better understood.

Python uses its own memory allocator for small objecst (< 257 bytes).
Larger objects are allocated directly with malloc, smaller objects end
up in arenas. The code is well documented in
http://svn.python.org/view/python/trunk/Objects/obmalloc.c?rev=56476&view=auto

Several objects keep a free list for performance reasons. Free list save
some extra mallocs and initialization of data structures. I've renamed
all free lists in Python 2.6 to "free_list".

Ints and floats are using their own block allocation algorithm. The code
predates Python's pymalloc code. I'm working on replacing the code with
 pymalloc because pymalloc-ed memory is given back to the OS. The int
and float free lists keep their sizes until the Python process ends.

Christian

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

Re: python 3.0 memory leaking?

rupert.thurner wrote:
> does python-3.0 improve something to avoid writing memory leaking
> applications?

No, it doesn't. Python 3.0 and maybe 2.6 are going to have some small
improvements but the improvements aren't related to memory leaking. I'm
working on the matter for a while now. I've limited some free lists and
I've a patch that gives allocated memory back to the OS earlier.

Have you followed my advice and checked all places that deal with
frames, tracebacks, exception objects and __del__ methods?

Christian

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

Re: Turn off ZeroDivisionError?

2008-02-10 Thread bearophileHUGS

Mark Dickinson:
> This is probably the only sane way to deal with differences in
> platform behaviour when doing float divisions.

What Python run on a CPU that doesn't handle the nan correctly?

Bye,
bearophile
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reducing types

2008-02-10 Thread bearophileHUGS

Paul McGuire:
> Sounds like you've been reading about Cobra...

I have heard about that language (for dotnet?) but my idea doesn't
come from Cobra...

Bye,
bearophile
-- 
http://mail.python.org/mailman/listinfo/python-list

Useful site for beginners

2008-02-10 Thread subeen

This website can be helpful for Python newbies: http://love-python.blogspot.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

2008-02-10 Thread Steve Holden

Dikkie Dik wrote:
> Mark Dickinson wrote:
>> On Feb 9, 5:03 pm, Neal Becker <[EMAIL PROTECTED]> wrote:
>>> If I use C code to turn off the hardware signal, will that stop python from
>>> detecting the exception, or is python checking for 0 denominator on it's
>>> own (hope not, that would waste cycles).
>> Yes, Python does do an explicit check for a zero denominator.  Here's
>> an excerpt from floatdiv.c in Objects/floatobject.c:
>>
>> if (b == 0.0) {
>> PyErr_SetString(PyExc_ZeroDivisionError, "float division");
>> return NULL;
>> }
>>
>> This is probably the only sane way to deal with differences in
>> platform behaviour when doing float divisions.
> Are you sure?
> 
> It could very well be that 1/(smallest possible number)>(greatest 
> possible number). So I would also trap any errors besides trapping for 
> the obvious zero division.

What's so special about one? You surely don't expect the Python code to 
check for all possible cases of overflow before allowing the hardware to 
proceed with a division?

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

Re: Turn off ZeroDivisionError?

On 2008-02-10, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> On Feb 9, 5:03 pm, Neal Becker <[EMAIL PROTECTED]> wrote:
>> If I use C code to turn off the hardware signal, will that stop python from
>> detecting the exception, or is python checking for 0 denominator on it's
>> own (hope not, that would waste cycles).
>
> Yes, Python does do an explicit check for a zero denominator.  Here's
> an excerpt from floatdiv.c in Objects/floatobject.c:
>
> if (b == 0.0) {
> PyErr_SetString(PyExc_ZeroDivisionError, "float division");
> return NULL;
> }
>
> This is probably the only sane way to deal with differences in
> platform behaviour when doing float divisions.

I've always found that check to be really annoying.  Every time
anybody asks about floating point handling, the standard
response is that "Python just does whatever the underlying
platform does".  Except it doesn't in cases like this. All my
platforms do exactly what I want for division by zero: they
generate a properly signed INF.  Python chooses to override
that (IMO correct) platform behavior with something surprising.
Python doesn't generate exceptions for other floating point
"events" -- why the inconsistency with divide by zero?

-- 
Grant Edwards   grante Yow!  Where's th' DAFFY
  at   DUCK EXHIBIT??
   visi.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Displaying Unicode Chars

2008-02-10 Thread [EMAIL PROTECTED]

I want to make a little Python utility where a user can enter the
unicode numerical code and get the actual symbol back in utf-8.

For example, a user could enter something like u221E

And get back ∞

Now, this does seem to work:

>>> print u"\u221E"
∞
However how can I change it so it works with a string variable?

print unicode("\u221E") doesn't seem to do it.

I hope this makes sense.  I don't know all the unicode terminology to
phrase this question coherently ;-)

Thanks in advance,

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

Re: Useful site for beginners

2008-02-10 Thread James Matthews

If you don't mind me recommending that you include links to python
documentation and show new users how they can read the docs and see the
info!

James

On Feb 10, 2008 9:30 PM, subeen <[EMAIL PROTECTED]> wrote:

> This website can be helpful for Python newbies:
> http://love-python.blogspot.com/
> --
> http://mail.python.org/mailman/listinfo/python-list
>

-- 
http://search.goldwatches.com/?Search=Movado+Watches
http://www.jewelerslounge.com
http://www.goldwatches.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Displaying Unicode Chars

2008-02-10 Thread James Matthews

Why don't you use ord?

2008/2/10 [EMAIL PROTECTED] <[EMAIL PROTECTED]>:

> I want to make a little Python utility where a user can enter the
> unicode numerical code and get the actual symbol back in utf-8.
>
> For example, a user could enter something like u221E
>
> And get back ∞
>
> Now, this does seem to work:
>
> >>> print u"\u221E"
> ∞
> However how can I change it so it works with a string variable?
>
> print unicode("\u221E") doesn't seem to do it.
>
> I hope this makes sense.  I don't know all the unicode terminology to
> phrase this question coherently ;-)
>
> Thanks in advance,
>
> Greg
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
http://search.goldwatches.com/?Search=Movado+Watches
http://www.jewelerslounge.com
http://www.goldwatches.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

2008-02-10 Thread Neal Becker

[EMAIL PROTECTED] wrote:

> Would a wrapper function be out of the question here?
> 
> def MyDivision(num, denom):
> if denom==0:
> return "NaN"
> else
> return num / denom

I bought a processor that has hardware to implement this.  Why do I want
software to waste time on it?

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

Re: Turn off ZeroDivisionError?

Grant Edwards wrote:
> I've always found that check to be really annoying.  Every time
> anybody asks about floating point handling, the standard
> response is that "Python just does whatever the underlying
> platform does".  Except it doesn't in cases like this. All my
> platforms do exactly what I want for division by zero: they
> generate a properly signed INF.  Python chooses to override
> that (IMO correct) platform behavior with something surprising.
> Python doesn't generate exceptions for other floating point
> "events" -- why the inconsistency with divide by zero?

I'm aware result is arguable and professional users may prefer +INF for
1/0. However Python does the least surprising thing. It raises an
exception because everybody has learned at school 1/0 is not allowed.

>From the PoV of a mathematician Python does the right thing, too. 1/0 is
not defined, only the lim(1/x) for x -> 0 is +INF. From the PoV of a
numerics guy it's surprising.

Do you suggest that 1./0. results into +INF [1]? What should be the
result of 1/0?

Christian

[1]
http://en.wikipedia.org/wiki/Division_by_zero#Division_by_zero_in_computer_arithmetic

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

Re: Turn off ZeroDivisionError?

2008-02-10 Thread Jeff Schwab

Neal Becker wrote:
> [EMAIL PROTECTED] wrote:
> 
>> Would a wrapper function be out of the question here?
>>
>> def MyDivision(num, denom):
>> if denom==0:
>> return "NaN"
>> else
>> return num / denom
> 
> I bought a processor that has hardware to implement this.  Why do I want
> software to waste time on it?

Will the amount of time wasted by the software exceed the amount of time 
required to implement Python-level access to the hardware feature?  At 
any rate, the work-around should at least let you work on the rest of 
the application, while a more efficient implementation can be developed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Displaying Unicode Chars

2008-02-10 Thread Martin v. Löwis

> I want to make a little Python utility where a user can enter the
> unicode numerical code and get the actual symbol back in utf-8.
> 
> For example, a user could enter something like u221E

I'm puzzled why the user would enter "u221E" - why not just "221E"?

> And get back ∞
> 
> Now, this does seem to work:
> 
 print u"\u221E"
> ∞
> However how can I change it so it works with a string variable?

The problem is not with variables - print can output variables
just fine:

text = u"\u221E"
print text

(where text is a variable holding a Unicode string)

Your problem is with data conversion: how to convert a string
holding a hexadecimal integer number into a Unicode
character whose ordinal is that number?

To do so, you need two steps (assuming you start from "221E")
0. char = "221E"
1. convert that into an integer: char = int(char, 16)
2. convert that into a Unicode character: char = unichr(char)
3. print it: print char

If you insist on the user entering "u221E" instead, you have
to convert that first into a string without the leading u:

0.5 char = char[1:]

HTH,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

On 2008-02-10, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Grant Edwards wrote:
>
>> I've always found that check to be really annoying.  Every
>> time anybody asks about floating point handling, the standard
>> response is that "Python just does whatever the underlying
>> platform does".  Except it doesn't in cases like this. All my
>> platforms do exactly what I want for division by zero: they
>> generate a properly signed INF.  Python chooses to override
>> that (IMO correct) platform behavior with something
>> surprising. Python doesn't generate exceptions for other
>> floating point "events" -- why the inconsistency with divide
>> by zero?
>
> I'm aware result is arguable and professional users may prefer
> +INF for 1/0. However Python does the least surprising thing.

It appears that you and I are surprised by different things.

> It raises an exception because everybody has learned at school
> 1/0 is not allowed.

You must have gone to a different school than I did.  I learned
that for IEEE floating point operations a/0. is INF with the
same sign as a (except when a==0, then you get a NaN).

>>From the PoV of a mathematician Python does the right thing,
>>too. 1/0 is not defined, only the lim(1/x) for x -> 0 is +INF.
>>From the PoV of a numerics guy it's surprising.
>
> Do you suggest that 1./0. results into +INF [1]?

That's certainly what I expected after being told that Python
doesn't do anything special with floating point operations and
leaves it all up to the underlying hardware. Quoting from the
page to linked to, it's also what the IEEE standard specifies:

   The IEEE floating-point standard, supported by almost all
   modern processors, specifies that every floating point
   arithmetic operation, including division by zero, has a
   well-defined result. In IEEE 754 arithmetic, a/0 is positive
   infinity when a is positive, negative infinity when a is
   negative, and NaN (not a number) when a = 0.

I was caught completely off guard when I discovered that Python
goes out of its way to violate that standard, and it resulted
in my program not working correctly.

> What should be the result of 1/0?

I don't really care.  An exception is OK with me, but I don't
write code that does integer divide by zero operations.

-- 
Grant Edwards   grante Yow!  does your DRESSING
  at   ROOM have enough ASPARAGUS?
   visi.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3.0 memory leaking?

2008-02-10 Thread rupert.thurner

On Feb 10, 9:08 pm, Christian Heimes <[EMAIL PROTECTED]> wrote:
> rupert.thurner wrote:
> > does python-3.0 improve something to avoid writing memory leaking
> > applications?
>
> No, it doesn't. Python 3.0 and maybe 2.6 are going to have some small
> improvements but the improvements aren't related to memory leaking. I'm
> working on the matter for a while now. I've limited some free lists and
> I've a patch that gives allocated memory back to the OS earlier.
>
> Have you followed my advice and checked all places that deal with
> frames, tracebacks, exception objects and __del__ methods?
>
> Christian

many thanks christian! do you have any code examples how to handle
frames, tracebacks, exception objects and __del__ correctly?

btw, i put your hints on http://wiki.python.org/moin/FreeMemory.

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

Re: Turn off ZeroDivisionError?

On Feb 10, 3:10 pm, [EMAIL PROTECTED] wrote:
> What Python run on a CPU that doesn't handle the nan correctly?

How about platforms that don't even have nans?  I don't think either
IBM's hexadecimal floating-point format, or the VAX floating-point
formats
support NaNs.  Python doesn't assume IEEE 754 hardware;  though much
of its code
could be a lot simpler if it did :-).
rywhere ;-).

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

Re: Turn off ZeroDivisionError?

On 2008-02-10, Neal Becker <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
>> Would a wrapper function be out of the question here?
>> 
>> def MyDivision(num, denom):
>> if denom==0:
>> return "NaN"
>> else
>> return num / denom
>
> I bought a processor that has hardware to implement this.  Why do I want
> software to waste time on it?

Exactly.  Espeically when Python supposedly leaves floating
point ops up to the platform.

-- 
Grant Edwards   grante Yow!  Don't hit me!! I'm in
  at   the Twilight Zone!!!
   visi.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

On 2008-02-10, Jeff Schwab <[EMAIL PROTECTED]> wrote:
> Neal Becker wrote:
>> [EMAIL PROTECTED] wrote:
>> 
>>> Would a wrapper function be out of the question here?
>>>
>>> def MyDivision(num, denom):
>>> if denom==0:
>>> return "NaN"
>>> else
>>> return num / denom
>> 
>> I bought a processor that has hardware to implement this.  Why do I want
>> software to waste time on it?
>
> Will the amount of time wasted by the software exceed the amount of time 
> required to implement Python-level access to the hardware feature?

The "time required to implement Python-level access to the
hardware features" is simply the time required to delete the
lines of code that raise an exception when demon is 0.0

> At any rate, the work-around should at least let you work on
> the rest of the application, while a more efficient
> implementation can be developed.

A more efficient implementation?  Just delete the code that
raises the exception and the HW will do the right thing.

-- 
Grant Edwards   grante Yow!  Do you need
  at   any MOUTH-TO-MOUTH
   visi.comresuscitation?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

On Feb 10, 3:29 pm, Grant Edwards <[EMAIL PROTECTED]> wrote:
> platform does".  Except it doesn't in cases like this. All my
> platforms do exactly what I want for division by zero: they
> generate a properly signed INF.  Python chooses to override
> that (IMO correct) platform behavior with something surprising.
> Python doesn't generate exceptions for other floating point
> "events" -- why the inconsistency with divide by zero?

But not everyone wants 1./0. to produce an infinity;  some people
would prefer an exception.

Python does try to generate exceptions for floating-point events
at least some of the time---e.g. generating ValueErrors for
sqrt(-1.) and log(-1.) and OverflowError for exp(large_number).

I agree that the current situation is not ideal.  I think the ideal
would be to have a floating-point environment much like Decimal's,
where the user has control over whether floating-point exceptions
are trapped (producing Python exceptions) or not (producing
infinities
and nans).  The main difficulty is in writing reliable ANSI C that
can do this across platforms.  It's probably not impossible, but
it is a lot of work.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

2008-02-10 Thread Paul Rubin

Christian Heimes <[EMAIL PROTECTED]> writes:
> Python targets both newbies and professionals.
> That's the reason for two math modules (math and cmath).

Ehhh???  cmath is for complex-valued functions, nothing to do with
newbies vs. professionals.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Chinese character error

2008-02-10 Thread John Deas

On Feb 9, 3:00 am, "Mark Tolonen" <[EMAIL PROTECTED]>
wrote:
> "Chris" <[EMAIL PROTECTED]> wrote in message
>
> news:[EMAIL PROTECTED]
>
>
>
> > On Feb 8, 11:29 am, John Deas <[EMAIL PROTECTED]> wrote:
> >> Hi,
>
> >> I made a small script to recursively copy files from a directory tree
> >> to an exportDir only if they have an mp3 extension :
>
> >> a=os.walk(os.getcwd())
> >> for root, dirs, files in a:
> >> for currFile in files:
> >> pathCurrFile=os.path.join(root, currFile)
> >> if mp3Reg.search(pathCurrFile):
> >> shutil.copy(pathCurrFile,exportDir)
> >> else:
> >> print pathCurrFile
>
> >> The problem is that I get stuck with files containing name in
> >> Chinese :
>
> >> Traceback (most recent call last):
> >>   File "/cygdrive/c/Documents and Settings/vku/Mes documents/Ma
> >> musique/iTunes/i
> >> Tunes Music/script.py", line 21, in 
> >> shutil.copy(pathCurrFile,exportDir)
> >>   File "/usr/lib/python2.5/shutil.py", line 80, in copy
> >> copyfile(src, dst)
> >>   File "/usr/lib/python2.5/shutil.py", line 46, in copyfile
> >> fsrc = open(src, 'rb')
> >> IOError: [Errno 2] No such file or directory: '/cygdrive/c/Documents
> >> and Setting
> >> s/vku/Mes documents/Ma musique/iTunes/iTunes Music/Podcasts/Learn
> >> Chinese - Chin
> >> esePod/785 Advanced - .mp3'
>
> >> I am using python oncygwin, so could this be the source of the error,
> >> and is there a way to fix this ?
>
> > It has to do with the way the OS reports the filename.  Explorers GUI
> > diplays it as square blocks and both CmdPrompt +Cygwindisplay it as
> > Question marks as does the os.listdir in Python.  Copying Chinese
> > Characters and checking their Ordinal Values directly from python gave
> > me for eg. 230+188+162 for 1 Chinese Charater yet Python shows it is
> > Ordinal 63 (a Question Mark) after reading the filename.
>
> > Those files you will need to manually copy, I even tried
> > find /cygdrive/d/Temp/ -name "*.mp3" -exec cp {} /cygdrive/d/Temp/
> > test/ \;
> > which yielded
> > cp: cannot stat '/cygdrive/d/Temp/??.mp3': No such file or directory
>
> If you call os.walk() with a Unicode string, it's return values will be
> Unicode as well and you should be able to process files with non-ASCII
> characters.  This worked for me (on Windows):
>
> import os
> import shutil
> import fnmatch
>
> exportDir = u'c:\\mp3s'
>
> a=os.walk(os.getcwdu()) # Unicode version of os.getcwd()
> for root, dirs, files in a:
> for currFile in files:
> pathCurrFile=os.path.join(root, currFile)
> if fnmatch.fnmatch(pathCurrFile,u'*.mp3'):
> shutil.copy(pathCurrFile,exportDir)
> else:
> print pathCurrFile
>
> --Mark

Hi,

I tried to play around with the advice you gave me.

When I do this in the directory containing an unicode-named mp3:

import os, shutil
os.listdir(os.getcwdu())

I get :

[u'The Pixies - Where is my mind (fight club).mp3', u'???.mp3']

Than, if try to copy it with :

shutil.copy(os.listdir(os.getcwdu())[1],u'test.mp3')

I get :

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.5/shutil.py", line 80, in copy
copyfile(src, dst)
  File "/usr/lib/python2.5/shutil.py", line 46, in copyfi
fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory: u'???.mp3'

Have you any idea why this is not working on my computer ?

Tanks,

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

Re: Turn off ZeroDivisionError?

Grant Edwards wrote:
> A more efficient implementation?  Just delete the code that
> raises the exception and the HW will do the right thing.

Do you really think that the hardware and the C runtime library will do
the right thing? Python runs on a lots platforms and architectures. Some
of the platforms don't have a FPU or don't support hardware acceleration
for floating point ops for user space applications. Some platforms don't
follow IEEE 754 semantics at all.

It took us a lot of effort to get consistent results for edge cases of
basic functions like sin and atan on all platforms. Simply removing
those lines and praying that it works won't do it.

Christian

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

Re: Turn off ZeroDivisionError?

2008-02-10 Thread Jeff Schwab

Grant Edwards wrote:
> On 2008-02-10, Jeff Schwab <[EMAIL PROTECTED]> wrote:
>> Neal Becker wrote:
>>> [EMAIL PROTECTED] wrote:
>>>
 Would a wrapper function be out of the question here?

 def MyDivision(num, denom):
 if denom==0:
 return "NaN"
 else
 return num / denom
>>> I bought a processor that has hardware to implement this.  Why do I want
>>> software to waste time on it?
>> Will the amount of time wasted by the software exceed the amount of time 
>> required to implement Python-level access to the hardware feature?
> 
> The "time required to implement Python-level access to the
> hardware features" is simply the time required to delete the
> lines of code that raise an exception when demon is 0.0

You mean the C code that implements the interpreter?  Assuming the 
developer is comfortable getting the Python source code, modifying it, 
compiling and deploying the modified version:  In the best case, the 
change introduces a portability nightmare.  In the worst case, you break 
all kinds of existing code, possibly in the standard libraries, that 
assumes an exception will be throw on any attempt to divide by zero.

>> At any rate, the work-around should at least let you work on
>> the rest of the application, while a more efficient
>> implementation can be developed.
> 
> A more efficient implementation?  Just delete the code that
> raises the exception and the HW will do the right thing.

"Just fork python" is not a simpler solution than "just use this 
pure-python function."  Whether it's worth the headache can be 
considered at length, but in the meantime, the pure-python solution is 
quicker, safer way to continue development of the client code that 
requires the functionality (NaN on divide-by-zero).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

Grant Edwards wrote:
> You must have gone to a different school than I did.  I learned
> that for IEEE floating point operations a/0. is INF with the
> same sign as a (except when a==0, then you get a NaN).

I'm not talking about CS and IEEE floating point ops. I was referring to
plain good old math. Python targets both newbies and professionals.
That's the reason for two math modules (math and cmath).

> That's certainly what I expected after being told that Python
> doesn't do anything special with floating point operations and
> leaves it all up to the underlying hardware. Quoting from the
> page to linked to, it's also what the IEEE standard specifies:
> 
>The IEEE floating-point standard, supported by almost all
>modern processors, specifies that every floating point
>arithmetic operation, including division by zero, has a
>well-defined result. In IEEE 754 arithmetic, a/0 is positive
>infinity when a is positive, negative infinity when a is
>negative, and NaN (not a number) when a = 0.
> 
> I was caught completely off guard when I discovered that Python
> goes out of its way to violate that standard, and it resulted
> in my program not working correctly.

Python's a/0 outcome doesn't violate the standards because Python
doesn't promise to follow the IEEE 754 standard in the first place. Mark
and I are working hard to make math in Python more reliable across
platforms. So far we have fixed a lot of problems but we haven't
discussed the a/0 matter.

The best we could give you is an option that makes Python's floats more
IEEE 754 like:

>>> from somemodule import ieee754
>>> with ieee754:
...r = a/0
...print r
inf

Christian

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

Re: Displaying Unicode Chars

2008-02-10 Thread Bjoern Schliessmann

[EMAIL PROTECTED] wrote:

> However how can I change it so it works with a string variable?
>
> print unicode("\u221E") doesn't seem to do it.

Sure, that's because \u only works in unicode strings. You'd need
to "encode" your \u-containing string to a unicode string. Perhaps
this'll help:

>>> def to_unicode(num):
... character = "\\u"+num
... return character.decode("unicode-escape")
... 
>>> to_unicode("221E")
u'\u221e'
>>> print to_unicode("221E")
∞

(improvements welcome)

Regards,

Björn

-- 
BOFH excuse #273:

The cord jumped over and hit the power switch.

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

Re: Turn off ZeroDivisionError?

On Feb 10, 4:56 pm, Grant Edwards <[EMAIL PROTECTED]> wrote:
> Exactly.  Espeically when Python supposedly leaves floating
> point ops up to the platform.

There's a thread at 
http://mail.python.org/pipermail/python-list/2005-July/329849.html
that's quite relevant to this discussion.  See especially the
exchanges between Michael
Hudson and Tim Peters in the later part of the thread.  I like this
bit, from Tim:

"I believe Python should raise exceptions in these cases by default,
because, as above, they correspond to the overflow and
invalid-operation signals respectively, and Python should raise
exceptions on the overflow, invalid-operation, and divide-by-0
signals
by default.  But I also believe Python _dare not_ do so unless it
also
supplies sane machinery for disabling traps on specific signals
(along
the lines of the relevant standards here).  Many serious numeric
programmers would be livid, and justifiably so, if they couldn't get
non-stop mode back.  The most likely x-platfrom accident so far is
that they've been getting non-stop mode in Python since its
beginning."

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

Re: Turn off ZeroDivisionError?

2008-02-10 Thread Ben Finney

Mark Dickinson <[EMAIL PROTECTED]> writes:

> On Feb 10, 3:29 pm, Grant Edwards <[EMAIL PROTECTED]> wrote:
> > platform does".  Except it doesn't in cases like this. All my
> > platforms do exactly what I want for division by zero: they
> > generate a properly signed INF.  Python chooses to override
> > that (IMO correct) platform behavior with something surprising.
> > Python doesn't generate exceptions for other floating point
> > "events" -- why the inconsistency with divide by zero?
> 
> But not everyone wants 1./0. to produce an infinity;  some people
> would prefer an exception.

Special cases aren't special enough to break the rules.

Most people would not want this behaviour either::

>>> 0.1
0.10001

But the justification for this violation of surprise is "Python just
does whatever the underlying hardware does with floating-point
numbers". If that's the rule, it shouldn't be broken in the special
case of division by zero.

-- 
 \  “If the desire to kill and the opportunity to kill came always |
  `\  together, who would escape hanging?” —Mark Twain, _Following |
_o__) the Equator_ |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

2008-02-10 Thread Neal Becker

Christian Heimes wrote:

> Grant Edwards wrote:
>> A more efficient implementation?  Just delete the code that
>> raises the exception and the HW will do the right thing.
> 
> Do you really think that the hardware and the C runtime library will do
> the right thing? Python runs on a lots platforms and architectures. Some
> of the platforms don't have a FPU or don't support hardware acceleration
> for floating point ops for user space applications. Some platforms don't
> follow IEEE 754 semantics at all.
> 
> It took us a lot of effort to get consistent results for edge cases of
> basic functions like sin and atan on all platforms. Simply removing
> those lines and praying that it works won't do it.
> 
> Christian
> 

I think, ideally, that on a platform that has proper IEEE 754 support we
would rely on the hardware, and only on platforms that don't would we add
extra software emulation.

With proper hardware support, the default would be a hardware floating pt
exception, which python would translate.

If the user wanted, she should be able to turn it off during some
calculation (but that would not be the default).

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

Re: Turn off ZeroDivisionError?

On 2008-02-10, Ben Finney <[EMAIL PROTECTED]> wrote:
> Mark Dickinson <[EMAIL PROTECTED]> writes:


>>> platform does". platforms do exactly what I want for division
>>> by zero: they generate a properly signed INF.  Python chooses
>>> to override that (IMO correct) platform behavior with
>>> something surprising. Python doesn't generate exceptions for
>>> other floating point "events" -- why the inconsistency with
>>> divide by zero?
>> 
>> But not everyone wants 1./0. to produce an infinity; some
>> people would prefer an exception.
>
> Special cases aren't special enough to break the rules.
>
> Most people would not want this behaviour either::
>
> >>> 0.1
> 0.10001
>
> But the justification for this violation of surprise is
> "Python just does whatever the underlying hardware does with
> floating-point numbers". If that's the rule, it shouldn't be
> broken in the special case of division by zero.

My feelings exactly.

That's the rule that's always quoted to people asking about
various FP weirdness, but apparently the rule only applies
when/where certain people feel like it.

-- 
Grant Edwards   grante Yow!  YOW!! I'm in a very
  at   clever and adorable INSANE
   visi.comASYLUM!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

On 2008-02-10, Christian Heimes <[EMAIL PROTECTED]> wrote:

> Python's a/0 outcome doesn't violate the standards

It does.

> because Python doesn't promise to follow the IEEE 754 standard in the first 
> place.

Whether a certain behavior violates that standard is
independant of whether somebody promised to follow the standard
or not.

> Mark and I are working hard to make math in Python more
> reliable across platforms. So far we have fixed a lot of
> problems but we haven't discussed the a/0 matter.
>
> The best we could give you is an option that makes Python's floats more
> IEEE 754 like:
>
 from somemodule import ieee754
 with ieee754:
> ...r = a/0
> ...print r
> inf

That would be great.

-- 
Grant Edwards   grante Yow!  A dwarf is passing
  at   out somewhere in Detroit!
   visi.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Help with jabber client in wx

2008-02-10 Thread Astan Chee

Hi,
A project Im working on is a jabber client working with wx to interface 
with uTorrent's webUI using a python API for it. My project can be found 
here:
http://code.google.com/p/gtalktorrent/
A quick note, the project started as a google talk client, but it seems 
that xmpppy is flexible enough to support various other/similar XMPP 
servers, but I mainly use with/in google talk
It is open source and I've included the windows executable as an 
optional download.
The current problem Im having is that whenever the jabber client 
disconnects or whenever a network error occurs (ISP goes down,etc), the 
client does not reconnect. I've added some code to help this, but it 
still doesnt reconnect properly; or rather, it doesnt detect the 
disconnection properly. What am I doing wrong in the xmpppy classes/methods?
I also ask people in the wx community since Im not sure how to overwrite 
or handle the wx MainLoop method and maybe I'm doing something wrong in 
there. Maybe a deadlocked event?
Anyway, does anyone have any ideas?
Cheers
Astan

Animal Logic
http://www.animallogic.com

Please think of the environment before printing this email.

This email and any attachments may be confidential and/or privileged. If you 
are not the intended recipient of this email, you must not disclose or use the 
information contained in it. Please notify the sender immediately and delete 
this document if you have received it in error. We do not guarantee this email 
is error or virus free.



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

Re: Why not a Python compiler?

2008-02-10 Thread castironpi

On Feb 10, 7:29 am, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano wrote:
> > On Sat, 09 Feb 2008 01:11:09 +, Marc 'BlackJack' Rintsch wrote:
>
> >> On Fri, 08 Feb 2008 05:12:29 -0800, Ryszard Szopa wrote:
>
> >>> Expressing simple loops as C for loops...
> >> You mean simple loops like ``for i in xrange(1000):``?  How should the
> >> compiler know what object is bound to the name `xrange` when that loop
> >> is executed?
>
> > Assuming the aim is to optimize for speed rather than memory, the
> > solution is for the compiler to create something like this pseudo-code:
>
> > if xrange is Python's built-in xrange:
> >     execute optimized for-loop at C-like speed
> > else:
> >     execute unoptimized normal loop at Python speed
>
> > (In case it's not obvious, the decision of which branch to take is made
> > at run time, not compile time.)
>
> > I understand that is more or less what psycho already does.
>
> ... and Cython, when iterating over lists, for example. That's one of the
> reasons why looping is so much faster in Cython than in Pyrex.
>
> Stefan- Hide quoted text -
>
> - Show quoted text -

There's always the Visitor pattern.

in xrange(1).for x:
loop_of_x_at_forlike_speed()

Do identifiers get hashed once at compile/ definition-execution time,
or every time they're encountered?  This could be fast...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

2008-02-10 Thread Carl Banks

On Feb 10, 3:29 pm, Grant Edwards <[EMAIL PROTECTED]> wrote:
> On 2008-02-10, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>
> > On Feb 9, 5:03 pm, Neal Becker <[EMAIL PROTECTED]> wrote:
> >> If I use C code to turn off the hardware signal, will that stop python from
> >> detecting the exception, or is python checking for 0 denominator on it's
> >> own (hope not, that would waste cycles).
>
> > Yes, Python does do an explicit check for a zero denominator.  Here's
> > an excerpt from floatdiv.c in Objects/floatobject.c:
>
> > if (b == 0.0) {
> > PyErr_SetString(PyExc_ZeroDivisionError, "float division");
> > return NULL;
> > }
>
> > This is probably the only sane way to deal with differences in
> > platform behaviour when doing float divisions.
>
> I've always found that check to be really annoying.  Every time
> anybody asks about floating point handling, the standard
> response is that "Python just does whatever the underlying
> platform does".  Except it doesn't in cases like this. All my
> platforms do exactly what I want for division by zero: they
> generate a properly signed INF.  Python chooses to override
> that (IMO correct) platform behavior with something surprising.
> Python doesn't generate exceptions for other floating point
> "events" -- why the inconsistency with divide by zero?

I understand your pain, but Python, like any good general-purpose
language, is a compromise.  For the vast majority of programming,
division by zero is a mistake and not merely a degenerate case, so
Python decided to treat it like one.


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

Re: Reducing types

2008-02-10 Thread Dan Bishop

On Feb 10, 1:19 pm, [EMAIL PROTECTED] wrote:
> For me Python is useful to write code that gives *correct* results,
> allowing me to write it in a short & simple way, with quick debugging
> cycles (and for other purposes, like to write dynamic code, to use it
> as glue language to use libraries, to create quick GUIs, as scripting
> for data munging, etc). When I need more speed I use the D language,
> or Psyco, or C, etc.
>
> Python 2.5 has string, unicode, long, int, float, and Decimal types.
> Python 3.0 reduces them to string (+ the byte type) int, float, and
> Decimal. So why not adopt the Decimal (IEEE 854) as the standard
> "float" for Python (if speed is a concern, than a mfloat type may be
> introduced, it's a "machine float", it's essentially the "float" of
> Python 2.5, operations between a float and a mfloat give a mfloat)? It
> can reduce some FP bugs, and avoid those 5.89 + 3.99 =
> 9.879 bugs that puzzle newbies, that are okay in a very
> fast low-level language like C++, but probably unfit for a high-level
> one :-)

(1) Because, although speed may not be the primary focus of Python,
it's still relevant.  And float has a HUGE speed advantage over
Decimal.

(2) Because decimal arithmetic isn't a panacea for floating-point
errors.  I have a decimal calculator at hand, and while it gives the
correct result for 5.89 + 3.99, it gives slightly incorrect results
for 1/3*3 and sqrt(3)**2.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

On Feb 10, 5:50 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> Most people would not want this behaviour either::
>
>     >>> 0.1
>     0.10001

Sure. And if it weren't for backwards-compatibility and speed issues
one
could reasonably propose making Decimal the default floating-point
type
in Python (whilst still giving access to the hardware binary floating
point).
I dare say that the backwards-compatibility isn't really a problem:  I
can
imagine a migration strategy resulting in Decimal default floats in
Python 4.0  ;-).  But there are orders-of-magnitude differences in
speed
that aren't going to be solved by merely rewriting decimal.py in C.

I guess it's all about tradeoffs.

> But the justification for this violation of surprise is "Python just
> does whatever the underlying hardware does with floating-point
> numbers". If that's the rule, it shouldn't be broken in the special
> case of division by zero.

I'm not convinced that this is really the justification, but I'm not
quite sure
what we're talking about here.  The justification for *printing*
0.1000...1 instead
of 0.1 has to do with not hiding binary floating-point strangeness
from users, since
they're eventually going to have to deal with it anyway, and hiding it
arguably
causes worse difficulties in understanding.  The justification for
having
the literal 0.1 not *be* exactly the number 0.1:  well, what are the
alternatives?
Decimal and Rational are very slow in comparison with float, and
historically
Decimal wasn't even available until recently.

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

Re: Error on Python

2008-02-10 Thread timr

On Sat, Feb 09, 2008 at 11:05:34PM -0500, Steve Holden wrote:
> Tim Roberts wrote:
> > maehhheeyy <[EMAIL PROTECTED]> wrote:
> > 
> >> Hi, right now I'm using Python and Multicast. I have the code for
> >> Multicast receiver on Python but I keep getting this error;
> >>
> >> File "", line 1, in bind
> >> error: (10049, "Can't assign requested address")
> >>
> >> The error is coming from this line;
> >> sock.bind ((MCAST_ADDR, MCAST_PORT))
> >>
> >> Can anyone please help me solve this problem?
> > 
> > Where did you get the multicast module?  Are you trying to do TCP
> > multicast?  What is the address you are trying to use?
> 
> TCP multicast? That doesn't make sense, there can only be two endpoints 
> to a TCP connection. But *you* know that.

TCP multicast exists.  There are special IP ranges for it, but it also
takes special support in the local network.  The fact that he used
MCAST_ADDR made me suspicious of that, hence my question.

> Couldn't the port just be in use?

That usually gets 10048, "address in use".
-- 
Tim Roberts, [EMAIL PROTECTED]
Providenza & Boeklheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: pyparsing 1.4.11 released

2008-02-10 Thread Paul McGuire

I have just uploaded version 1.4.11 of pyparsing to SourceForge.  It
has been a pretty full 2 months since the last release, with
contributions from new users, old users, and also some help from the
Google Highly-Open Participation contest.  I think there are some very
interesting new features in this release.  Please check it out!

(Please note - if you download and install the Windows binary, this
will
NOT include the HTML doc or examples directory.  TO get these, you
will
need to download the docs or one of the source distributions.)

The pyparsing wiki is at http://pyparsing.wikispaces.com.

Here are the notes for 1.4.11:

Version 1.4.11 - February 10, 2008
--
- With help from Robert A. Clark, this version of pyparsing
  is compatible with Python 3.0a3.  Thanks for the help,
  Robert!

- Added WordStart and WordEnd positional classes, to support
  expressions that must occur at the start or end of a word.
  Proposed by piranha on the pyparsing wiki, good idea!

- Added matchOnlyAtCol helper parser action, to simplify
  parsing log or data files that have optional fields that are
  column dependent.  Inspired by a discussion thread with
  hubritic on comp.lang.python.

- Added withAttribute.ANY_VALUE as a match-all value when using
  withAttribute.  Used to ensure that an attribute is present,
  without having to match on the actual attribute value.

- Added get() method to ParseResults, similar to dict.get().
  Suggested by new pyparsing user, Alejandro Dubrovksy, thanks!

- Added '==' short-cut to see if a given string matches a
  pyparsing expression.  For instance, you can now write:

integer = Word(nums)
if "123" == integer:
   # do something

print [ x for x in "123 234 asld".split() if x==integer ]
# prints ['123', '234']

- Simplified the use of nestedExpr when using an expression for
  the opening or closing delimiters.  Now the content expression
  will not have to explicitly negate closing delimiters.  Found
  while working with dfinnie on GHOP Task #277, thanks!

- Fixed bug when defining ignorable expressions that are
  later enclosed in a wrapper expression (such as ZeroOrMore,
  OneOrMore, etc.) - found while working with Prabhu
  Gurumurthy, thanks Prahbu!

- Fixed bug in withAttribute in which keys were automatically
  converted to lowercase, making it impossible to match XML
  attributes with uppercase characters in them.  Using with-
  Attribute requires that you reference attributes in all
  lowercase if parsing HTML, and in correct case when parsing
  XML.

- Changed '<<' operator on Forward to return None, since this
  is really used as a pseudo-assignment operator, not as a
  left-shift operator.  By returning None, it is easier to
  catch faulty statements such as a << b | c, where precedence
  of operations causes the '|' operation to be performed
  *after* inserting b into a, so no alternation is actually
  implemented.  The correct form is a << (b | c).  With this
  change, an error will be reported instead of silently
  clipping the alternative term.  (Note: this may break some
  existing code, but if it does, the code had a silent bug in
  it anyway.)  Proposed by wcbarksdale on the pyparsing wiki,
  thanks!

- Several unit tests were added to pyparsing's regression
  suite, courtesy of the Google Highly-Open Participation
  Contest.  Thanks to all who administered and took part in
  this event!



Pyparsing is a pure-Python class library for quickly developing
recursive-descent parsers.  Parser grammars are assembled directly in
the calling Python code, using classes such as Literal, Word,
OneOrMore, Optional, etc., combined with operators '+', '|', and '^'
for And, MatchFirst, and Or.  No separate code-generation or external
files are required.  Pyparsing can be used in many cases in place of
regular expressions, with shorter learning curve and greater
readability and maintainability.  Pyparsing comes with a number of
parsing examples, including:
- "Hello, World!" (English, Korean, Greek, and Spanish)
- chemical formulas
- configuration file parser
- web page URL extractor
- 5-function arithmetic expression parser
- subset of CORBA IDL
- chess portable game notation
- simple SQL parser
- search query parser
- EBNF parser/compiler
- Python value string parser (lists, dicts, tuples, with nesting)
  (safe alternative to eval)
- HTML tag stripper
- S-expression parser
- macro substitution preprocessor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

2008-02-10 Thread Carl Banks

On Feb 10, 5:50 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> Mark Dickinson <[EMAIL PROTECTED]> writes:
> > On Feb 10, 3:29 pm, Grant Edwards <[EMAIL PROTECTED]> wrote:
> > > platform does".  Except it doesn't in cases like this. All my
> > > platforms do exactly what I want for division by zero: they
> > > generate a properly signed INF.  Python chooses to override
> > > that (IMO correct) platform behavior with something surprising.
> > > Python doesn't generate exceptions for other floating point
> > > "events" -- why the inconsistency with divide by zero?
>
> > But not everyone wants 1./0. to produce an infinity;  some people
> > would prefer an exception.
>
> Special cases aren't special enough to break the rules.
>
> Most people would not want this behaviour either::
>
> >>> 0.1
> 0.10001
>
> But the justification for this violation of surprise is "Python just
> does whatever the underlying hardware does with floating-point
> numbers". If that's the rule, it shouldn't be broken in the special
> case of division by zero.

Do you recall what the very next Zen after "Special cases aren't
special enough to break the rules" is?


that's-why-they-call-it-Zen-ly yr's,

Carl Banks

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

Re: Turn off ZeroDivisionError?

On Feb 10, 7:08 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
> I understand your pain, but Python, like any good general-purpose
> language, is a compromise.  For the vast majority of programming,
> division by zero is a mistake and not merely a degenerate case, so
> Python decided to treat it like one.

Agreed.  For 'normal' users, who haven't encountered the ideas of
infinities and NaNs, floating-point numbers are essentially a
computational model for the real numbers, and operations that are
illegal in the reals (square root of -1, division by zero) should
produce Python exceptions rather than send those users hurrying to
comp.lang.python to complain about something called #IND appearing on
their screens.

But for numerically-aware users it would be nice if it were possible
to do non-stop IEEE arithmetic with infinities and NaNs.

Any suggestions about how to achieve the above-described state of
affairs are welcome!

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

Re: Turn off ZeroDivisionError?

Grant Edwards wrote:
> That would be great.

I'm looking forward to review your patch anytime soon. :)

Christian


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

Re: Turn off ZeroDivisionError?

On Feb 10, 7:07 pm, Grant Edwards <[EMAIL PROTECTED]> wrote:
> On 2008-02-10, Christian Heimes <[EMAIL PROTECTED]> wrote:
>  from somemodule import ieee754
>  with ieee754:
> > ...    r = a/0
> > ...    print r
> > inf
>
> That would be great.

Seriously, in some of my crazier moments I've considered trying to
write a PEP on this, so I'm very interested in figuring out exactly
what it is that people want.  The devil's in the details, but the
basic ideas would be:

(1) aim for consistent behaviour across platforms in preference to
exposing differences between platforms
(2) make default arithmetic raise Python exceptions in preference to
returning infs and nans.  Essentially, ValueError would be raised
anywhere that IEEE 754(r) specifies raising the divide-by-zero or
invalid signals, and OverflowError would be raised anywhere that IEEE
754(r) specifies raising the overflow signal.  The underflow and
inexact signals would be ignored.
(3) have a thread-local floating-point environment available from
Python to make it possible to turn nonstop mode on or off, with the
default being off.  Possibly make it possible to trap individual
flags.

Any thoughts on the general directions here?  It's far too late to
think about this for Python 2.6 or 3.0, but 3.1 might be a possibility.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

Mark Dickinson wrote:
> Any suggestions about how to achieve the above-described state of
> affairs are welcome!

I have worked out a suggestion in three parts.

Part 1
--

The PyFloat C API gets two more functions:

int PyFloat_SetIEEE754(int new_state) -> old state
int PyFloat_GetIEEE754(void) -> current state

By default the state is 0 which means no IEEE 754 return values for
1./0.,  0./0. and maybe some other places. An op like 1./0. raises an
exception.

With state 1 float ops like f/0. returns copysign(INF, f) and for f=0.
it returns a NaN.

ints and longs aren't affected by the state.

The state is to be stored and fetched from Python's thread state object.
This could slow down floats a bit because every time f/0. occurs the
state has to be looked up in the thread state object.

Part 2
--

The two function are exposed to Python code as math.set_ieee754 and
math.get_ieee754. As an alternative the functions could be added to a
new module ieee754 or to the float type.

Part 3
--

contextlib gets a new context for ieee754

class ieee754(object):
def __init__(self, state=1):
self.new_state = state

def __enter__(self):
self.old_state = math.set_ieee754(self.new_state)

def __exit__(self, *args):
math.set_ieee754(self.old_state)

usage:

with contextlib.ieee754():
...

Christian

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

Re: Turn off ZeroDivisionError?

2008-02-10 Thread Ben Finney

Christian Heimes <[EMAIL PROTECTED]> writes:

> The two function are exposed to Python code as math.set_ieee754 and
> math.get_ieee754.

Or, better, as a property, 'math.ieee754'.

-- 
 \ "My, your, his, hers, ours, theirs, its. I'm, you're, he's, |
  `\  she's, we're, they're, it's."  -- Anonymous, |
_o__)alt.sysadmin.recovery |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Turn off ZeroDivisionError?

Ben Finney wrote:
> Or, better, as a property, 'math.ieee754'.

No, it won't work. It's not possible to have a module property.

Christian



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

Re: Edit Python code programmatically

Guilherme Polo wrote:

> Generating code like this is always dangerous.

Generating code isn't dangerous in itself. What's dangerous
is mixing hand-edited and generated code in the same file.
There's too much opportunity for hand edits to get wiped
out by subsequent automatic edits or vice versa.

If you really want to generate code, find a way of
separating out the generated code into another .py
file that never needs to be edited by hand.

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

packing greyscale values

2008-02-10 Thread jimgardener

hi
i am getting value of a pixel of a greyscale image using PIL's
image.getdata and need to pack it as an int as below

ie greyvalues
127 , 56 , 135 , 99 , 102 , 101 , 146 , 112 , 155 , 154 , 112 , 169

should become
-4473925, -8289919, -4144960, -5789785, -5592406, -5658199 ,-3684409,
-5131855, -3289651,-3355444, -5131855, -2763307

(i got these values using java's BufferedImage class..)I would like to
know if there is a way to do the conversion in python.(.i need 'these
'for some calculations)

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

Re: OT: Star Wars and parsecs

Bjoern Schliessmann wrote:

> No, even simpler: In the Star Wars galaxy, parsec is a time unit.

Yep, it's the Paradoxical Second, defined as the average length of
time it takes a person to figure out that the pilot they've
hired is feeding them a load of bull for the purpose of finding
out how long it takes them to notice they're being fed a load
of bull.

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

Re: Turn off ZeroDivisionError?

Christian Heimes wrote:
> Mark Dickinson wrote:
>> Any suggestions about how to achieve the above-described state of
>> affairs are welcome!
> 
> I have worked out a suggestion in three parts.

[snip]

I've implemented my proposal and submitted it to the experimental math
branch: http://svn.python.org/view?rev=60724&view=rev

Christian

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

How can I kill CGIHTTPServer ?

2008-02-10 Thread eching

I'm running CGIHTTPServer with the serve_forever method and I cannot
get the darn thing to stop unless I kill the command prompt its
running in.  I searched for similar posts here and found this:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/6879d74ad7679349/ff7d0aa2be964767?lnk=gst&q=HTTPServer+kill#ff7d0aa2be964767

But there doesn't seem to be a definitive answer.  I tried one of the
last proposed solutions:

class Server(SocketServer.ThreadingMixIn, SocketServer.TCPServer):
pause = 0.25
allow_reuse_address = True

def __init__(self, server_address, RequestHandlerClass):
SocketServer.TCPServer.__init__(self, server_address,
RequestHandlerClass)
self.socket.settimeout(self.pause)
self.serving = 1
...

def serve_forever(self):
while self.serving:
self.handle_request()

And that worked, but the last post in the thread suggested '...this
would cause timeouts in the middle of handling request whenever a
client is slow'

Can anyone comment on this solution or have other possible solutions?
Eventually I probably will want this to run as a windows service to
serve up some internal apps, so it would be great if I could the
server to shutdown gracefully.

Thanks in advance,
Eric
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Displaying Unicode Chars

2008-02-10 Thread Martin v. Löwis

 > Thanks to both of you.  Those approaches make sense.  Here's the final
 > result if you're curious: 
http://utilitymill.com/utility/Display_Unicode_Char_From_Hex

Not sure what operating system you are using. On Windows, I recommend
that you look at the charmap.exe utility. On Linux, try gucharmap
or kcharselect.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Professional Grant Proposal Writing Workshop (May 2008: Denver, Colorado)

2008-02-10 Thread Anthony Jones

The Grant Institute's Grants 101: Professional Grant Proposal Writing Workshop
will be held in Denver, Colorado, May 14 - 16, 2008. Interested development professionals, researchers, faculty, and graduate students should register as soon as possible, as demand means that seats will fill up quickly. Please forward, post, and distribute this e-mail to your colleagues and listservs.
All participants will receive certification in professional grant writing from the Institute. For more information call (888) 824 - 4424 or visit The Grant Institute at www.thegrantinstitute.com.
Please find the program description below:
The Grant Institute
Grants 101: Professional Grant Proposal Writing Workshop
will be held in
Denver, Colorado
May 14 - 16, 2008
8:00 AM - 5:00 PM

The Grant Institute's Grants 101 course is an intensive and detailed introduction to the process, structure, and skill of professional proposal writing. This course is characterized by its ability to act as a thorough overview, introduction, and refresher at the same time. In this course, participants will learn the entire proposal writing process and complete the course with a solid understanding of not only the ideal proposal structure, but a holistic understanding of the essential factors,
which determine whether or not a program gets funded. Through the completion of interactive exercises and activities, participants will complement expert lectures by putting proven techniques into practice. This course is designed for both the beginner looking for a thorough introduction and the intermediate looking for a refresher course that will strengthen their grant acquisition skills. This class, simply put, is designed to get results by creating professional grant proposal writers.

Participants will become competent program planning and proposal writing professionals after successful completion of the Grants 101 course. In three active and informative days, students will be exposed to the art of successful grant writing practices, and led on a journey that ends with a masterful grant proposal.
Grants 101 consists of three (3) courses that will be completed during the three-day workshop.
(1) Fundamentals of Program Planning
This course is centered on the belief that "it's all about the program." This intensive course will teach professional program development essentials and program evaluation. While most grant writing "workshops" treat program development and evaluation as separate from the writing of a proposal, this class will teach students the relationship between overall program planning and grant writing.
(2) Professional Grant Writing

Designed for both the novice and experienced grant writer, this course will make each student an overall proposal writing specialist. In addition to teaching the basic components of a grant proposal, successful approaches, and the do's and don'ts of grant writing, this course is infused with expert principles that will lead to a mastery of the process. Strategy resides at the forefront of this course's intent to illustrate grant writing as an integrated, multidimensional, and dynamic endeavor.
Each student will learn to stop writing the grant and to start writing the story. Ultimately, this class will illustrate how each component of the grant proposal represents an opportunity to use proven techniques for generating support.
(3) Grant Research

At its foundation, this course will address the basics of foundation, corporation, and government grant research. However, this course will teach a strategic funding research approach that encourages students to see research not as something they do before they write a proposal, but as an integrated part of the grant seeking process. Students will be exposed to online and database research tools, as well as publications and directories that contain information about foundation, corporation, and
government grant opportunities. Focusing on funding sources and basic social science research, this course teaches students how to use research as part of a strategic grant acquisition effort.
Registration
$597.00 tuition includes all materials and certificates.
Each student will receive:
*The Grant Institute Certificate in Professional Grant Writing
*The Grant Institute's Guide to Successful Grant Writing
*The Grant Institute Grant Writer's Workbook with sample proposals, forms, and outlines
Registration Methods
1) On-Line - Complete the online registration form at www.thegrantinstitute.com under Register Now. We'll send your confirmation by e-mail.
2) By Phone - Call (888) 824-4424 to register by phone. Our friendly Program Coordinators will be happy to assist you and answer your questions.
3) By E-mail - Send an e-mail with your name, organization, and basic contact information to [EMAIL PROTECTED] and we will reserve your slot and send your Confirmation Packet.
You have received this invitation due to specific educational affiliat

wxpython thread question

2008-02-10 Thread marcinguy

I am new to threading and python. Currently I am working on a GUI app
that will be a frontend to CLI client.

I want to invoke a method of the class from GUI and run it in the
thread. That works well, the problems is I dont know how can I stop
this operation, thread if the user would like to stop/cancel it.

Here is the code:

.
.
.

class ScanThread:
def __init__(self, txtbox, para):
self.para = para
self.txtbox = txtbox
#print "Init"

def Start(self):
self.keepGoing = self.running = True
thread.start_new_thread(self.Run, ())
#print "Start"

def Stop(self):
self.keepGoing = False
#print "Stop"

def IsRunning(self):
return self.running
#print "IsRunning"

def Run(self):
if self.keepGoing:
obj=tool.sanner(self.para,self.txtbox);

obj.scan()
obj.attack()
#time.sleep(1)

self.running = False
#print "Run set to false"


.
.
.

 def do_Scan(self, event): # wxGlade: MyFrame.
#print "Event handler `do_Scan' not implemented"
self.threads = []
val = self.text_ctrl_1.GetValue()
box = self.text_ctrl_2;
self.threads.append(ScanThread(box,val))
for t in self.threads:
t.Start()
self.Scan.Enable(False)
self.Stop.Enable(True)
self.frame_1_statusbar.SetStatusText("Scanning")
#event.Skip()


 def do_Stop(self, event): # wxGlade: MyFrame.
#print "Event handler `do_Stop' not implemented"

busy = wx.BusyInfo("One moment please, waiting for threads to
die...")
wx.Yield()

for t in self.threads:
t.Stop()

running = 1

while running:
running = 0

for t in self.threads:
running = running + t.IsRunning()

time.sleep(0.1)
#self.Destroy()
#event.Skip()

do_Stop doesn't stop the Thread. Works well if I put the simple code
in the thread (i.e printing text etc), but with CLI class code I am
using, it simply doesn't respond.

Any help and explanation or code sample GREATLY appreciated.

Do I have to rewrite class I am using (CLI client) to work with
threads to make this happen 

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

Re: Displaying Unicode Chars

2008-02-10 Thread [EMAIL PROTECTED]

On Feb 10, 4:30 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I want to make a little Python utility where a user can enter the
> > unicode numerical code and get the actual symbol back in utf-8.
>
> > For example, a user could enter something like u221E
>
> I'm puzzled why the user would enter "u221E" - why not just "221E"?
>
> > And get back ∞
>
> > Now, this does seem to work:
>
>  print u"\u221E"
> > ∞
> > However how can I change it so it works with a string variable?
>
> The problem is not with variables - print can output variables
> just fine:
>
> text = u"\u221E"
> print text
>
> (where text is a variable holding a Unicode string)
>
> Your problem is with data conversion: how to convert a string
> holding a hexadecimal integer number into a Unicode
> character whose ordinal is that number?
Thanks to both of you.  Those approaches make sense.  Here's the final
result if you're curious: 
http://utilitymill.com/utility/Display_Unicode_Char_From_Hex

-Greg


> To do so, you need two steps (assuming you start from "221E")
> 0. char = "221E"
> 1. convert that into an integer: char = int(char, 16)
> 2. convert that into a Unicode character: char = unichr(char)
> 3. print it: print char
>
> If you insist on the user entering "u221E" instead, you have
> to convert that first into a string without the leading u:
>
> 0.5 char = char[1:]
>
> HTH,
> Martin

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

Re: Chinese character error

2008-02-10 Thread Martin v. Löwis

> Have you any idea why this is not working on my computer ?

Can you please try the listdir operation with the Python distribution
from python.org instead of Cygwin Python?

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Help to translate simple VBA code to Python

2008-02-10 Thread Alexandr N Zamaraev

I use Bentley MicroStation through Automation interface.
But I do not known how translate some VBA code to Python.
For example ("Copy Element Example" from documentation):


'The following code starts the command
Sub RunCopyElement()
 CommandState.StartLocate New clsCopyElementCommand
End Sub

'This following code must be in a class that implements 
ILocateCommandEvents. In this example, it is in the class 
clsCopyElementCommand.

Implements ILocateCommandEvents

' This is called when the user enters a data point after the
'  LocateFilter has accepted an element
Private Sub ILocateCommandEvents_Accept(ByVal Element As Element, Point 
As Point3d, ByVal View As View)
'skip function body
End Sub

Private Sub ILocateCommandEvents_Cleanup()
End Sub

Private Sub ILocateCommandEvents_Dynamics(Point As Point3d, ByVal View 
As View, ByVal DrawMode As MsdDrawingMode)
'skip function body
End Sub

Private Sub ILocateCommandEvents_LocateFailed()
'skip function body
End Sub


Private Sub ILocateCommandEvents_LocateFilter(ByVal Element As Element, 
   Point As Point3d, Accepted As Boolean)
'skip function body
End Sub

Private Sub ILocateCommandEvents_LocateReset()
'skip function body
End Sub

Private Sub ILocateCommandEvents_Start()
'skip function body
End Sub

Also sample using interface ILocateCommandEvents: 
http://www.la-solutions.co.uk/content/MVBA/MVBA-MeasureArea.htm

All interface derived from IDiapach.

How to realize in Python without external DLL?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OT: Speed of light [was Re: Why not a Python compiler?]

Gabriel Genellina wrote:

> Before the famous Michelson-Morley experiment (end of s. XIX), some  
> physicists would have said "light propagates over ether, some kind of  
> matter that fills the whole space but has no measurable mass", but the  
> experiment failed to show any evidence of it existence.

Not just that, but it showed there was something seriously weird
about space and time -- how can light travel at the same speed
relative to *everyone*? Einstein eventually figured it out.

In hindsight, Maxwell's equations had been shouting "Relativity!"
at them all along, but nobody had seen it.

> previous experiments showed 
> that  light was not made of particles either.

Except that the photoelectric effect showed that it *is* made
of particles. Isn't the universe fun?

> Until DeBroglie formulated 
> its  hypothesis of dual nature of matter (and light): wave and particle 
> at the  same time.

Really it's neither waves nor particles, but something else for
which there isn't a good word in everyday English. Physicists
seem to have got around that by redefining the word "particle"
to mean that new thing.

So to get back to the original topic, it doesn't really matter
whether you talk about light travelling or propagating. Take
your pick.

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

Re: Turn off ZeroDivisionError?

Christian Heimes wrote:

> The state is to be stored and fetched from Python's thread state object.
> This could slow down floats a bit because every time f/0. occurs the
> state has to be looked up in the thread state object.

An alternative implementation might be to leave zero division
traps turned on, and when one occurs, consult the state to
determine whether to raise an exception or re-try that
operation with trapping turned off.

That would only incur the overhead of changing the hardware
setting when a zero division occurs, which presumably is a
relatively rare occurrence.

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

Re: Error on Python

2008-02-10 Thread Zara

On Sat, 9 Feb 2008 10:26:26 -0800 (PST), maehhheeyy
<[EMAIL PROTECTED]> wrote:

>Hi, right now I'm using Python and Multicast. I have the code for
>Multicast receiver on Python but I keep getting this error;
>
>File "", line 1, in bind
>error: (10049, "Can't assign requested address")
>
>The error is coming from this line;
>sock.bind ((MCAST_ADDR, MCAST_PORT))
>
>Can anyone please help me solve this problem?

This error typically arises when the address is neither the IP address
of a network connection or 0.0.0.0.
 If you are trying to connect an IGMP socket under Windows, it may not
be treated as a normal socket. You must use the corresponding
setsockopt() options, and I am not sure if they are available throguh
Python!

Search MSDN for IGMP, or lok directly at:
http://msdn2.microsoft.com/en-us/library/ms739172(VS.85).aspx

If you are trying on *NIX SO, I don't know if this is applicable

best regrads,

Zara

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

Re: Turn off ZeroDivisionError?