Re: Possible memory leak?

[Steven D'Aprano]

Tuvas wrote:

> However, I would like to make a few more statements. The max image size
> is 1024x1024. The length of time it takes to do the row statement
> increased fairly substationally every time it was ran, in the order of
> ~.5%. That seems small, but when you run it 1M times, the last
> operation will take 5000 times longer than the original, or about
> ~1sec. And that's just for one row, the entire process would take an
> eternity...

I've just gone back and taken another look at your 
original post. You haven't posted the actual code you 
are using, have you? The code you posted doesn't 
actually return a result, nor does it set a global 
variable. As far as I can tell, it just churns for a 
while, processing hard, and then throws the result away.

So I'm guessing that it isn't actually your production 
code. Did you really think we would be able to debug 
some code that you haven't shown us? I mean, some of 
the folks on comp.lang.python are really good, but even 
they aren't that good *wink*


-- 
Steven.

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

Re: Loop exception catching

[Fredrik Lundh]

Aldo Cortesi wrote:

> > What do you mean?
>
> Well, the problem with "input" is that it allows the user to supply an
> arbitrary Python expression, which will then be executed. Among other things,
> this means that your pet cat could make your script exit due to an uncaught
> exception by simply walking accross your keyboard. If your cat is sufficiently
> clever, it could also empty your bank account, email your entire porn
> collection to your mother, and then erase your hard drive.

but that the cat would be clever enough to make your script exit and then do
evil stuff from the shell is completely out of the question.





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

Re: Possible memory leak?

[Steven D'Aprano]

Tuvas wrote:

> Oh, I should also mention, I used a memory monitor and saw the amount
> of memory being used go up with time, even when the function ended,
> meaning I did the 10 128x128 pictures, never was any memory dealocated
> until I exited the program.

Are you really trying to say that the amount of memory 
being used is going up even when the function is not 
being used?

If so, then at least part of your problem exists in 
another part of your program.

If you are monitoring the amount of memory being 
allocated to Python, then no, Python won't generally 
return memory to the operating system while it is still 
running. But the memory allocated to your data 
structures will be reclaimed by Python when they are 
not in use.


-- 
Steven.

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

Re: Real-world use cases for map's None fill-in feature?

[Steven D'Aprano]

[EMAIL PROTECTED] wrote:

>>4. A terminating bug is preferred to a non-terminating bug.
> 
> 
> This is not self-evident to me.  Is this somehow
> related to the design philosophy of functional
> languages?  I was never aware of such a preference
> in conventional procedural languages (though I
> could easily be wrong).
> 
> It also seems directly counter to Python's "no errors
> should pass silently" dogma -- a non termination
> seems more noticable than silent erroneous results.

You are assuming that the function in question returns 
a result *quickly*, and that any delay  obvious to the 
user is clearly a problem ("damn program has hung...").

Consider a generic function which may take "a long 
time" to return a result. How long do you wait before 
you conclude it has hung? A minute? An hour? A day? A 
month? A year? If you have some knowledge of the 
expected running time you can make a good estimate 
("well, there are only a thousand records in the 
database, so even if it takes an entire minute to check 
each record, if it hasn't returned after 17 hours, it 
is probably hung"). But for arbitrary problems, you 
might not know enough about the function and data to 
make that estimate. Some calculations do have to run 
for days or weeks or months to get a correct result, 
and some are impossible to predict in advance.

So, in general, it is impossible to tell the difference 
between a non-terminating bug and a correct calculation 
that would have finished if you had just waited a 
little longer. (How much is a little longer?) Hence, in 
general, a terminating wrong answer is easier to test 
for than a non-terminating bug.


-- 
Steven.

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

Re: Using non-ascii symbols

[Robert Kern]

James Stroud wrote:
> Robert Kern wrote:
> 
>>James Stroud wrote:
>>
>>>I can't find "≤, ≥, or ≠" on my keyboard.
>>
>>Get a better keyboard? or OS?
> 
> Please talk to my boss. Tell him I want a Quad G5 with about 2 Giga ram. 
> I'll by the keyboard myself, no problemo.

Alternatively, you can simply learn to use the tools in front of you.

http://www.cl.cam.ac.uk/~mgk25/unicode.html#input

-- 
Robert Kern
[EMAIL PROTECTED]

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

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

Re: Is there a way to profile underlying C++ code?

[Travis E. Oliphant]

Bo Peng wrote:
> Dear list,
> 
> I have a C++-SWIG-wrapped python module. The running time for one of the 
> functions is pretty unpredictable so I would like to profile it. 
> However, the python profiler does not seem to enter the compiled module 
> (.so file). Is there a way to profile the C++ functions?
> 

On Linux you can use oprofile (which is pretty nice and easy to use --- 
no recompiling.  Just start the profiler, run your code, and stop the 
profiler).

http://oprofile.sourceforge.net/about/

-Travis

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

Is there a way to profile underlying C++ code?

[Bo Peng]

Dear list,

I have a C++-SWIG-wrapped python module. The running time for one of the 
functions is pretty unpredictable so I would like to profile it. 
However, the python profiler does not seem to enter the compiled module 
(.so file). Is there a way to profile the C++ functions?

Many thanks in advance.
Bo
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Loop exception catching

[Paul Rubin]

[EMAIL PROTECTED] (Alex Martelli) writes:
> He'd sure empty your bank account and hard drive, but even he wouldn't
> send your porn to your mom, that's just... *mean*!-)

He'd send kitty porn, except no one would figure it out ;-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Loop exception catching

[Alex Martelli]

Paul Rubin  wrote:

> [EMAIL PROTECTED] (Alex Martelli) writes:
> > I thought I knew some pretty evil cats, but I see my experience with
> > felines was nothing compared to yours!
> 
> Catbert?

He'd sure empty your bank account and hard drive, but even he wouldn't
send your porn to your mom, that's just... *mean*!-)


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

Re: Using non-ascii symbols

[James Stroud]

Robert Kern wrote:
> James Stroud wrote:
> 
> 
>>I can't find "≤, ≥, or ≠" on my keyboard.
> 
> 
> Get a better keyboard? or OS?

Please talk to my boss. Tell him I want a Quad G5 with about 2 Giga ram. 
I'll by the keyboard myself, no problemo.

> On OS X,
> 
> ≤ is Alt-,
> ≥ is Alt-.
> ≠ is Alt-=
>
> Fewer keystrokes than <= or >= or !=.
> 

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

Re: Dynamic pull down menus (CGI)

[[EMAIL PROTECTED]]

You will be quite limited without the use of JavaScript to perform this
kind of dynamic functionality. HTML alone cannot do this. You can use
dynamically generated Javascript, AJAX, Flash or Java.

One possible would be to just use HTML forms and add in an extra button
click after the user makes their selection from the first select
element.

You could create the options for a select element using a CGI script
and contain the select element in a form. Position a submit button
beside the select element to submit the user's choice back to the
server.

A handling CGI script could then look at the value and recreate the
first select box and the second select box with the appropriate values.

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

Re: Loop exception catching

[Paul Rubin]

[EMAIL PROTECTED] (Alex Martelli) writes:
> I thought I knew some pretty evil cats, but I see my experience with
> felines was nothing compared to yours!

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

Re: Loop exception catching

[Alex Martelli]

Aldo Cortesi <[EMAIL PROTECTED]> wrote:
   ...
> this means that your pet cat could make your script exit due to an uncaught
> exception by simply walking accross your keyboard. If your cat is sufficiently
> clever, it could also empty your bank account, email your entire porn
> collection to your mother, and then erase your hard drive.

I thought I knew some pretty evil cats, but I see my experience with
felines was nothing compared to yours!


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

Re: Loop exception catching

[Aldo Cortesi]

Thus spake Ivan Shevanski ([EMAIL PROTECTED]):

> Thanks, that seems to work fine.  But about your other comment. . .
>
> >Well, leaving aside the merits of using "input" (which should be avoided at
> >all costs)
>
> What do you mean?

Well, the problem with "input" is that it allows the user to supply an
arbitrary Python expression, which will then be executed. Among other things,
this means that your pet cat could make your script exit due to an uncaught
exception by simply walking accross your keyboard. If your cat is sufficiently
clever, it could also empty your bank account, email your entire porn
collection to your mother, and then erase your hard drive.

In short, using "input" means that your programme could potentially behave in
some arbitrary way that is simply impossible to predict, depending on what is
supplied by the user. Just use "raw_input" instead - it just takes input from a
user without evaluating it as a Python expression, and will bring order and
predictability to whatever it is you want to do.




Cheers,



Aldo


--
Aldo Cortesi
[EMAIL PROTECTED]
http://www.nullcube.com
Mob: 0419 492 863
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is there a maximum length of a regular expression in python?

[fuzzylollipop]

this should really be posted to http://www.thedailywtf.com/, I wonder
if they have a german version of TheDailyWTF.com?

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

Re: logging into secure website with script

[James Stroud]

dpoehls wrote:
> Hello there,
> 
> I am new to python, and shell scriping in general..I have done quite a
> bit of php, but that it about it. Anyhow, I am wondering if it would be
> possible to write a python script that would login to a password
> enabled site (qmailadmin) and then be able to add a new account.  I
> imagine it could be done by accessing the website and then it would
> send POSTs to the website?  If this makes no sense, I apologize, just
> wondering if anyone could point me in the right direction. Thanks ahead
> of time!
> 

Spend some time perusing this code:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302930

It helped me with a similar problem. I'm not sure if it works for https.

If the form is using POST to "hide" the login, just suck the web page 
and change POST to GET. Then use your sucked webpage and submit your 
login from it. You will then see the fields (separated by "+"s and the 
values, separated from the fields by "="s). Use the fields and values to 
populate the "txdata" dictionary in the example using urllib.urlencode 
(an example is in the discussion).

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

logging into secure website with script

[dpoehls]

Hello there,

I am new to python, and shell scriping in general..I have done quite a
bit of php, but that it about it. Anyhow, I am wondering if it would be
possible to write a python script that would login to a password
enabled site (qmailadmin) and then be able to add a new account.  I
imagine it could be done by accessing the website and then it would
send POSTs to the website?  If this makes no sense, I apologize, just
wondering if anyone could point me in the right direction. Thanks ahead
of time!

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

Dynamic pull down menus (CGI)

[Keith Burns]

Hi,

I have seen two entries in the archives for this topic:

1. Uses hypertext, not a pulldown menu to feed parameters back to the python 
CGI
2. The other actually used Java.

Is there a way using Python for CGI such that when a user selects an item 
from one pull down menu (ie FRUIT or VEGETABLE or MEAT) that another pull 
down menu is filled with appropriate selections (If FRUIT in the first, then 
APPLES, ORANGES etc... you get the idea)... without resorting to JavaScript?

Any references to RTxM are greatly appreciated...

Cheers
Keith


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

Re: Possible memory leak?

[Tuvas]

Oh, I should also mention, I used a memory monitor and saw the amount
of memory being used go up with time, even when the function ended,
meaning I did the 10 128x128 pictures, never was any memory dealocated
until I exited the program.

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

Re: Possible memory leak?

[Tuvas]

Hmm. The problem is that the required form for the image is as a string
of characters to convert with the tkimage interface, at least, as I
understood it. Perhaps an array would work, I'll try that when I get
ahold of the computer in question (One thing required is a linux only
library, and I don't have access to a linux machine at the moment...)

However, I would like to make a few more statements. The max image size
is 1024x1024. The length of time it takes to do the row statement
increased fairly substationally every time it was ran, in the order of
~.5%. That seems small, but when you run it 1M times, the last
operation will take 5000 times longer than the original, or about
~1sec. And that's just for one row, the entire process would take an
eternity...

And the real kicker, when doing this with smaller images, ei, about
128x128, the second image starts of at the same point of slowness as
the first one. EI, the last operation of the first image took .01
seconds to complete (It started, let's say, around .005), for instance,
the next one would start at that length of time, and end at .02 or so,
the third picture would be taking that long for each row, and so on. It
only does this on one particular computer (I've only had the chance to
run it on 2 machines to date, BTW.)

There is a reason why the rows are pieced together as is, I must say,
but it's a tad bit complicated... I'll just defend it without giving a
real reason.

Thanks for the help!

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

Codec Search Function

[James Stroud]

Hello All,

I'm using pyinstaller 1.0 (stable) on win32xp and it is not able to find 
the codec for several encodings (hex, base64, etc.). I resorted to 
writing my own for hex, just to see if I could get my program deployed. 
But I think a more permanent solution would be to get pyinstaller 
working right.

I tried the latest release (unstable version), claiming that it solved 
the problem, but it had problems finding a search function:

LookupError: no codec search functions registered: can't find encoding

I looked at the documentation for codecs.register, and it was really not 
clear exactly how I was to create the search function that needs 
registering. Any help would be appreciated.

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

Re: Real-world use cases for map's None fill-in feature?

[Andrae Muys]

[EMAIL PROTECTED] wrote:
> > 4. A terminating bug is preferred to a non-terminating bug.
>
> This is not self-evident to me.  Is this somehow
> related to the design philosophy of functional
> languages?  I was never aware of such a preference
> in conventional procedural languages (though I
> could easily be wrong).

This is not a paradigm based preference.  It derives from the basic
fact that you can test for an incorrect result, but you can't test for
non-termination.  Therefore if you have to choose between making it
easy to inadvertantly introduce either non-termination or a trivial
logic error, you are better off chosing the trivial logic error.  That
preference is independent of which
structured/object/functional/logic/constraint/concurrent/reactive
school of programming you adhere to.

> It also seems directly counter to Python's "no errors
> should pass silently" dogma -- a non termination
> seems more noticable than silent erroneous results.

Two problems with that.  One we are dealing with a bug, not an error.
Two, even if we classified the bug as an error noticing non-termination
requires solving the halting-problem whereas noticing an erroneous
result simply requires a unit-test.

The reason why you see this in FP and not in OOP is that
infinite/unbounded/v.large values are trivial to define in FP and
(generally) not in OOP.  Consequently the potential for inadvertant
non-termination simply doesn't arise in OOP.

> > Hence zip is generally truncating.
>
> I see your point in a theoretical sense, but it still
> seems to me be a pretty weak reason for making
> a practical decision about what should be in Python,
> particularly when the justification is being transfered
> from a functional programming domain to an
> object/procedural one.  Is any language feature that
> might result in non-termination if erroneously used,
> to be banned?  That doesn't seem very reasonble.

Of course not --- only by making python non-turing complete could such
a thing be achieved. But you have overstated the position. This isn't a
matter of outlawing function that could be used to write a
non-terminating prodcedure.  It's about a simple API design decision.
A choice between two options.  It doesn't require the designer to
decide that one is *right* and one *wrong*.  Just that one is at least
slightly better than the other; or even that one was chosen simply
because either was better than neither.  API design decisions are not
personal vendettas against your use-case :).

Andrae Muys

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

Re: "wxPython in Action" book

[Dave Cook]

On 2006-01-24, Iain King <[EMAIL PROTECTED]> wrote:
> New book on wxPython: http://www.manning.com/books/rappin
>
> Release date of this month.  Does anyone know if it's out yet / has
> anyone read it and has an opinion?

Someone (the author?) on the wxpython-users mailing list said it was delayed
by 6 weeks.

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

Re: Possible memory leak?

[Travis E. Oliphant]

Tuvas wrote:
> I have a function in a program that works something like this.
> 
> def load_pic_data(width,heigth,inpdat, filt=TRUE):
> data=''
> total=0
> tnum=0
> size=100
> for y in range(0,heigth):
> row=''
> for x in range(0,width):
> index=2*(x+y*width)
> num=ord(inpdat[index+1])*256+ord(inpdat[index])
> if(vfilter.get() and d_filter and filt):
> num=round((num-(d_filter[index/2])))
> if(num<0):
> num=0
> if(num>255*64):
> num=255*64
> row=row+chr(num/64)
> data=data+row
> 
> 
> The purpose of this part of a program is to take a 14 bit numerical
> representation and convert it to an 8 bit representation. 

This is exactly the kind of thing NumPy (http://numeric.scipy.org) is 
ideal for.  If that's of interest to you, then I can offer particular 
suggestions...

-Travis

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

Re: Possible memory leak?

[Stephen Kellett]

In message <[EMAIL PROTECTED]>,
Steven D'Aprano <[EMAIL PROTECTED]> writes
>But the real killer is this one line:
>
>row=row+chr(num/64)
>
>Bad, bad BAD idea. Every time you add two strings together, Python has to
>copy BOTH strings. As row gets huge, this takes longer and longer to do.
>
>A rule of thumb I use is, never add more than two strings together. Maybe
>three. Certainly not more than four. Or five.
>
>But absolutely not millions of strings, which is what you are doing.

You would be able to visualize this process very well using Python
Memory Validator and Python Performance Validator.

http://www.softwareverify.com

Stephen
-- 
Stephen Kellett
Object Media Limitedhttp://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Weird generator id() behaviour (was Re: Python code written in1998, howto improve/change it?)

[Carl Cerecke]

Adding a continue statemtent after the yield statements yields :-) a 
speed increase. Still not as good as functions though. (about 30% slower)

Cheers,
Carl

Carl Cerecke wrote:
> Carl Cerecke wrote:
> Generator FSM done properly (well, better anyway). They are still almost 
> twice as slow as plain function calls, though.
> 
> def g_on():
> 
> while 1:
> action = next_action()
> if action == 'lift':
> yield s_g_on
> elif action == 'push':
> yield s_g_off
> else:
> break
> yield None
> 
> def g_off():
> 
> while 1:
> action = next_action()
> if action == 'lift':
> yield s_g_on
> elif action == 'push':
> yield s_g_off
> else:
> break
> yield None
> 
> def actions(n):
> import random
> for i in range(n-1):
> yield random.choice(['lift','push'])
> yield None
> 
> r = 100
> #r = 10
> next_action = actions(r).next
> s_g_on = g_on()
> s_g_off = g_off()
> state = s_g_on
> 
> while state:
> state = state.next()
> z = time.clock()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Weird generator id() behaviour (was Re: Python code written in1998, how to improve/change it?)

[Carl Cerecke]

Carl Cerecke wrote:
> Fredrik Lundh wrote:
> 
>> Carl Cerecke wrote:
>>
>>
>>> It turns out that generators are more efficient than the eval function
>>> excuting bits of compiled code. About 20-25% faster.
>>
>>
>>
>> why are you using generators to return things from a function, when
>> you can just return the things ?
> 
> 
> Trying to find the fastest way to implement finite state machine.
> The included file times 4 different ways, with functions the fastest.
> 
> The reason, I think, for the unusual sequence if id()s of the generators 
> - see grandparent post - (and the reason for their poor performance 
> compared to functions), is because the reference to the generator is 
> being lost, then another generator is being created with the same id.
> Properly done, I would expect generators to out perform functions.

Generator FSM done properly (well, better anyway). They are still almost 
twice as slow as plain function calls, though.

def g_on():

 while 1:
 action = next_action()
 if action == 'lift':
 yield s_g_on
 elif action == 'push':
 yield s_g_off
 else:
 break
 yield None

def g_off():

 while 1:
 action = next_action()
 if action == 'lift':
 yield s_g_on
 elif action == 'push':
 yield s_g_off
 else:
 break
 yield None

def actions(n):
 import random
 for i in range(n-1):
 yield random.choice(['lift','push'])
 yield None

r = 100
#r = 10
next_action = actions(r).next
s_g_on = g_on()
s_g_off = g_off()
state = s_g_on

while state:
 state = state.next()
z = time.clock()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pulling numbers from ASCII filename not working

[Fredrik Lundh]

"IamIan" <[EMAIL PROTECTED]> wrote:

> The exception I get is "TypeError: Cannot add value 'int' to string."

now that you've posted the exception, can you please post the code
you're using, and the *complete* traceback.

(the stuff you posted earlier contained syntax errors, and didn't con-
tain any additions.  I suggest using copy/paste, rather than typing
things from memory).





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

Re: Is there a maximum length of a regular expression in python?

[Frithiof Andreas Jensen]

"Bryan Olson" <[EMAIL PROTECTED]> skrev i en meddelelse 
news:[EMAIL PROTECTED]
> Roy Smith wrote:

> Does no one care about an internal error in the regular expression
> engine?

Yes, but - given the example - In about the same way that I care about an 
internal error in my car engine after dropping a spanner into it ;-) 


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

Re: obtain client ip address from SimpleXMLRPCServer ?

[Peter Gsellmann]

[EMAIL PROTECTED] wrote:

> Is it possible to obtain the client's ip address from a
> SimpleXMLRPCServer instance or subclass instance?  When running
> SimpleXMLRPCServer with logRequests = 1, the xmlrpc server prints out
> the fqdn on the console, however, I'm not sure if this information
> (either fqdn or ip address) is available to the SimpleXMLRPCServer
> instance.  Can somebody shed some light on how to obtain this
> information?
> 
The request-handler has the method: address_string()

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

Re: Weird generator id() behaviour (was Re: Python code written in1998, how to improve/change it?)

[Carl Cerecke]

Fredrik Lundh wrote:
> Carl Cerecke wrote:
> 
> 
>>It turns out that generators are more efficient than the eval function
>>excuting bits of compiled code. About 20-25% faster.
> 
> 
> why are you using generators to return things from a function, when
> you can just return the things ?

Trying to find the fastest way to implement finite state machine.
The included file times 4 different ways, with functions the fastest.

The reason, I think, for the unusual sequence if id()s of the generators 
- see grandparent post - (and the reason for their poor performance 
compared to functions), is because the reference to the generator is 
being lost, then another generator is being created with the same id.
Properly done, I would expect generators to out perform functions.

These are the numbers I get on a P3 600:
$ ./foo.py
action generator overhead: 13.25
---
exec: 8.7
---
eval: 10.09
---
generators: 6.68
---
functions: 3.37


#!/usr/bin/env python

import time

s_on = compile('''
#print 'on'
action = next_action()
if action == 'lift':
 state = s_on
elif action == 'push':
 state = s_off
else:
 state = None
''','','exec')

s_off = compile('''
#print 'off'
action = next_action()
if action == 'lift':
 state = s_on
elif action == 'push':
 state = s_off
else:
 state = None
''','','exec')

def f_on():
 action = next_action()
 if action == 'lift':
 return f_on
 elif action == 'push':
 return f_off
 else:
 return None

def f_off():
 action = next_action()
 if action == 'lift':
 return f_on
 elif action == 'push':
 return f_off
 else:
 return None


def g_on():

 #print "on"
 action = next_action()
 if action == 'lift':
 yield g_on()
 elif action == 'push':
 yield g_off()
 else:
 yield None

def g_off():

 #print "off"
 action = next_action()
 if action == 'lift':
 yield g_on()
 elif action == 'push':
 yield g_off()
 else:
 yield None


def actions(n):
 import random
 for i in range(n-1):
 yield random.choice(['lift','push'])
 yield None

r = 100
#r = 10
next_action = actions(r).next

a = time.clock()
while next_action():
 pass
z = time.clock()
print "action generator overhead:",z-a
common = z-a

print "---"
next_action = actions(r).next
state = s_on # start state
a = time.clock()
while state:
 exec state
z = time.clock()
print "exec:",z-a-common

print "---"
next_action = actions(r).next
state = s_on # start state
a = time.clock()
while state:
 eval(state)
z = time.clock()
print "eval:",z-a-common

print "---"
next_action =  actions(r).next
s_g_on = g_on()
s_g_off = g_off()
state = s_g_on
a = time.clock()
while state:
 #print id(state)
 state = state.next()
z = time.clock()
print "generators:",z-a-common

print "---"
next_action =  actions(r).next
state = f_on
a = time.clock()
while state:
 state = state()
z = time.clock()
print "functions:",z-a-common
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Possible memory leak?

[Paul Rubin]

Paul Rubin  writes:
> Probably better to use StringIO or the array module.

That's cStringIO of course.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Possible memory leak?

[Paul Rubin]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> row = []
> # processing in a loop...
> row.append(chr(num/64)
> # finished processing
> row = "".join(row)  # convert to a string in one hit
> print row

Probably better to use StringIO or the array module.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: socket examples

[Bryan Olson]

le dahut wrote:

> I've read the Gordon McMillan's "Socket Programming HOWTO"

Just a few days ago, another participant in this group noted
that code in Gordon McMillan's "Socket Programming HOWTO"
does not work. He was right. The code is wrong.

Currently, one can Google up "Python socket howto", and
see the wrong code, in section "3 Using a Socket". I
expect we will soon fix this bug. I've send e-mail to
the author's address as presented in the howto. I've not
yet received a reply, but eventually I'll escalate.

The level of the error is astonishing: methods are missing
the 'self' parameter. The 'self' parameter is unneeded in
other languages, but basic in Python. The conclusion is
inescapable: the code in the howto was never tested at all,
nor reviewed by anyone competent in Python.


I myself have posted code that was outright wrong, so I
don't want to come down too hard on any particular author.
Nevertheless, we who advocate Python have to be concerned
that such a basic error appears in one of very few HowTo
documents.


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

ANN: ActivePython 2.4.2.10 is now available

[Trent Mick]

I'm happy to announce that ActivePython 2.4.2.10 is now available for free
download from:
http://www.ActiveState.com/Products/ActivePython/

This release is a maintenance/update release for existing platforms and adds
support for three new ones: Mac OS X/x86, Windows/x64 and Linux/x86_64.  See
below for a full list of supported platforms.

Changes in this release include:
- Add early support for Mac OS X for Intel platform (macosx-x86).
  Please see the "Mac OS X for Intel" section below for details.
- Upgrade to PyWin32 build 207 on Windows/x86
- Upgrade Tkinter to Tcl/Tk 8.4.12
- Support for Windows/x64 (win64-x64). Note that PyWin32 has not been ported
  to 64-bit Windows so this build does not include PyWin32.
- Support for Linux/x86_64 (linux-x86_64)
- Fixed a problem on Mac OS X/PowerPC that unintentionally created a
  dependency on Fink (fink.sourceforge.net) for the "bz2" and "curses"
  extensions. (Thanks, Bob!)
- The Windows "debug libraries" package now allows installation into
  non-ActivePython Python installations of the same version. This was
  requested by Dave Abrahams for the Boost folks (http://tinyurl.com/898zw).
- Changed Intel 32-bit architecture platform name from "ix86" to "x86",
  changing package names for some ActivePython builds.


Mac OS X for Intel
--

This is the first release of ActivePython for Mac OS X/Intel. It should be
considered an early release. This build is not a universal build and there
are a number of known issues:

http://aspn.activestate.com/ASPN/docs/ActivePython/2.4/relnotes.html#KI_macosx

I suspect that ultimately a universal Python build is the right answer, but 
details and issues around that should be discussed on the Python Mac mailing
list:
pythonmac-sig@python.org


What is ActivePython?
-

ActivePython is ActiveState's quality-assured binary distribution of
Python. Builds for AIX, HP-UX, Linux, Mac OS X, Solaris, and Windows 
are made freely available.

ActivePython includes the Python core and core extensions (zlib 1.2.3,
bzip2 1.0.2, bsddb 4.2.52, Tk 8.4.12, and Tix 8.1.4) and is fully
compatible with other Python distributions of the same version.

ActivePython also includes a wealth of Python documentation, including:
- the core Python docs;
- Andrew Kuchling's "What's New in Python" series;
- the Non-Programmer's Tutorial for Python;
- Mark Pilgrim's excellent "Dive into Python"; and
- a snapshot of the Python FAQs, HOWTOs, and PEPs.

An online version of the docs can be found here:
http://aspn.activestate.com/ASPN/docs/ActivePython/2.4/welcome.html

We would welcome any and all feedback to:
[EMAIL PROTECTED]

Please file bugs against ActivePython at:
http://bugs.ActiveState.com/ActivePython


On what platforms does ActivePython run?


ActivePython now includes installers for the following ten platforms:

- AIX/PowerPC
- HP-UX/PA-RISC
- Linux/x86
- (new) Linux/x86_64: "x86_64" is also known as "AMD64"
- Solaris/SPARC
- Solaris/x86
- Mac OS X/PowerPC
- (new) Mac OS X/x86:
- (new) Windows/x64: "x64" is also known as "AMD64"
- Windows/x86


Extra Bits
--

ActivePython releases also include the following packages:

- Windows "debug" package: Debug-built binaries for ActivePython
  users building debug versions of their binary Python extensions.
- ActivePython24.chm: An MS compiled help collection of the full
  ActivePython documentation set. Linux users of applications such as
  xCHM might find this useful. This package is installed by default on
  Windows.

These packages are available from:
ftp://ftp.activestate.com/ActivePython/etc/


Thanks, and enjoy!

Trent, Python Tech Lead

--
Trent Mick
TrentM at ActiveState.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pulling numbers from ASCII filename not working

[IamIan]

The exception I get is "TypeError: Cannot add value 'int' to string." I
have looked at LatString, and it is the string representation of
latitude ('17' etc.). What's odd is that the exception is raised not
when I include LatInt = int(LatString), but when I try to print
LatInt's value or multiply it by another number.

Filenames are along the lines of "N16W110.asc" - is there another way
to get LatString into a number for multiplication purposes?

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

Re: Weird generator id() behaviour (was Re: Python code written in 1998, how to improve/change it?)

[Fredrik Lundh]

Carl Cerecke wrote:

> It turns out that generators are more efficient than the eval function
> excuting bits of compiled code. About 20-25% faster.

why are you using generators to return things from a function, when
you can just return the things ?

def f_on():
print "on"
action = next_action()
if action == 'lift':
return f_on
elif action == 'push':
return f_off

def f_off():
print "off"
action = next_action()
if action == 'lift':
return f_on
elif action == 'push':
return f_off

state = f_on
while state:
state = state()





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

Re: file_name_fixer.py

[Bruno Desthuilliers]

eww a écrit :
(top-post corrected)
> bruno at modulix wrote:
> 
>>[EMAIL PROTECTED] wrote:
>>
>>>i put this together to fix a bunch of files with wierd names, please
>>>gimme feedback, i am a newbie
>>
>>Ok, so let's go... Hope you won't hate me too much !-)

(snip program and comments)

 > thanks for the feedback!

You're welcome. Feel free to ask for more details here if you're unsure 
about some particular point of it.

 > I'll work on your suggestions.


So while you're at it, please follow this one too: avoid posting back 
the whole post you're answering to. Keep the relevant parts only and put 
your answers where appropriate... Readability is important - and not 
only in source code !-)


-- 
bruno at modulix

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

Re: Using non-ascii symbols

[Steven D'Aprano]

On Tue, 24 Jan 2006 15:58:35 -0600, Dave Hansen wrote:

> On Wed, 25 Jan 2006 08:26:16 +1100 in comp.lang.python, Steven
> D'Aprano <[EMAIL PROTECTED]> wrote:
> 
>>On Tue, 24 Jan 2006 10:38:56 -0600, Dave Hansen wrote:
>>
>>> The latter, IMHO.  Especially variable names.  Consider i vs. ì vs. í
>>> vs. î vs. ï vs. ...
>>
>>Agreed, but that's the programmer's fault for choosing stupid variable
>>names. (One character names are almost always a bad idea. Names which can
>>be easily misread are always a bad idea.) Consider how easy it is to
> 
> I wasn't necessarily expecting single-character names.  Indeed, the
> different between i and ì is easier to see than the difference
> between, say, long_variable_name and long_varìable_name.  For me,
> anyway.

Sure. But that's no worse than pxfoobrtnamer and pxfoobtrnamer.

I'm not saying that adding more characters to the mix won't increase the
opportunity to pick bad names. But this isn't a new problem, it is an old
problem.


 
>>shoot yourself in the foot with plain ASCII:
>>
>>
>>l1 = 0
>>l2 = 4
>>...
>>pages of code
>>...
>>assert 11 + l2 = 4
> 
> You've shot yourself twice, there.

Deliberately so. The question is, in real code without the assert, should
the result of the addition be 4, 12, 15 or 23?



-- 
Steven.

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

Re: Possible memory leak?

[Steven D'Aprano]

On Tue, 24 Jan 2006 13:51:36 -0800, Tuvas wrote:

> The purpose of this part of a program is to take a 14 bit numerical
> representation and convert it to an 8 bit representation. This will
> later be displayed as an image. However, I've noticed the following
> about this code. I was noticing when I took a small picture, it went
> really fast, but a larger picture took forever to run through. 

for i in range(10):
for j in range(10):
   # do stuff with i and j
   # this loops 100 times.

for i in range(1000):
for j in range(1000):
   # do stuff with i and j
   # this loops 1,000,000.

Of course the code gets slower as the image size increases.

But the real killer is this one line:

row=row+chr(num/64)

Bad, bad BAD idea. Every time you add two strings together, Python has to
copy BOTH strings. As row gets huge, this takes longer and longer to do.

A rule of thumb I use is, never add more than two strings together. Maybe
three. Certainly not more than four. Or five. 

But absolutely not millions of strings, which is what you are doing.

The best way to handle this is to turn row into a list, and then once, at
the very end, convert the list into a string.

Instead of this:

row = ""
# processing in a loop...
row = row + chr(num/64)
# finished processing
print row

do this instead:

row = []
# processing in a loop...
row.append(chr(num/64)
# finished processing
row = "".join(row)  # convert to a string in one hit
print row

You should find that runs much faster.

> I suspect if I somehow dealocate the row statement
> after it's done, that it will run faster, and the data variable when
> it's done, but I just don't know how to do so.

Once row and data are no longer being used, Python automatically removes
them and reclaims the memory they used. You rarely need to worry about
that.


-- 
Steven.

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

Re: Loop exception catching

[Ivan Shevanski]

On 1/23/06, Aldo Cortesi <[EMAIL PROTECTED]> wrote:
Well, leaving aside the merits of using "input" (which should be avoided at allcosts), here's one way to do what you want:while 1:try:x = input("> ")break
except SyntaxError:print "explain the problem here"Cheers,AldoThanks, that seems to work fine.  But about your other comment. . .
>Well, leaving aside the merits of using "input" (which should be avoided at all>costs)What do you mean?-- -Ivan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Converting date to milliseconds since 1-1-70

[NateM]

Thank you!  If I am reading in dates as strings from a text file, like
"5/11/1998", how do I convert that to a format I can pass into mktime?
Thanks again.

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

Re: Possible memory leak?

[Fredrik Lundh]

Tuvas wrote:

> I have a function in a program that works something like this.
>
> def load_pic_data(width,heigth,inpdat, filt=TRUE):
> data=''
> total=0
> tnum=0
> size=100
> for y in range(0,heigth):
> row=''
> for x in range(0,width):
> index=2*(x+y*width)
> num=ord(inpdat[index+1])*256+ord(inpdat[index])
> if(vfilter.get() and d_filter and filt):
> num=round((num-(d_filter[index/2])))
> if(num<0):
> num=0
> if(num>255*64):
> num=255*64
> row=row+chr(num/64)
> data=data+row
>
> The purpose of this part of a program is to take a 14 bit numerical
> representation and convert it to an 8 bit representation. This will
> later be displayed as an image. However, I've noticed the following
> about this code. I was noticing when I took a small picture, it went
> really fast, but a larger picture took forever to run through. I added
> a print statement to the y portion of the code to see where it was
> getting hung up. I noticed that it appears to be running slower as time
> goes on.

hint: what does

> row=row+chr(num/64)

do, and how often is it executed ?





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

Re: Using non-ascii symbols

[Dave Hansen]

On Wed, 25 Jan 2006 08:26:16 +1100 in comp.lang.python, Steven
D'Aprano <[EMAIL PROTECTED]> wrote:

>On Tue, 24 Jan 2006 10:38:56 -0600, Dave Hansen wrote:
>
>> The latter, IMHO.  Especially variable names.  Consider i vs. ì vs. í
>> vs. î vs. ï vs. ...
>
>Agreed, but that's the programmer's fault for choosing stupid variable
>names. (One character names are almost always a bad idea. Names which can
>be easily misread are always a bad idea.) Consider how easy it is to

I wasn't necessarily expecting single-character names.  Indeed, the
different between i and ì is easier to see than the difference
between, say, long_variable_name and long_varìable_name.  For me,
anyway.

>shoot yourself in the foot with plain ASCII:
>
>
>l1 = 0
>l2 = 4
>...
>pages of code
>...
>assert 11 + l2 = 4

You've shot yourself twice, there.  Python would tell you about the
second error, though.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Creating a more random int?

[Steven D'Aprano]

On Tue, 24 Jan 2006 09:36:49 -0800, Paul Rubin wrote:

> Try reading bytes from os.urandom and converting them to ints in your
> program.

He'll have the same problem with them, since the problem isn't the quality
of the randomness, but his intuition of what a random sequence should look
like.


-- 
Steven.

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

Re: Weird generator id() behaviour (was Re: Python code written in 1998, how to improve/change it?)

[Wolfgang Keller]

On Tue, 24 Jan 2006 21:19:26 +0100, Carl Cerecke wrote
(in article <[EMAIL PROTECTED]>):

> def g_on():
> 
>  print "on"
>  action = next_action()
>  if action == 'lift':
>  yield g_on()
>  elif action == 'push':
>  yield g_off()
>  else:
>  yield None
> 
> def g_off():
> 
>  print "off"
>  action = next_action()
>  if action == 'lift':
>  yield g_on()
>  elif action == 'push':
>  yield g_off()
>  else:
>  yield None

Amazing.

Executable pseudo-code, really. :-)

And that's even (run-time) efficient?

Tanks a lot,

Sincerely,

Wolfgang Keller

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

Possible memory leak?

[Tuvas]

I have a function in a program that works something like this.

def load_pic_data(width,heigth,inpdat, filt=TRUE):
data=''
total=0
tnum=0
size=100
for y in range(0,heigth):
row=''
for x in range(0,width):
index=2*(x+y*width)
num=ord(inpdat[index+1])*256+ord(inpdat[index])
if(vfilter.get() and d_filter and filt):
num=round((num-(d_filter[index/2])))
if(num<0):
num=0
if(num>255*64):
num=255*64
row=row+chr(num/64)
data=data+row


The purpose of this part of a program is to take a 14 bit numerical
representation and convert it to an 8 bit representation. This will
later be displayed as an image. However, I've noticed the following
about this code. I was noticing when I took a small picture, it went
really fast, but a larger picture took forever to run through. I added
a print statement to the y portion of the code to see where it was
getting hung up. I noticed that it appears to be running slower as time
goes on. I did a time.time() timestamp to verify this, and had it
confirmed. Any ideas as to what I could do to make it run faster? Note
that if this process is repeated, it runs equally slow.What can I do to
make it run faster? I suspect if I somehow dealocate the row statement
after it's done, that it will run faster, and the data variable when
it's done, but I just don't know how to do so.Thanks!

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

Re: Creating a more random int?

[Steven D'Aprano]

On Tue, 24 Jan 2006 18:47:01 +0200, Steven Macintyre wrote:

> Hi all,
> 
> I need to retrieve an integer from within a range ... this works ... below
> is my out puts ... it just does not seem so random ... 

You are choosing from six values. You should expect each value _about_
17% of the time, in the long-term. On your tiny sample of 17 samples, you
get this:

7 3 3 4 3 4 7 7 7 5 6 3 8 8 5 3 4

3 occurs five times or 29%
4 occurs three times or 18%
5 occurs two times or 12%
6 occurs one time or 6%
7 occurs four times or 23%
8 occurs two times or 12%

Looks pretty random to me.

With only 17 trials, it would be a major miracle to get near 17% for every
number. If you actually got something like this:

5 3 4 5 8 4 7 5 6 8 6 3 6 7 4 3 7

the odds are VERY strong that it is not really random. For one thing, it
is too good to be true. For another thing, there are no repeated values.
The chances of there being no repeated values is very small indeed.

> Is there perhaps a suggestion out there to create a more random int ...?

23 is the most random int. Perhaps you should use that.

But all joking aside, the random number generator used by Python is one of
the best in the world. What is at fault is your intuition about what
random numbers should look like, not the random number generator.


-- 
Steven.

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

Re: Some thougts on cartesian products

[Christoph Zwerschke]

I think this has been discussed thoroughgoing enough. All I wanted to 
say is that this proposal of building "Cartesian products" of strings is 
well-defined, in line with the mathematical concept of Cartesian 
products, and can be *sometimes* useful. I hope we agree on this, but if 
not we don't need to go through this again...

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

Re: Loading a Python collection from an text-file

[[EMAIL PROTECTED]]

Maybe YAML is what youre looking for...
http://yaml.org

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

Re: Using non-ascii symbols

[Steven D'Aprano]

On Tue, 24 Jan 2006 10:38:56 -0600, Dave Hansen wrote:

> The latter, IMHO.  Especially variable names.  Consider i vs. ì vs. í
> vs. î vs. ï vs. ...

Agreed, but that's the programmer's fault for choosing stupid variable
names. (One character names are almost always a bad idea. Names which can
be easily misread are always a bad idea.) Consider how easy it is to
shoot yourself in the foot with plain ASCII:


l1 = 0
l2 = 4
...
pages of code
...
assert 11 + l2 = 4


-- 
Steven.

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

Re: append to the end of a dictionary

[Steven D'Aprano]

On Tue, 24 Jan 2006 08:45:27 -0600, Tim Chase wrote:

> To get them in a key-order, my understanding is that you have to 
> use something like
> 
>   keys = mydict.keys()
>   sort(keys)
>   orderedDict = [(k, mydict[k]) for k in keys]

Did you test this before posting?

>>> keys = ["a", "b"]
>>> sort(keys)
Traceback (most recent call last):
  File "", line 1, in ?
NameError: name 'sort' is not defined

sort is not a built-in function.

What you want is to call the sort method of the list:

keys.sort()

The sort method is always in-place, it does NOT return the newly sorted
list.

If you are using Python 2.4 or up, you can call the function sorted(keys)
which leaves the original list as is, creates a copy, and sorts the copy.


> unless you have a way of doing an in-line sort, in which you would be
> able to do something like
> 
>orderedDict = [(k,mydict[k]) for k in mydict.keys().sort()]
> 
> Unfortunately, the version I've got here doesn't seem to support a
> sort() method for the list returned by keys(). :(

Remember, list.sort() does NOT return the list. It returns None. What you
are doing there is sorting the keys, throwing the sorted list away, and
trying to iterate over None.


-- 
Steven.

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

Re: Some thougts on cartesian products

[Bryan Olson]

Christoph Zwerschke wrote:
> Bryan Olson wrote:
> 
>> The claim "everything is a set" falls into the category of
>> 'not even wrong'.
> 
> No, it falls into the category of the most fundamental Mathematical 
> concepts. You actually *define* tuples as sets, or functions as sets or 
> relations as sets, or even all kinds of numbers and other things which 
> exist in the heads of Mathematicians as sets.

No, wrong ... or well, obviously ... or uh ... sorry.
I've lost track of what we're arguing. If you want to
stand behind "everything is a set," I can certainly present
a case to the contrary.

Is there anything I actually claimed that you are prepared to
argue against? Cite me, and I'll defend or retract, or at least
re-phrase.

I definitely did make specific claims. I'll list them if you want,
and I'll listen to evidence against them, should you choose to
present any. I expect that neither of us wants to devote our
energy to flaming on in violent agreement.


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

Re: append to the end of a dictionary

[Steven D'Aprano]

On Tue, 24 Jan 2006 16:01:48 +0100, Yves Glodt wrote:

> that means I can neither have a dictionary with 2 identical keys but 
> different values...?

Yes, that's correct.

> I would need e.g. this:
> (a list of ports and protocols, to be treated later in a loop)
> 
> 
> 
> ports = {'5631': 'udp', '5632': 'tcp', '3389': 'tcp', '5900': 'tcp'}

Which will work perfectly fine as a dict, because you have unique keys but
multiple values. Two keys with the same value is allowed.

Question: is there a reason the port numbers are stored as strings instead
of numbers?


> #then:
> for port,protocol in ports.iteritems():
> print port,protocol
> #do more stuff
> 
> 
> What would be the appropriate pythonic way of doing this?


Is it even possible to have multiple protocols listening on the
same port? Doesn't matter I suppose. Associating multiple values to the
same key is easy: just store the values in a list:


foods = { "red": ["apple", "tomato", "cherry"], 
  "green": ["apple", "lettuce", "lime"], 
  "blue": ["blueberry"],
  "yellow": ["butter", "banana", "apple", "lemon"] }

# add a new colour
foods["orange"] = ["orange"]
# add a new food to a colour
foods["red"].append("strawberry")

for colour, foodlist in foods.iteritems():
for food in foodlist:
print colour, food


If you need to use the keys in a particular order, extract the keys and
sort them first:

colours = foods.keys()
colours.sort()
for colour in colours:
for food in foods[colour]:
print colour, food



-- 
Steven.

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

Re: Pulling numbers from ASCII filename not working

[Larry Bates]

At lest one of the filenames (or directories) being returned by
os.listdir doesn't have integer value where you are looking.
Remember that os.listdir returns subdirectories as well as files.
You may want to look at using glob.glob() instead and limit it
to *.asc.

Secondly,

filenames = [filename.lower() \
for filename in filenames \
if (filename[-4:].lower() == ".asc" and filename[0] != "-" )]

is better rewritten as (not tested):

import glob
filenames=glob.glob(os.path.join(gp.workspace, '*.asc'))
filenames = [f.lower() for f in filenames if not f.startswith('-')]

Larry Bates

IamIan wrote:
> I searched the archives but couldn't find anyone else with this
> problem. Basically I'm grabbing all ASCII files in a directory and
> doing geoprocessing on them. I need to calculate a z-factor based on
> the latitude of the ASCII file being worked on, which is in the
> filename. If I type in the code manually it works and reads the
> latitude value from the ASCII filename, but when run within ArcGIS it
> crashes when it gets to int(LatString). Isnumber() returned false for
> Latitude as well. Is there something different about reading values
> from an ASCII filename?
> 
> import sys, os, win32com.client, string, gc
> 
> # Get a list of ASCII files in the workspace for ASCII To Raster
> conversion
> filenames = os.listdir(gp.workspace)
> filenames = [filename.lower()
> for filename in filenames
> if (filename[-4:].lower() == ".asc" and filename[0] != "-" )]
> for filename in filenames:
> 
> # For each ASCII file, create Hillshade.
> # account for latitude by computing Z units using radians
> Latitude = filename[1:3]
> LatString = str(Latitude)
> LatInt = int(LatString)
> radians = LatInt * 0.0174532925
> zFactor = 1/(113200 * (cos(radians)))
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python code written in 1998, how to improve/change it?

[skip]

Wolfgang> So basically if I want to write a long-running program in
Wolfgang> Python, it would make sense to code all functions that are
Wolfgang> likely to be called more than once as generators...

If they need to resume their calculations from where they left off after the
last yield.

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

Re: Oddities of Tkinter

[Tuvas]

I thought I mentioned that I'm running in linux, and yes, there are
threads involved. I just don't know why on one machine that it would
run so differently than another.

As to re-writing my whole code, well, I've got around 2500 lines of
code, and while re-writing would be faster I'm sure, I still don't want
to invest in the long hours to do such a thing. Especially since 90% of
the time that it will be running on the one machine that works, only a
small percentage on the other, and it will never be publically used.
It's an interface for a custom-built astronamical camera, it'd be
useless to anyone who doesn't have the very camera that we have, except
to get an idea as to how some things work.

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

Re: Converting date to milliseconds since 1-1-70

[gry]

NateM wrote:
> How do I convert any given date into a milliseconds value that
> represents the number of milliseconds that have passed since January 1,
> 1970 00:00:00.000 GMT?
> Is there an easy way to do this like Date in java?
> Thanks,
> Nate

The main module for dates and times is "datetime"; so

>>> import datetime
>>> t=datetime.datetime.now()
>>> print t
2006-01-24 15:13:35.012755

To get at the "epoch" value, i.e. seconds since 1/1/1970, use the
"time" module:

>>> import time
>>> print time.mktime(t.timetuple())
1138133615.0

Now just add in the microseconds:
>>> epoch=time.mktime(d.timetuple())+(t.microsecond/100.)
>>> print epoch
1138133615.01

Use the "%" formatting operator to display more resolution:
>>> print '%f' % t
1138133615.012755

Note that the floating point division above is not exact and could
possibly
mangle the last digits.

Another way to this data is the datetime.strftime member:

>>> print d.strftime('%s.%%06d') % d.microsecond
'1138133615.012755'

This gets you a string, not a number object.  Converting the string to
a number again risks inaccuracy in the last digits:
>>> print float( '1138133615.012755')
1138133615.0127549

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

Weird generator id() behaviour (was Re: Python code written in 1998, how to improve/change it?)

[Carl Cerecke]

Wolfgang Keller wrote:
> On Fri, 20 Jan 2006 05:16:57 +0100, Peter Hansen wrote
> (in article <[EMAIL PROTECTED]>):
> 
> 
>>I believe the more modern approach to this is to use generators in some 
>>way, yield each other as the next state.  This way you avoid all almost 
>>all the function call overhead (the part that takes significant time, 
>>which is setting up the stack frame) and don't have to resort to 
>>bytecode hacks for better performance.
> 
> 
> Dumb question from a endless newbie scripting dilettant:
> 
> Do you have a reference to a cookbook example for this method?

It turns out that generators are more efficient than the eval function 
excuting bits of compiled code. About 20-25% faster.

However, the generators exhibit some weird behaviour.

The included code shows an example using a compile/eval FSM method, and 
a generator method. Note, in particular, the pattern of ids of the 
generator objects. I had expected some complications in the ids, but not 
a repeatable sequence of length 3 after the first generator object.

What is going on? Anybody?

#!/usr/bin/env python

import time

s_on = compile('''
print 'on'
action = next_action()
if action == 'lift':
 state = s_on
elif action == 'push':
 state = s_off
else:
 state = None
''','','exec')

s_off = compile('''
print 'off'
action = next_action()
if action == 'lift':
 state = s_on
elif action == 'push':
 state = s_off
else:
 state = None
''','','exec')


def g_on():

 print "on"
 action = next_action()
 if action == 'lift':
 yield g_on()
 elif action == 'push':
 yield g_off()
 else:
 yield None

def g_off():

 print "off"
 action = next_action()
 if action == 'lift':
 yield g_on()
 elif action == 'push':
 yield g_off()
 else:
 yield None


def actions(n):
 import random
 for i in range(n-1):
 yield random.choice(['lift','push'])
 yield None

#r = 100
r = 10
next_action = actions(r).next

#a = time.clock()
while next_action():
 pass
#z = time.clock()
#print "action generator:",z-a
next_action = actions(r).next
#print "---"
state = s_on # start state
#a = time.clock()
while state:
 eval(state)
#z = time.clock()
#print z-a
print "---"

next_action =  actions(r).next
s_g_on = g_on()
s_g_off = g_off()
state = s_g_on
#a = time.clock()
while state:
 print id(state)
 state = state.next()
#z = time.clock()
#print z-a


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

Re: Pulling numbers from ASCII filename not working

[mrmakent]

First: http://www.catb.org/~esr/faqs/smart-questions.html

You say your program 'crashes' when it gets to 'int(LatString)'.  I'm
guessing (and it's entirely a guess, since you don't tell us) that you
are getting an exception like 'ValueError: invalid literal for int():
whatever'.  I'm guessing again that 'LatString' doesn't contain what
you think it does at this point.  Have you tried inserting a print
statement to show you just what 'LatString' contains?

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

CTI library interest?

[gregarican]

As part of a project I'm trying to port to Python I am planning on
moving a CTI library it relies on into Python code. Previously the
overall project as well as the associated library were written in Ruby.
Specifically the CTI library utilizes TSAPI/CSTA for linking telephone
equipment with IP computer endpoints. For a glimpse into the Ruby
version of the CTI library check out http://tsapi.rubyforge.org.

Is anyone interested in assisting with the Python implementation of
this CTI library? If you have access to a TSAPI/CSTA-compliant PBX
system or can compile a CSTA simulator on a Linux box that's all you
need to try out your code.

Anyone want to pitch in?

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

Re: getting a KeyError:'href' any ideas?

[[EMAIL PROTECTED]]

ok the syntax for next is this:

b = n.findNext



LordLaraby wrote:
> You wrote:
> > i have an
> > href which looks like this:
> > 
> > http://www.cnn.com";>
> > 
> > here is my code
> > for incident in row('td', {'class':'all'}):
> > n = incident.findNextSibling('a', {'class': 'btn'})
> > link = incident.findNextSibling['href'] + "','"
> > any idea what i'm doing wrong here with the syntax?  thanks in advance
> Since you already found the anchor tag with the 'btn' class attribute,
> just grab it's href attribute like so:
> for incident in row('td', {'class':'all'}):
>n = incident.findNextSibling('a', {'class': 'btn'})
>link = n['href'] + "','"
> 
> Works for me...
> 
> LL

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

Re: Using non-ascii symbols

[Christoph Zwerschke]

Fredrik Lundh wrote:
> umm.  if you have an editor that can convert things back and forth, you
> don't really need language support for "digraphs"...

It would just be very impractical to convert back and forth every time 
you want to run a program. Python also supports tabs AND spaces though 
you can easily convert things.

But indeed, in 100 years or so ;-) if people get accustomed to using 
these symbols and input will be easy, digraph support could become 
optional and then phase out... Just as now happens with C trigraphs.

-- Christoph



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

Re: www.mywebsite.py

[Simon Brunning]

On 1/24/06, Cyril Bazin <[EMAIL PROTECTED]> wrote:
> Does someone ever tried (and succeed) to make an address like
> "www.website.py".
> I found that the .py extension is given to the paraguay.
>
> I found this link ( http://www.nic.py/) but I don't speak spanish...
>
> If someone has more informations...

This any help?



If it's as bad as the English translation, probably not. ;-)

--
Cheers,
Simon B,
[EMAIL PROTECTED],
http://www.brunningonline.net/simon/blog/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using non-ascii symbols

[Dave Hansen]

On Tue, 24 Jan 2006 19:44:28 +0100 in comp.lang.python, Christoph
Zwerschke <[EMAIL PROTECTED]> wrote:

>Dave Hansen wrote:
>> C uses ! as a unary logical "not" operator, so != for "not equal" just
>> seems to follow, um, logically.
>
>Consequently, C should have used !> for <= and !< for >= ...

Well, actually, no.

"Less (than) or equal" is <=.  "Greater (than) or equal" is >=.  "Not
equal" is !=. 

If you want to write code for the IOCCC, you could use !(a>b) instead
of a<=b...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python code written in 1998, how to improve/change it?

[Wolfgang Keller]

On Fri, 20 Jan 2006 05:16:57 +0100, Peter Hansen wrote
(in article <[EMAIL PROTECTED]>):

> I believe the more modern approach to this is to use generators in some 
> way, yield each other as the next state.  This way you avoid all almost 
> all the function call overhead (the part that takes significant time, 
> which is setting up the stack frame) and don't have to resort to 
> bytecode hacks for better performance.

Dumb question from a endless newbie scripting dilettant:

Do you have a reference to a cookbook example for this method?

Sidequestion: As I understand it, as a general rule generators are more 
efficient than functions in any case where the function is called several 
times, right? So basically if I want to write a long-running program in 
Python, it would make sense to code all functions that are likely to be 
called more than once as generators...

TIA,

Sincerely,

Wolfgang Keller

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

Re: getting a KeyError:'href' any ideas?

[[EMAIL PROTECTED]]

what is the syntax used to find a child of td?

Mike Meyer wrote:
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
>
> Please use less whitespace in your posts in the future. There's really
> no need to put two blank lines between sections.
>
> > i have an
> > href which looks like this:
> > 
> > http://www.cnn.com";>
> > 
> > here is my code
> > for incident in row('td', {'class':'all'}):
> > n = incident.findNextSibling('a', {'class': 'btn'})
> > link = incident.findNextSibling['href'] + "','"
> > any idea what i'm doing wrong here with the syntax?  thanks in advance
>
> It's not the syntax, it's the logic. the a element is not a sibling of
> the td element, it's a child. findNextSibling is going to return the
> next td, assuming there is one. Trying to index
> incident.findNextSibling in the next line is also broken. That's a
> method, not an indexable object. So that line will also break.
>
>  --
> Mike Meyer <[EMAIL PROTECTED]>
> http://www.mired.org/home/mwm/
> Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

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

Re: Using non-ascii symbols

[Claudio Grondi]

Christoph Zwerschke wrote:
> Claudio Grondi wrote:
> 
>> There is no symbol coming to my mind, but I would be glad if it would 
>> express, that 'a' becomes a reference to a Python object being 
>> currently referred by the identifier 'b' (maybe some kind of <-> ?).
> 
> 
> With unicode, you have a lot of possibilities to express this:
> 
> a ← b # a = b
> a ⇐ b # a = copy(b)
> a ⇚ b # a = deepcopy(b)
 ^-- with this above also the notation

   a ← b # a = b

starts to be obvious to me, as it covers also some of the specifics of 
Python.

Nice idea.

Claudio
>> 
>> -- Christoph
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using non-ascii symbols

[Christoph Zwerschke]

Dave Hansen wrote:
>> Once you open your mind for using non-ascii symbols, I'm sure one can 
>> find a bunch of useful applications. Variable names could be allowed to 
>> be non-ascii, as in XML. Think class names in Arabian... Or you could 
>> use Greek letters if you run out of one-letter variable names, just as 
>> Mathematicians do. Would this be desirable or rather a horror scenario? 
> 
> The latter, IMHO.  Especially variable names.  Consider i vs. ì vs. í
> vs. î vs. ï vs. ...

There could be conventions discouraging you to use ambiguous symbols. 
Even today, you wouldn't use a lowercase "l" or an "O" because it can be 
confused with a digit 1 or 0. But you're right this problem would become 
much greater with unicode chars. This kind of pitfall has already been 
overlooked with the introduction of international domain names which are 
  exploitable for phishing attacks...

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

Re: list comprehention

[Paddy]

Umm,
My answer is not correct, but for a different reason; it seems you need
the length of my
previous answer, thus:

PythonWin 2.4 (#60, Feb  9 2005, 19:03:27) [MSC v.1310 32 bit (Intel)]
on win32.
Portions Copyright 1994-2004 Mark Hammond ([EMAIL PROTECTED]) -
see 'Help/About PythonWin' for further copyright information.

>>> ref = [3, 3, 1, 1, 3]
>>> lst=[5, 1, 4, 5, 3]
>>> answer = len([ val for val in set(ref) for x in range(min(lst.count(val), 
>>> ref.count(val)))])
>>> answer
2
>>> 

- Paddy.

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

Re: socket examples

[Bryan Olson]

le dahut wrote:
> I have a server that receives data from a client, detect the end of this 
> data and send other data back to the client (it's to measure bandwidth).
> I think the best way is to thread a part of the server's program am I 
> right ?

Others disagree on this, but in most cases, yes: threads
are the way to go. Usually daemon threads. Start with:

import threading

Write a function to handle one connection.

def handler(conn, addr):
 pass   # move the per-connection code here


> HOST = socket.gethostname()

In most cases, you don't want that. In building the argument
to bind(), use socket.INADDR_ANY to accept connections on any
available interface, including the local loopback address.
The bind() function in Python's socket module will treat the
empty string as INADDR_ANY.


> try:
> PORT = int(sys.argv[1])
> print PORT
> except:
> PORT = 50009
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> print "s.bind((", HOST, PORT, "))"
> s.bind((HOST, PORT))
> s.listen(5)
> while 1:
> conn, addr = s.accept()

This is where you call your connection handling function.

  t = threading.Thread(target=handler, args=(conn, addr))
  t.setDaemon(True)
  t.start()

Obviously, move the per-connection code into the handler()
function.

You might want to launch the thread within a try-except block,
with a catch-all except that logs an otherwise uncaught
exception.


> print 'Connected by', addr
> data=''
> while 1:
> data += conn.recv(1024)

Don't count on recv() returning more than one byte, even
from an open and healthy connection. See the doc for
socket.recv.

> if data[-5:] == '#': #the end of the data
> break

There's a better way to shut down: when done sending data,
call socket.shutdown(socket.SHUT_WR). If the remote side
has shutdown writing, recv() will return the empty string
(after returning all the data, of course).

End-of-connection is the only case in which recv(nonzero)
will return the empty string. Also note that a socket will
select() as readable on end of connection.

Unfortunately, in some cases a connection that ends
because of an error can mimic graceful shutdown. A
zero-byte return from recv(nonzero) always means
end-of-data, but does not necessarily mean you've
received everything the remote side wanted to send.

> 
> data2='1'*1024*1024
> data2=data2[:-5]+'#' #the end of the data
> conn.send(data2)

Don't count on send() sending all the data you pass.
Python's sockets offer the convenient method sendall()
which does send all the data it is passed before returning.
When using a thread per connection, sendall() is the way
to go.

> conn.close()

Right; closing is good practice. As noted above, I
recommend shutting down writing and detecting end-of-data
before closing. Incidentally, shutting down reading is
utter trivia and best left to close().


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

Converting date to milliseconds since 1-1-70

[NateM]

How do I convert any given date into a milliseconds value that
represents the number of milliseconds that have passed since January 1,
1970 00:00:00.000 GMT?
Is there an easy way to do this like Date in java?
Thanks,
Nate

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

www.mywebsite.py

[Cyril Bazin]

Does someone ever tried (and succeed) to make an address like "www.website.py".I found that the .py extension is given to the paraguay.I found this link (
http://www.nic.py/) but I don't speak spanish... If someone has more informations...Cyril
-- 
http://mail.python.org/mailman/listinfo/python-list

Pulling numbers from ASCII filename not working

[IamIan]

I searched the archives but couldn't find anyone else with this
problem. Basically I'm grabbing all ASCII files in a directory and
doing geoprocessing on them. I need to calculate a z-factor based on
the latitude of the ASCII file being worked on, which is in the
filename. If I type in the code manually it works and reads the
latitude value from the ASCII filename, but when run within ArcGIS it
crashes when it gets to int(LatString). Isnumber() returned false for
Latitude as well. Is there something different about reading values
from an ASCII filename?

import sys, os, win32com.client, string, gc

# Get a list of ASCII files in the workspace for ASCII To Raster
conversion
filenames = os.listdir(gp.workspace)
filenames = [filename.lower()
for filename in filenames
if (filename[-4:].lower() == ".asc" and filename[0] != "-" )]
for filename in filenames:

# For each ASCII file, create Hillshade.
# account for latitude by computing Z units using radians
Latitude = filename[1:3]
LatString = str(Latitude)
LatInt = int(LatString)
radians = LatInt * 0.0174532925
zFactor = 1/(113200 * (cos(radians)))

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

Re: Using non-ascii symbols

[Christoph Zwerschke]

Dave Hansen wrote:
> C uses ! as a unary logical "not" operator, so != for "not equal" just
> seems to follow, um, logically.

Consequently, C should have used !> for <= and !< for >= ...

-- Christoph

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

Re: Using non-ascii symbols

[Christoph Zwerschke]

Claudio Grondi wrote:
> There is no symbol coming to my mind, but I would be glad if 
> it would express, that 'a' becomes a reference to a Python object being 
> currently referred by the identifier 'b' (maybe some kind of <-> ?).

With unicode, you have a lot of possibilities to express this:

a ← b # a = b
a ⇐ b # a = copy(b)
a ⇚ b # a = deepcopy(b)

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

Re: Using non-ascii symbols

[Christoph Zwerschke]

UTF-8 is also the standard encoding of SuSE Linux since I version 9.1. 
Both VIM and EMACS provide ways to enter unicode. VIM even supports 
digraph input which would be particularly senseful in this case.

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

Re: "wxPython in Action" book

[SPE - Stani's Python Editor]

You won't find a better book about wxPython.

Stani
--
http://pythonide.stani.be

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

Re: Using non-ascii symbols

[Fredrik Lundh]

Christoph Zwerschke wrote:

> > My point still stands: _somewere_ along the way the rendering got messed
> > up for _some_ people - something that wouldn't have happened with the
> > <=, >= and != digraphs.
>
> Yes, but Python is already a bit handicapped concerning posting code
> anyway because of its significant whitespace. Also, I believe once
> Python will support this, the editors will allow converting "digraphs"
> <=, >= and != to symbols back and forth

umm.  if you have an editor that can convert things back and forth, you
don't really need language support for "digraphs"...





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

am i using findNextSibling wrong?

[localpricemaps]

i have this html:



3.99


1.05


3

http://www.cnn.com";
target="_blank" onclick="reload()">

i tried to this use this python to scrape out the href cnn.com and
failed.

for incident in row('td', {'class':'price'}):
  n = incident.findNextSibling('a')
  b = n.findNextSibling('div')
  c = b.findNextSibling('div')
  d = c.findNextSibling('a', {'class': 'btn'}')
  info = d['href'] + "','"
  print info

and i tried this
for incident in row('td', {'class':'price'}):
n = incident.findNextSibling('a', {'class': 'btn'})
info = n['href'] + "','"
print info

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

Re: Using non-ascii symbols

[Christoph Zwerschke]

Rocco Moretti schrieb:
> My point still stands: _somewere_ along the way the rendering got messed 
> up for _some_ people - something that wouldn't have happened with the 
> <=, >= and != digraphs.

Yes, but Python is already a bit handicapped concerning posting code 
anyway because of its significant whitespace. Also, I believe once 
Python will support this, the editors will allow converting "digraphs" 
<=, >= and != to symbols back and forth, just as all editors learned to 
convert tabs to spaces back and forth... And newsreaders and mailers are 
also improving. Some years ago, I used to write all German Umlauts as 
digraphs because you could never be sure how they arrived. Nowadays, I'm 
using Umlauts as something very normal.

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

Re: Some thougts on cartesian products

[Christoph Zwerschke]

Bryan Olson wrote:
 > The claim "everything is a set" falls into the category of
 > 'not even wrong'.

No, it falls into the category of the most fundamental Mathematical 
concepts. You actually *define* tuples as sets, or functions as sets or 
relations as sets, or even all kinds of numbers and other things, which 
exist only in the heads of Mathematicians, as sets.

 > Watch things not be sets:
 >
 >x = [1, 1, 2]
 >y = [1, 2]
 >print x == y
 >print set(x) == set(y)

Python tuples and lists are of course not the same as Python sets. But 
mathematically, you can understand them as sets anyway and associate 
every Python tuple with a Python set. The naive approach to understand a 
list as the set of its values which is done by casting with set() does 
not work, as you rightly noticed. The associated set to a Python tuple 
or list x would be set(enumerate(x)), not set(x).

Generally, two approaches are common for constructing tuples as sets:

(A) Think of an n-tuple as a function on the index set, range(n). Then 
remember a function is a special relation is a set.

   (1, 2, 2) would correspond to the set {(0, 1), (1, 2), (2, 2)}
   (1, 2) would correspond to the set {(0, 1), (1, 2)}

In Python, the tuple or list x would correspond to set(enumerate(x)).

As a sidemark, another common approach is this:

(B) Define the set corresponding to (1, 2) as {{1}, 2}. Define the set 
corresponding to (1, 2, 2) as {{{1}, 2}, 2}, the set corresponding to 
(1, 2, 2, 4) as 1}, 2}, 2}, 4} and so on.

 > I really did try to raise the real issues. I cannot make you answer,
 > but the question remains: are duplicate and order significant in
 > what you call "Cartesian product" or they not? Can you show that
 > your proposed language extensions are  useful and consistent in
 > some reasonable sense?

I already tried to answer. It is not what "I call" Cartesian product. If 
there is a canonical set representation of something like a function or 
a tuple you immediately have a well-defined Cartesian product on these 
things, and this would be also called Cartesian product. A Cartesian 
product of functions and tuples is a well-defined mathematical concept. 
The Cartesian product of functions is even a function again, and (via 
lexicographical order of the index set) you can also interpret the 
Cartesian product of tuples as a tuple again (this was probably the 
point where you had doubts, but I already tried to explain).

The only ambiguity is whether the result should be a generator or a 
tuple, and in the case of strings whether the elements in the result 
should be returned as tuples,
"ab"*"cd" = ("a", c"), ("a", "d"), ("b", "c"), ("b", "d")
or concatenated as strings:
"ab"*"cd" = "ac", "ad", "bc", "bd"

In any way, there is no dispute about duplicates or ordering. This is 
all canonical and well-defined.

Concerning the use, I admit there is no really frequent use, but in some 
occasions it may be useful and I already gave some examples.

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

Re: Creating a more random int?

[Tim Chase]

> I need to retrieve an integer from within a range ... this
> works ... below is my out puts ... it just does not seem so
> random ...
> 
> Is there perhaps a suggestion out there to create a more
> random int ...?

I'm not sure how you determine that "it just does not seem so
random"...I tried the following:

>>> import random
>>> samples = 1
>>> x = [random.randint(3,8) for i in range(1,samples+1)]
>>> s = 0
>>> for i,j,k in [(i,x.count(i), (samples/6.0)-x.count(i)) for i
in range(3,9)]:
... print i,j,k
... s = s + k
...
3 1735 -68.33
4 1634 32.67
5 1608 58.67
6 1688 -21.33
7 1670 -3.333
8 1665 1.667
>>> s
-5.6843418860808015e-14

It also seems to hover fairly closely about the mid-point in 
terms of distribution.  Looks like a fairly decent sampling to 
me.  Is there some statistical test it's failing for you?

-tim






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

Re: list comprehension

[Duncan Booth]

Patrick Maupin wrote:

> Duncan Booth wrote:
> 
>> I prefer writing an 'if' statement here, Bryan prefers 'get', that's
>> just a choice of style. But 'setdefault' here, that has no style.
> 
> Well, I'm often told I have no style, and I _did_ admit that it's an
> abuse of setdefault.  However, I often use setdefault to populate
> nested dictionaries, or dictionaries of sets or lists, e.g.:
> 
> for x, y in somebiglist:
> bigdict.setdefault(x,set()).add(y)   # Strips duplicates
> 
> 
> for x, y in somebiglist:
> bigdict.setdefault(x,[]).append(y)   # Preserves duplicates
> 
> To my mind, this latter is so much cleaner and clearer than any of the
> alternatives that it just isn't funny:

Yes, but storing a mutable is a not unreasonable use of setdefault. What I 
objected to was storing an immutable just to overwrite it immediately.

Also, while I agree it is shorter, I'm not convinced that it is much 
cleaner, and it is likely to be slower if there are a lot of duplicates, 
possibly a lot slower if the mutable object has much overhead on its 
construction.

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

Re: Creating a more random int?

[[EMAIL PROTECTED]]

Steven Macintyre wrote:
> Hi all,
>
> I need to retrieve an integer from within a range ... this works ... below
> is my out puts ... it just does not seem so random ...

What's wrong with it?

>
> Is there perhaps a suggestion out there to create a more random int ...?

What do you think the output should be?

What's your criteria for "more random"?

>
> >>> random.randint(3, 8)
> 7
> >>> random.randint(3, 8)
> 3
> >>> random.randint(3, 8)
> 3
> >>> random.randint(3, 8)
> 4
> >>> random.randint(3, 8)
> 3
> >>> random.randint(3, 8)
> 4
> >>> random.randint(3, 8)
> 7
> >>> random.randint(3, 8)
> 7
> >>> random.randint(3, 8)
> 7
> >>> random.randint(3, 8)
> 5
> >>> random.randint(3, 8)
> 6
> >>> random.randint(3, 8)
> 3
> >>> random.randint(3, 8)
> 8
> >>> random.randint(3, 8)
> 8
> >>> random.randint(3, 8)
> 5
> >>> random.randint(3, 8)
> 3
> >>> random.randint(3, 8)
> 4
> 
> Regards,
> 
> 
> Steven

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

Re: Some thougts on cartesian products

[Christoph Zwerschke]

Bryan Olson wrote:
> The claim "everything is a set" falls into the category of
> 'not even wrong'.

No, it falls into the category of the most fundamental Mathematical 
concepts. You actually *define* tuples as sets, or functions as sets or 
relations as sets, or even all kinds of numbers and other things which 
exist in the heads of Mathematicians as sets.

> Watch things not be sets:
> 
>x = [1, 1, 2]
>y = [1, 2]
 >print x == y
 >print set(x) == set(y)

Python tuples and lists are of course not the same as Python sets.
But mathematically, you can understand them as sets anyway and associate 
every Python tuple with a Python set. The naive approach to understand a 
tuple as the set of its values which is done by casting to set() does 
not work, as you rightly noticed. The associated set to a Python tuple 
or list x would be set(enumerate(x)), not set(x).

Generally, two approaches are common for constructing tuples as sets:

(A) Think of an n-tuple as a function on the index set, range(n). Then 
remember a function is a special relation is a set.

   (1, 2, 2) would correspond to the set {(0, 1), (1, 1), (1, 2)}
   (1, 2) would correspond to the set {(0, 1), (1, 2)}

In Python, the tuple or list x would correspond to set(enumerate(x)).

As a sidemark, another common approach is this:

(B) Define the set corresponding to (1, 2) as {1, 2}. Define the set 
corresponding to (1, 2, 2) as {{1, 2}, 2}, the set corresponding to (1, 
2, 2, 4) as {{{1, 2}, 2}, 4} and so on.

> I really did try to raise the real issues. I cannot make you answer,
> but the question remains: are duplicate and order significant in
> what you call "Cartesian product" or they not? Can you show that
> your proposed language extensions are  useful and consistent in
> some reasonable sense?

I already tried to answer. It is not what "I call" Cartesian product. 
Since functions are sets in Mathematics, once you have a Cartesian 
product on sets, there is a natural (canonical) way to define a 
Cartesian product on functions as well. So there is also a canonical way 
to define a Cartesian product on tuples, if you interpret tuples as 
functions via (A). And there is a canonical way to understand the 
resulting sets as tuples again (by the lexicographical order of the 
index set).

So the cartesian product of a string, tuple, or list is well-defined 
including its order.

The only ambiguity is whether the result should be a generator or a 
tuple, and in the case of strings whether the elements in the result 
should be returned as tuples,
"ab"*"cd" = ("a", c"), ("a", "d"), ("b", "c"), ("b", "d")
or concatenated as strings:
"ab"*"cd" = "ac", "ad", "bc", "bd"

In any way, there is no dispute about duplicates or ordering. This is 
all canonical and well-defined.

Concerning the use, I admit there is no really frequent use, but in some 
occasions it may be useful and I already gave some examples.

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

Re: Creating a more random int?

[Paul Rubin]

"Steven Macintyre" <[EMAIL PROTECTED]> writes:
> I need to retrieve an integer from within a range ... this works ... below
> is my out puts ... it just does not seem so random ... 

It's pretty normal for random small ints to not look random.  Are
there some statistical tests that the prng is definitely failing?

> Is there perhaps a suggestion out there to create a more random int ...?

Try reading bytes from os.urandom and converting them to ints in your
program.
-- 
http://mail.python.org/mailman/listinfo/python-list

customized instance dictionaries, anyone?

[wolfgang . lipp]

some time after posting my `Linkdict recipe`__ to aspn__
-- basically, a dictionary with run-time delegational
lookup, but this is not important here -- i thought gee
that would be fun to make such a customized dictionary
thingie an instance dictionary, and get some custom
namespace behavior out of that.

..  __: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/465748
..  __: http://aspn.activestate.com/

here is a simplified example: first, the customized
dictionary class and a test::


class CustomDict( dict ):

defaultValue = 'THIS ITEM NOT AVAILABLE'

def __getitem__( self, name ):
try:
return super( CustomDict, self ).__getitem__( name )
except KeyError:
return self.defaultValue

def __contains__( self, name ):
return True

def has_key( self, name ):
return True

print ''
cd = CustomDict( foo = 'bar' )
print cd[ 'foo' ]
print cd[ 'bar' ]
print 'bar' in cd
print cd.has_key( 'bar' )

this gives us::


bar
THIS ITEM NOT AVAILABLE
True
True

so it appears to work. note that we may have failed to
implement all the conceivable ways to test for
membership (such as searching through ``keys()``) or to
retrieve a value for a given key. more on that below.
now for the class to utilize this definition::

class X( object ):

def __init__( self ):
self.__dict__ = CustomDict( foo = 'bar' )

and the test code for that::

print ''
x = X()
print x.__dict__[ 'foo' ]
print x.__dict__[ 'bar' ]
print x.foo
print x.bar

which yields::


bar
THIS ITEM NOT AVAILABLE
bar

Traceback (most recent call last):
  File "C:\home\projects\__svn__\sundry\#.py", line 39, in ?
print x.bar
AttributeError: 'X' object has no attribute 'bar'

ok. so the custom dict *basically* works as expected,
since it does successfully make ``x.foo`` available --
no surprise here. unfortunately, looking up ``x.bar``,
which should really return the default value string,
causes an ``AttributeError`` to be raised.

now of course given the short definition of
``CustomDict``, perhaps there is an essential lookup
method that has not been overwritten but that is
internally used for attribute lookup. however, i
carefully tested my actual class (from the recipe
mentioned above) and also compared the methods defined
there against the standard ``dict()`` interface, and
nothing of importance appeared to be missing. i also
tried to bind the dictionary to the instance earlier, in
``__new__``, to no avail. am i missing something here?

_wolfgang

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

Creating a more random int?

[Steven Macintyre]

Hi all,

I need to retrieve an integer from within a range ... this works ... below
is my out puts ... it just does not seem so random ... 

Is there perhaps a suggestion out there to create a more random int ...?

>>> random.randint(3, 8)
7
>>> random.randint(3, 8)
3
>>> random.randint(3, 8)
3
>>> random.randint(3, 8)
4
>>> random.randint(3, 8)
3
>>> random.randint(3, 8)
4
>>> random.randint(3, 8)
7
>>> random.randint(3, 8)
7
>>> random.randint(3, 8)
7
>>> random.randint(3, 8)
5
>>> random.randint(3, 8)
6
>>> random.randint(3, 8)
3
>>> random.randint(3, 8)
8
>>> random.randint(3, 8)
8
>>> random.randint(3, 8)
5
>>> random.randint(3, 8)
3
>>> random.randint(3, 8)
4

Regards,


Steven

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

Re: Problem with running external process

[Donn Cave]

In article <[EMAIL PROTECTED]>,
 "ToMasz" <[EMAIL PROTECTED]> wrote:

> No, no, that wasn't my intention (I'm just not conscious enough what's
> going on with these fork, exec, spawn.. functions).
> My parent process should start the child process and go back to it's
> tasks. Before executing it for the next time the parent should check if
> the previous child process is done and start it again.
> 
> Is it what these lines do?
> 
> os.spawnlp(os.P_NOWAIT,'ext_script.py','')
> os.waitpid(-1, os.WNOHANG)

No, do you see them doing it?  "Check if the previous child
process is done?"

In your original post you said you were using os.P_WAIT,
but I suppose you really were using os.P_NOWAIT all along,
right?

This case may call for a working sample program that makes a
genuine attempt to do what you want to do.

   Donn Cave, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using non-ascii symbols

[Claudio Grondi]

Christoph Zwerschke wrote:
> Juho Schultz wrote:
> 
>> Fortran 90 allowed >, >= instead of .GT., .GE. of Fortran 77. But F90 
>> uses ! as comment symbol and therefore need /= instead of != for 
>> inequality. I guess just because they wanted. However, it is one more 
>> needless detail to remember. Same with the suggested operators.
> 
> 
> The point is that it is just *not* the same. The suggested operators are 
> universal symbols (unicode). Nobody would use ≠ as a comment sign. No 
> need to remember was it .NE. or -ne or <> or != or /= ...
> 
> There is also this old dispute of using "=" for both the assignment 
> operator and equality and how it can confuse newcomers and cause errors. 
>  A consequent use of unicode could solve this problem:
> 
Being involved in the discussion about assignment and looking for new 
terms which do not cause confusion when explaining what assignment does, 
this proposal seems to be a kind of solution:

> a ← b # Assignment (now "a = b" in Python, a := b in Pascal)
 ^-- this seems to me to be still open for further proposals and 
discussion. There is no symbol coming to my mind, but I would be glad if 
it would express, that 'a' becomes a reference to a Python object being 
currently referred by the identifier 'b' (maybe some kind of <-> ?).
> a = b # Eqality (now "a == b" in Python, a = b in Pascal)
> a ≡ b # Identity (now "a is b" in Python, @a = @b in Pascal)
> a ≈ b # Approximately equal (may be interesting for floats)
 ^-- this three seem to me to be obvious and don't need to be 
further discussed (only implemented as the time for such things will come).

Claudio
> 
> (I know this goes one step further as it is incompatible to the existing 
> use of the = sign in Python).
> 
> Another aspect: Supporting such symbols would also be in accord with 
> Python's trait of being "executable pseudo code."
> 
> -- Christoph
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Loading a Python collection from an text-file

[Larry Bates]

Take a look at ConfigParser module.  The format of the file would be
something like:

[members]
peter=16
anton=21

People are accustomed to this format file (windows .ini format).

-Larry


Ilias Lazaridis wrote:
> within a python script, I like to create a collection which I fill with
> values from an external text-file (user editable).
> 
> How is this accomplished the easiest way (if possible without the need
> of libraries which are not part of the standard distribution)?
> 
> something like:
> 
> text-file:
> {peter, 16},
> {anton, 21}
> 
> -
> 
> within code:
> 
> users.load(text-file.txt)
> 
> for user in users
>   user.name
>   user.age
> 
> .
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a 32 bit number to integer

[Dave Hansen]

On Tue, 24 Jan 2006 13:23:05 -0300 in comp.lang.python, Ricardo
Quesada <[EMAIL PROTECTED]> wrote:

>Hi,
>
>  In python 2.0, this number was an integer:
>0x88776655
>
>  but in python 2.4 it is a long (every number > 0x7fff it is a long)
>
>in python 2.4, is there a way to convert that number to a integer 
>(notice that it only occupies 32 bits) ?

Well, the sign bit's gonna be set no matter what.  But the following
might work for you...

>>> def short(x):
return int(0x8000 - x)


>>> x = short(0x88776655)
>>> x
-142042709
>>> "%x"%x
'-8776655'
>>> 

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a 32 bit number to integer

[Paul Rubin]

Ricardo Quesada <[EMAIL PROTECTED]> writes:
> 0x88776655
> 
>   but in python 2.4 it is a long (every number > 0x7fff it is a long)
> 
> in python 2.4, is there a way to convert that number to a integer
> (notice that it only occupies 32 bits) ?

It would be -2005440939 but that's maybe not what you want.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using non-ascii symbols

[Rocco Moretti]

Robert Kern wrote:
> Rocco Moretti wrote:
> 
> [James Stroud wrote:]
> 
>I can't find "?, ?, or ?" on my keyboard.
>>
>>Posting code to newsgroups might get harder too. :-)
> 
> 
> His post made it through fine. Your newsreader messed it up.

I'm not exactally sure what happened - I can see the three charachters 
just fine in your (Robert's) and the original (Christoph's) post. In 
Giovanni's post, they're rendered as question marks.

My point still stands: _somewere_ along the way the rendering got messed 
up for _some_ people - something that wouldn't have happened with the 
<=, >= and != digraphs.

(FWIW, my newsreader is Thunderbird 1.0.6.)
-- 
http://mail.python.org/mailman/listinfo/python-list

a 32 bit number to integer

[Ricardo Quesada]

Hi,

  In python 2.0, this number was an integer:
0x88776655

  but in python 2.4 it is a long (every number > 0x7fff it is a long)

in python 2.4, is there a way to convert that number to a integer 
(notice that it only occupies 32 bits) ?


thanks,
riq.

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

Re: Using non-ascii symbols

[Dave Hansen]

On Tue, 24 Jan 2006 04:09:00 +0100 in comp.lang.python, Christoph
Zwerschke <[EMAIL PROTECTED]> wrote:

[...]
>Once you open your mind for using non-ascii symbols, I'm sure one can 
>find a bunch of useful applications. Variable names could be allowed to 
>be non-ascii, as in XML. Think class names in Arabian... Or you could 
>use Greek letters if you run out of one-letter variable names, just as 
>Mathematicians do. Would this be desirable or rather a horror scenario? 

The latter, IMHO.  Especially variable names.  Consider i vs. ì vs. í
vs. î vs. ï vs. ...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using non-ascii symbols

[Dave Hansen]

On Tue, 24 Jan 2006 16:33:16 +0200 in comp.lang.python, Juho Schultz
<[EMAIL PROTECTED]> wrote:

[...]
>
>Fortran 90 allowed >, >= instead of .GT., .GE. of Fortran 77. But F90 
>uses ! as comment symbol and therefore need /= instead of != for 
>inequality. I guess just because they wanted. However, it is one more 
>needless detail to remember. Same with the suggested operators.

C uses ! as a unary logical "not" operator, so != for "not equal" just
seems to follow, um, logically.

Pascal used <>, which intuitively (to me, anyway ;-) read "less than
or greater than," i.e., "not equal."  Perl programmers might see a
spaceship.

Modula-2 used # for "not equal."  I guess that wouldn't work well in
Python...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using non-ascii symbols

[Christoph Zwerschke]

Juho Schultz wrote:
> Fortran 90 allowed >, >= instead of .GT., .GE. of Fortran 77. But F90 
> uses ! as comment symbol and therefore need /= instead of != for 
> inequality. I guess just because they wanted. However, it is one more 
> needless detail to remember. Same with the suggested operators.

The point is that it is just *not* the same. The suggested operators are 
universal symbols (unicode). Nobody would use ≠ as a comment sign. No 
need to remember was it .NE. or -ne or <> or != or /= ...

There is also this old dispute of using "=" for both the assignment 
operator and equality and how it can confuse newcomers and cause errors. 
  A consequent use of unicode could solve this problem:

a ← b # Assignment (now "a = b" in Python, a := b in Pascal)
a = b # Eqality (now "a == b" in Python, a = b in Pascal)
a ≡ b # Identity (now "a is b" in Python, @a = @b in Pascal)
a ≈ b # Approximately equal (may be interesting for floats)

(I know this goes one step further as it is incompatible to the existing 
use of the = sign in Python).

Another aspect: Supporting such symbols would also be in accord with 
Python's trait of being "executable pseudo code."

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

Re: file_name_fixer.py

[eww]

thanks for the feedback!

I'll work on your suggestions.


bruno at modulix wrote:
> [EMAIL PROTECTED] wrote:
> > i put this together to fix a bunch of files with wierd names, please
> > gimme feedback, i am a newbie
>
> Ok, so let's go... Hope you won't hate me too much !-)
>
> >
> > #!/usr/bin/env python
> > import os
> > import sys
> > import string
> > import platform
> > dir = sys.argv[1]
> This will shadow the builtin 'dir' function.
>
> > noworky = sys.argv[2]
>
> If the user fails to provide args, the program will crash with an
> IndexError - which may not be very helpful.
>
> Also, a better scheme would be
>   myprog [-opt1 [-opt2=val [-optN]]] arg1 arg2 argN
>
> Hint: the optparse module is your friend
> http://www.python.org/doc/2.4.2/lib/module-optparse.html
>
> > if platform.system() == 'Linux':
> > uglychars = ''.join( set(string.punctuation+' ') - set('/_.') )
> > else:
> > if platform.system() == 'Windows':#this is broken because windows
> > is gay with case
> > uglychars = ''.join( set(string.punctuation+' ') -
> > set(':\\/_.') )
> > else:
> > print "wtf... what platform is this anyway?"
>
> May be MacOS Classic, MacOS X or any *n*x or *BSD variant, or any other
> platform supporting Python - are there are some...
>
> > underscore = '_'
> > underscore = underscore * len(uglychars)
>
> You don't need the intermediate value:
>   underscores = '_' * len(uglychars)
>
> > chars = string.maketrans(uglychars, underscore)
>
> > print "# PHASE I, DIRECTORIES"
>
> Why not processing dirs and files in one pass ?
>
> > for path, subdirs, files in os.walk(dir, topdown=True):
>
> Err... is the 'dir' argument supposed to be an absolute path or a
> relative path ?
>
> And why using the topdown option ?
>
> > oldname = path
>
> woops ! this may be the absolute path. Are you sure you want to process
> an absolute path ?
>
> I think you'd better process files and dirs in one path, walking bottom
> up (so you don't process any file twice).
>
> > newname = oldname.translate(chars)
> > newname = string.lower(newname)
>
> Use the 'str' object methods instead of functions from the string module:
>
>  newname = newname.lower()
>
> You can also chain method/function calls:
>  newname = oldname.translate(chars).lower()
>
>
> > while string.count(newname, "__") > 0:
>
> in the context of a boolean expression, 0 evaluate to False, non-zero to
> True. So you don't have to be so explicit:
>   while newname.count('__'):
>
> > newname = string.replace(newname,"__","_")
>
> You don't need to actually *count* the occurrences of  '__' - if there's
> one, that's enough:
>  while '__' in newname:
>  # proceed
>
> Also, a regexp may be more effective here.
>
> > while string.count(newname, "..") > 0:
> > newname = string.replace(newname,"..",".")
>
> Don't forget the '..' and '.' special directories in unix filesystems...
>
> > if oldname != newname:
> > if os.path.isfile(newname) or os.path.isdir(newname):
>
> And if there's a special file (device etc) ?
> hint : os.path.exists()
>
>
> > print oldname, "-->\n", newname, "\t\t\tERROR: file/dir
> > exists\n"
>
> stdout is for 'normal' program outputs (ie: outputs that may be used as
> inputs to another program). This kind of output should go to stderr:
>print >> sys.stdout, "%s --> %s : \t\t\tERROR: "
> "file/dir exists" % (oldname,
>  newname,)
>
> > else:
> > print oldname, "-->\n", newname, "\t\t\tYAY: file
> > renamed\n"
> > if noworky == "doit":
> > os.renames(oldname, newname)
>
> How is the user supposed to know that he has to pass the string "doit"
> as a second arg ?
>
> There are some (more or less agreed upon) conventions about cli options.
> Like '--dry-run' to express the fact that the program shouldn't actually
> do more than simulate it's execution.
>
> > print "# PHASE II, FILES"
> > for path, subdirs, files in os.walk(dir, topdown=True):
> > for oldname in files:
> > oldname = os.path.join(path, oldname)
>
> Are you *sure* you want to operate on the *whole* *absolute* path ?
> (cf my thoughts about the "first phase" and the whole algorithm)
>
> > newname = oldname.translate(chars)
> > newname = string.lower(newname)
>
> Aren't you repeating some code here ?
> hint : all duplicated code should be factored out into a function.
>
> > newname = string.replace(newname,".mpeg",".mpg")
> > newname = string.replace(newname,".ram",".rm")
> > newname = string.replace(newname,".jpeg",".jpg")
> > newname = string.replace(newname,".qt",".mov")
>
> # outside the loop, define a dict like:
> ext_map = {'mpeg': 'mpg',
>'ram' : 'rm',
>'jpeg' : 'jpg',
># etc
>   }
>
> # then in the loop:
>   base, ext = os.path.split(n