date:20100114

Re: Code Generator written in python

2010-01-14 Thread Steve Ferg

http://nedbatchelder.com/code/cog/

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

Re: heapq._siftdown / decrease-key support?

2010-01-14 Thread Joshua Bronson

Thanks for the responses!

On Thu, Jan 14, 2010 at 12:23 AM, Daniel Stutzbach
 wrote:
> Your guess is correct.  Someday I'd like to rewrite HeapDict in C for speed, 
> but I haven't been able to find the time (and no one has offered to pay me to 
> make the time ;) ).

Daniel, did you realize you can accomplish logarithmic-time priority
change (albeit indirectly) with the built-in heapq module using this
mark-as-invalid trick? Are there other algorithms requiring decrease-
key besides A* and Dijkstra where this technique doesn't help?

On Thu, Jan 14, 2010 at 2:41 AM, Mikael Lind  wrote:
> If I recall correctly, avoiding the linear search did wonders for
> algorithm complexity.

It's still possible to perform the decrease-key operation without
having to do a linear search; heapdict does it in logarithmic time. If
my cursory benchmarks were accurate (which upon reconsideration I'm
not actually sure they are), I think the only explanation for it being
possibly slower is that it's running in pure Python.

I just switched back to using heapq but now with the mark-as-invalid
trick instead of the linear scan, and the performance I'm observing is
very close to heapdict's. Which is curious, because now that both
operations are running in logarithmic time, I'd expect the heapq
implementation to be much faster since it's written in C. Maybe I have
some confounding variables in how I'm running my tests.

By the way, I just realized that the obvious reason the heapq module
doesn't support priority change is that its functions are designed to
operate on external lists rather than providing an encapsulating data
structure like heapdict. With heapdict, logarithmic decrease_key is
possible because it's also storing the positions of the elements in an
underlying dictionary, so instead of a linear scan it does a constant-
time lookup. My guess is that the simplicity of having heapq operate
on external lists is preferable to supporting decrease-key directly,
so it isn't likely to change any time soon, especially since you can
accomplish the same thing with the mark-as-invalid technique.

Raymond, do you think this technique is worth documenting in the heapq
module? It'd be too bad if any future users incorrectly think that it
won't meet their needs the way I did.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Simple distributed example for learning purposes?

2010-01-14 Thread Tim Golden


On 13/01/2010 20:24, Aahz wrote:

In article,
Tim Golden  wrote:


I'm trying to come up with something which will illustrate the
usefulness of a distributed processing model. Since I may not be using
the term "distributed" exactly, my criteria are:


Distributed spider with firewall that limits network I/O per computer
(the firewall is useful but not essential).


Thanks; I'll add that to the list.

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

Re: Getting access to the process table from python?

2010-01-14 Thread Simon Brunning

2010/1/13 Roy Smith :
> I need to get information about what processes are running on a box.
> Right now, I'm interested in Solaris and Linux, but eventually
> probably other systems too.  I need to know things like the pid,
> command line, CPU time, when the process started running, and owner.
>
> Has anybody written a module to do this?  I know I can run ps and
> parse the output, or troll /proc directly, but if somebody's already
> written all that, I'd rather not reinvent the wheel.



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

Re: force URLencoding script

2010-01-14 Thread João

On Jan 12, 10:07 pm, r0g  wrote:
> João wrote:
> > On Jan 12, 8:05 pm, r0g  wrote:
> >> João wrote:
> >>> Someone please?
> >> Haven't seen your original post yet mate, usenet can be flaky like that,
> >> might have been a good idea to quote your original post!
>
> >> Roger.
>
> > Thanks Roger.
>
> >> João wrote:
> >>> Someone please?
> >>> Hi.
> >>> I'm trying to figure out how to force URLencoding in my Python 2.4.3
> >>> environment, receiving data as an input argument but I'm really at a loss
> >>> here.
>
> >>> What am I doing wrong?
> > headers =  {  ’User-Agent’  :  user_agent  }
>
> Those quotes need to be either " or ' i.e.
>
> headers =  {  'User-Agent'  :  user_agent  }
>
> If that doesn't sort it then it would be helpful to see a traceback or,
> if it is not crashing, get a description of how it is failing to do what
> you expect.
>
> Cheers,
>
> Roger.

Weird, I had the correct quotes in my script, maybe I've pasted with
some error.
This is my current script,

(and though I got it working with the subprocess.call I don't know how
to use a pure Python version.

for the following data,
authentication = "UID=somestring&"
message = 'PROBLEM severity High: OperatorX Plat1(locationY) global
Succ. : 94.47%'
dest_number = 'XXX'

url_values = urlencode({'M':message})
enc_data = authentication + url_values + dest_number


I'm getting null for
full_url = Request(url, enc_data, headers)

and thus,
response = urlopen(full_url).read()
returns,
TypeError: 

)

#!/usr/bin/env python
import sys
import os
import subprocess
from urllib import urlencode, urlopen
from urllib2 import Request

destination = sys.argv[1]
msg = sys.argv[2]

authentication = "UID=somestring&"
dest_number = "&N=%s" % destination

message = '%s' % msg
url_values = urlencode({'M':message})

enc_data = authentication + url_values + dest_number

url = 'http://10.112.28.221:38080/GwHTTPin/sendtext'

subprocess.call('echo "%s" | /usr/bin/POST -P "%s"' % (enc_data, url),
shell=True)
-- 
http://mail.python.org/mailman/listinfo/python-list

maintain 2 versions of python on my computer

2010-01-14 Thread luis


Hi

I am not an expert in programming and using Python for its simplicity

I have 2 versions of python installed on my computer (windos xp) to
begin the transition from version 2.4 to 2.6 or 3. maintaining the
operability of my old scripts

Is there any way to indicate the version of the python interpreter
must use a script?

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

Re: heapq._siftdown / decrease-key support?

2010-01-14 Thread Terry Reedy


On 1/14/2010 5:03 AM, Joshua Bronson wrote:

Thanks for the responses!

On Thu, Jan 14, 2010 at 12:23 AM, Daniel Stutzbach
  wrote:

Your guess is correct.  Someday I'd like to rewrite HeapDict in C for speed, 
but I haven't been able to find the time (and no one has offered to pay me to 
make the time ;) ).


Daniel, did you realize you can accomplish logarithmic-time priority
change (albeit indirectly) with the built-in heapq module using this
mark-as-invalid trick? Are there other algorithms requiring decrease-
key besides A* and Dijkstra where this technique doesn't help?

On Thu, Jan 14, 2010 at 2:41 AM, Mikael Lind  wrote:

If I recall correctly, avoiding the linear search did wonders for
algorithm complexity.


It's still possible to perform the decrease-key operation without
having to do a linear search; heapdict does it in logarithmic time. If
my cursory benchmarks were accurate (which upon reconsideration I'm
not actually sure they are), I think the only explanation for it being
possibly slower is that it's running in pure Python.

I just switched back to using heapq but now with the mark-as-invalid
trick instead of the linear scan, and the performance I'm observing is
very close to heapdict's. Which is curious, because now that both
operations are running in logarithmic time, I'd expect the heapq
implementation to be much faster since it's written in C. Maybe I have
some confounding variables in how I'm running my tests.

By the way, I just realized that the obvious reason the heapq module
doesn't support priority change is that its functions are designed to
operate on external lists rather than providing an encapsulating data
structure like heapdict. With heapdict, logarithmic decrease_key is
possible because it's also storing the positions of the elements in an
underlying dictionary, so instead of a linear scan it does a constant-
time lookup.


If the values in the queue are associated with 0 to n-1, as can be used 
for graph node identifiers , the positions can also be kept in an list, 
again with constant time lookup.



 My guess is that the simplicity of having heapq operate

on external lists is preferable to supporting decrease-key directly,
so it isn't likely to change any time soon, especially since you can
accomplish the same thing with the mark-as-invalid technique.

Raymond, do you think this technique is worth documenting in the heapq
module? It'd be too bad if any future users incorrectly think that it
won't meet their needs the way I did.



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

Re: maintain 2 versions of python on my computer

2010-01-14 Thread Alf P. Steinbach


* luis:

Hi

I am not an expert in programming and using Python for its simplicity

I have 2 versions of python installed on my computer (windos xp) to
begin the transition from version 2.4 to 2.6 or 3. maintaining the
operability of my old scripts

Is there any way to indicate the version of the python interpreter
must use a script?


I think the most direct way is to use different filename extensions, and 
associate them with corresponding interpreters via the 'assoc' and 'ftype' 
Windows commands.


An alternative is to associate '.py' and '.pyw' with two dummy programs (console 
and GUI subsystem programs) that in some way determines the Python version of 
the script and invokes the right interpreter.


Offhand I can think of three ways to let such a dummy program know the Python 
version of a script (filename extensions are not a way because with distinct 
filename extensions you don't need the dummy program):


  * version information in comment in the file.

  * version information in the filename, like e.g. 'myscript.python31.py',
or version information in the general path, e.g. 'python31\myscript.py'.

  * version information in some kind of 'database', which might be a
separate file or simply hardcoded in your dummy startup program.

But I think personally I'd go for filename extensions and using 'assoc' and 
'ftype', because while ugly it's simplest, like '.py24', '.py26', 'py31'.



Cheers & hth.,

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

Re: Code Generator written in python

2010-01-14 Thread trzewiczek


On 01/13/2010 05:09 PM, Arnaud Delobelle wrote:

nyoka  writes:

   

Can someone help me with sample python code for a code generator
 

Sure, here are some example of self-evaluating python objects, i.e. for each v
below,

v == eval(v)

I'm quite proud of the last one.

v = (lambda x:x%('"''""'+x+'"''""'))("""(lambda 
x:x%%('"''""'+x+'"''""'))(%s)""")

v = (lambda x:x%('r\"'+x+'\"'))(r"(lambda x:x%%('r\"'+x+'\"'))(%s)")

v = (lambda x:x%`x`)('(lambda x:x%%`x`)(%s)')

v = (lambda x: x+"("+`x`+")")('(lambda x: x+"("+`x`+")")')

v = "\"%s\" %% ((r\"%s\",)*2)" % ((r"\"%s\" %% ((r\"%s\",)*2)",)*2)

:)

   
If you're proud of the last one, consider moving to Perl. Python is - as 
I heard - about elegance and readability of code...

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

Re: maintain 2 versions of python on my computer

2010-01-14 Thread Gabriel Genellina


En Thu, 14 Jan 2010 08:21:28 -0300, luis  escribió:


I am not an expert in programming and using Python for its simplicity

I have 2 versions of python installed on my computer (windos xp) to
begin the transition from version 2.4 to 2.6 or 3. maintaining the
operability of my old scripts

Is there any way to indicate the version of the python interpreter
must use a script?


See http://www.effbot.org/zone/exemaker.htm
It uses the #! line to determine which version to load, resembling the  
Unix way.

(I've written a variant of the same idea but isn't ready yet)

Or, you can always invoke your scripts with an explicit interpreter.  
Create a python24.cmd file containing just this line:


@c:\path\to\python.exe %*

(and a similar one for 2.6 and 3.0) and put them somewhere in your path  
(it is convenient to add a single directory to the system PATH for your  
own utilities; I use c:\util; others use c:\bin).


Then you can say:

python26 foo.py

to execute foo.py using Python 2.6

--
Gabriel Genellina

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

Re: A simple-to-use sound file writer

2010-01-14 Thread Steve Holden

Alf P. Steinbach wrote:
> Just as a contribution, since someone hinted that I haven't really
> contributed much to the Python community.
> 
> The [simple_sound] code will probably go into my ch 3 at  http://tinyurl.com/programmingbookP3>, but sans sine wave generation
> since I haven't yet discussed trig functions, and maybe /with/ changes
> suggested by you?
> 
I wouldn't hold back on the sine wave just because it would represent a
"forward reference". That's OK sometimes. Why not just put a comment in
to the effect that "The sine wave is created using a function from the
math module, which we'll be looking at in ..."?

Since the sine is the basis for all other waveforms its omission would
seem more than a little strange to anyone knowledgeable about audio, for
example.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010  http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

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

Re: A simple-to-use sound file writer

2010-01-14 Thread Alf P. Steinbach

* Steve Holden:

Alf P. Steinbach wrote:

Just as a contribution, since someone hinted that I haven't really
contributed much to the Python community.

The [simple_sound] code will probably go into my ch 3 at http://tinyurl.com/programmingbookP3>, but sans sine wave generation
since I haven't yet discussed trig functions, and maybe /with/ changes
suggested by you?

I wouldn't hold back on the sine wave just because it would represent a
"forward reference". That's OK sometimes. Why not just put a comment in
to the effect that "The sine wave is created using a function from the
math module, which we'll be looking at in ..."?

Since the sine is the basis for all other waveforms its omission would
seem more than a little strange to anyone knowledgeable about audio, for
example.

I don't know very much if anything about audio. For example, in the code what I
called "sawtooth" wave is really "triangle" wave. The sawtooth is simpler, what
I called "linear" in the code.

And if you wonder, I was just checking the terminology now before starting to
write it up... Perhaps should have done that before posting code. But once I got
the idea of posting it I just posted it.

Anyway, as I recall any wave can be decomposed into sine waves, or square waves,
or almost whatever kind of waves. Think about a square wave of frequency f and
one of frequency 3f and perhaps third the amplitude (not sure), combined that's
already a good start on a sine wave. With some ugly staircasing but hey. And as
a matter of programming practicality, a triangle wave sounds almost like a sine
wave. It's just a little more edgy or "hairy", a slight buzz.

Cheers,

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

a problem with writing a generator

2010-01-14 Thread Paweł Banyś

Hello,

Please forgive me if I repeat the subject anyhow. I am trying to write a
simple program in Python which scans a config file in search for
"include" lines. If those lines are found, the files included there are
followed and scanned and if any further "include" lines are found, the
whole procedure repeats itself. The program ends when the whole tree
structure of those "includes" is generated.

I seem to have some blackout in my mind because I cannot understand how
to use a generator functionality to complete the task. If anybody has
already done such thing I would be very grateful for any guidance.

Regards,

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

Re: a problem with writing a generator

2010-01-14 Thread Alf P. Steinbach


* Paweł Banyś:

Hello,

Please forgive me if I repeat the subject anyhow. I am trying to write a
simple program in Python which scans a config file in search for
"include" lines. If those lines are found, the files included there are
followed and scanned and if any further "include" lines are found, the
whole procedure repeats itself. The program ends when the whole tree
structure of those "includes" is generated.

I seem to have some blackout in my mind because I cannot understand how
to use a generator functionality to complete the task. If anybody has
already done such thing I would be very grateful for any guidance.


Assuming that include directives are like

  #include "blahblah"

and further that config files do not contain stuff that's not valid as C 
preprocessor tokens, may I suggest to check whether your C or C++ compiler 
offers an option to show the include file hierarchy.


For example, with gcc or g++ use option '-H' (it has other options for 
generating makefiles!), or with Microsoft's Visual C++, '-showIncludes'. You'll 
also have to ask the compiler to only preprocess.


Disclaimer: I haven't used *nix, if that's your environment, since mid 1990's...



Cheers & hth.,

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

Re: a problem with writing a generator

2010-01-14 Thread Paweł Banyś

> Assuming that include directives are like
> 
>   #include "blahblah"

Yes, I have already tried the methods related to source code processing
using Python generators but unfortunately I am dealing with BIND and its
named.conf files.

Regards,

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

Re: a problem with writing a generator

2010-01-14 Thread Steven D'Aprano

On Thu, 14 Jan 2010 15:11:29 +0100, Paweł Banyś wrote:

> Hello,
> 
> Please forgive me if I repeat the subject anyhow. I am trying to write a
> simple program in Python which scans a config file in search for
> "include" lines. If those lines are found, the files included there are
> followed and scanned and if any further "include" lines are found, the
> whole procedure repeats itself. The program ends when the whole tree
> structure of those "includes" is generated.
> 
> I seem to have some blackout in my mind because I cannot understand how
> to use a generator functionality to complete the task. 

Do you have to use a generator? Just write the code in whatever way feels 
most comfortable to you. Generators aren't compulsory.

Anyway, here's an untested recursive generator solution that ignores 
everything but include lines, and yields the names of the files indented 
according to the depth of the structure.

def includes(filename, depth=0):
yield "%s%s" % ("  "*depth, filename)
f = open(filename, 'r')
for line in f:
if line.startswith('include '):
inc, fname = line.split(None, 1)
for line in includes(fname, depth=depth-1):
yield line
f.close()




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

Re: A simple-to-use sound file writer

2010-01-14 Thread Steve Holden

Alf P. Steinbach wrote:
> * Steve Holden:
>> Alf P. Steinbach wrote:
>>> Just as a contribution, since someone hinted that I haven't really
>>> contributed much to the Python community.
>>>
>>> The [simple_sound] code will probably go into my ch 3 at >> http://tinyurl.com/programmingbookP3>, but sans sine wave generation
>>> since I haven't yet discussed trig functions, and maybe /with/ changes
>>> suggested by you?
>>>
>> I wouldn't hold back on the sine wave just because it would represent a
>> "forward reference". That's OK sometimes. Why not just put a comment in
>> to the effect that "The sine wave is created using a function from the
>> math module, which we'll be looking at in ..."?
>>
>> Since the sine is the basis for all other waveforms its omission would
>> seem more than a little strange to anyone knowledgeable about audio, for
>> example.
> 
> I don't know very much if anything about audio. For example, in the code
> what I called "sawtooth" wave is really "triangle" wave. The sawtooth is
> simpler, what I called "linear" in the code.
> 
> And if you wonder, I was just checking the terminology now before
> starting to write it up... Perhaps should have done that before posting
> code. But once I got the idea of posting it I just posted it.
> 
> Anyway, as I recall any wave can be decomposed into sine waves, or
> square waves, or almost whatever kind of waves. Think about a square
> wave of frequency f and one of frequency 3f and perhaps third the
> amplitude (not sure), combined that's already a good start on a sine
> wave. With some ugly staircasing but hey. And as a matter of programming
> practicality, a triangle wave sounds almost like a sine wave. It's just
> a little more edgy or "hairy", a slight buzz.
> 
It's not clear to me that you can approximate any waveform with a
suitable combination of square waves, though I admit the idea has
intuitive appeal. But I know beyond a shadow of a doubt from my
education that any periodic function with a fundamental frequency f can
be approximated to whatever desired accuracy by the sum of sine and
cosine waves of frequencies Nf (N = 0, 1, 2, 3, ...) of appropriate
amplitudes (the frequency 0 component allows you to insert a "DC shift"
for waveforms that aren't symmetrical about zero). I seem to remember
the Fourier's theorem was the fundamental proof.

There is a very pretty discussion of all this, if you are mathematically
inclined, in

  http://press.princeton.edu/books/maor/chapter_15.pdf

with a specific example for the sawtooth waveform.

I would definitely recommend renaming the waveforms you *do* use to
conform with accepted terminology. This will reduce reader confusion.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010  http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

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

Re: a problem with writing a generator

2010-01-14 Thread Tim Chase


Paweł Banyś wrote:

Assuming that include directives are like

  #include "blahblah"


Yes, I have already tried the methods related to source code processing
using Python generators but unfortunately I am dealing with BIND and its
named.conf files.


(dealing with BIND named.conf files doesn't sound like homework, 
so I'll bite, though this might make a pretty good CS homework 
problem in the right context)


Sounds like a recursive generator could do the trick.  I'd also 
keep track of "files already recursed" to make sure you don't 
have infinite loops.  Something like this (untested):


  import re
  import os
  class ImportException(Exception): pass
  class RecursionException(Exception): pass
  include_re = re.compile(r'^\s*#include\s+"([^"]+"')
  def importer(fname, paths=None,seen=None):
if not paths: paths = [os.curdir]
if seen is None: seen = set()
f = file(fname)
for i, line in enumerate(f):
  m = include_re.match(line)
  if m: # this line is an "#include"
recurse_fname = m.group(1)
if recurse_fname in seen:
  raise RecursionException(
"[%s:%i] Recursion detected on [%s]" %
(fname, i, recurse_fname)
)
for pth in paths:
  full_path = os.path.join(pth, recurse_fname)
  if os.isfile(full_path):
seen.add(recurse_fname) # push
for line in importer(full_path, paths, seen):
  yield line
seen.remove(recurse_fname) # pop
break
else:
  raise ImportException("[%s:%i] could not find [%s]" %
(fname, i, recurse_fname))
  else: # not an include
yield line
f.close()

There might be some bugs lurking in there, and there might be 
some robustness aspects to consider (like using "with" for the 
file to make sure it gets closed, or wrapping it in a try/finally 
if you're using an older version of Python), and you might also 
consider allowing a certain depth of recursion (I'd use a dict of 
fname->recursion-depth to keep tabs on how deep I'd gotten, and 
raise an exception if I go too deep), but otherwise, that should 
give you a pretty straight-forward and easy-to-tweak starting point.


Hope this helps,

-tim


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

Re: A simple-to-use sound file writer

2010-01-14 Thread Alf P. Steinbach

* Steve Holden:

Alf P. Steinbach wrote:

* Steve Holden:

Alf P. Steinbach wrote:

Just as a contribution, since someone hinted that I haven't really
contributed much to the Python community.

Since the sine is the basis for all other waveforms its omission would
seem more than a little strange to anyone knowledgeable about audio, for
example.

I don't know very much if anything about audio. For example, in the code
what I called "sawtooth" wave is really "triangle" wave. The sawtooth is
simpler, what I called "linear" in the code.

And if you wonder, I was just checking the terminology now before
starting to write it up... Perhaps should have done that before posting
code. But once I got the idea of posting it I just posted it.

Anyway, as I recall any wave can be decomposed into sine waves, or
square waves, or almost whatever kind of waves. Think about a square
wave of frequency f and one of frequency 3f and perhaps third the
amplitude (not sure), combined that's already a good start on a sine
wave. With some ugly staircasing but hey. And as a matter of programming
practicality, a triangle wave sounds almost like a sine wave. It's just
a little more edgy or "hairy", a slight buzz.

It's not clear to me that you can approximate any waveform with a
suitable combination of square waves,

Oh. It's simple to prove. At least conceptually! :-)

Consider first that you need an infinite number of sine waves to create a
perfect square wave.

The opposite also holds: infinite number of square waves to create a perfect
sine wave (in a way sines and squares are opposites, the most incompatible).

With the goal of just a rough approximation you can go about it like this:

1. Divide a full cycle of the sine wave into n intervals. With
sine wave frequency f this corresponds to n*f sample rate for digital
representation.

2. Each interval will be approximated by a rectangular bar extending
up to or down to the sine wave. As it happens this (the bar's height) is
the sample value in a digital representation.

3. In the first half of the cycle, for each bar create that bar as
a square wave of frequency f, amplitude half the bar's height, and phase
starting at the bar's left, plus same square wave with negative sign
(inverted amplitude) and phase starting at the bar's right. And voilà,
not only this bar generated but also the corresponding other-way bar in
second half of cycle.

4. Sum all the square waves from step 3.

5. Let n go to infinity for utter perfectness! :-)

And likewise for any other waveform.

After all, it's the basis of digital representation of sound!

though I admit the idea has
intuitive appeal. But I know beyond a shadow of a doubt from my
education that any periodic function with a fundamental frequency f can
be approximated to whatever desired accuracy by the sum of sine and
cosine waves of frequencies Nf (N = 0, 1, 2, 3, ...) of appropriate
amplitudes (the frequency 0 component allows you to insert a "DC shift"
for waveforms that aren't symmetrical about zero). I seem to remember
the Fourier's theorem was the fundamental proof.

Yes, the good Fourier had a thing for roundish curves. He saw them everywhere
and in anything. Eventually he found an infinite number of them in, to others,
invisible /sound/.

There is a very pretty discussion of all this, if you are mathematically
inclined, in

http://press.princeton.edu/books/maor/chapter_15.pdf

with a specific example for the sawtooth waveform.

I would definitely recommend renaming the waveforms you *do* use to
conform with accepted terminology. This will reduce reader confusion.

Yes, thanks.

Cheers,

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

Re: a problem with writing a generator

2010-01-14 Thread Wolodja Wentland

On Thu, Jan 14, 2010 at 15:11 +0100, Paweł Banyś wrote:

> I seem to have some blackout in my mind because I cannot understand how
> to use a generator functionality to complete the task. If anybody has
> already done such thing I would be very grateful for any guidance.

I guess the following slides will help you a lot:

http://www.dabeaz.com/generators/

If you have further questions just ask and have fun playing with
generators in Python ...

-- 
  .''`. Wolodja Wentland 
 : :'  :
 `. `'` 4096R/CAF14EFC 
   `-   081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


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

Re: a problem with writing a generator

2010-01-14 Thread Dave Angel


PaweB Bany[ wrote:

Hello,

Please forgive me if I repeat the subject anyhow. I am trying to write a
simple program in Python which scans a config file in search for
"include" lines. If those lines are found, the files included there are
followed and scanned and if any further "include" lines are found, the
whole procedure repeats itself. The program ends when the whole tree
structure of those "includes" is generated.

I seem to have some blackout in my mind because I cannot understand how
to use a generator functionality to complete the task. If anybody has
already done such thing I would be very grateful for any guidance.

Regards,

Paweł

  
If you really want a tree structure, then I don't see why you expect a 
generator to be necessary, or helpful. A generator is frequently a good 
way tor reduce a tree to linear form, so if you were trying to make a 
single set of includes, I'd write a generator. Otherwise, you just need 
a recursive function.


Do you understand recursion? Have you any experience with it in other 
programming languages?


In this case, you write a single function that takes a filename as an 
argument, and returns a list of the includes contained within it. Then, 
inside that function, right after finding such an include, you call the 
same function, passing it the include name, and append the return value 
to your own list.


All the details of building the tree just work, if you get it right.

If you get stuck implementing this outline, then post whatever code you 
have so far, and give the reason why you're stuck. Also, at that point, 
define exactly what you expect the "tree" to look like. There are at 
least a few reasonable choices, and there's no point in heading the 
wrong way.


DaveA

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

Writing a string.ishex function

2010-01-14 Thread chandra

Folks,

I am new to Python and could not find a function along the lines of
string.ishex in Python. There is however, a string.hexdigits constant
in the string module. I thought I would enhance the existing modlue
but am unsure how I should go about it. Specifically, I have attempted
this much:
---cut---
#! /usr/bin/python
# -*- coding: utf-8 -*-

import string

def ishex(string):
ishex = False
for i in string:
if i in string.hexdigits:
ishex = True
else:
ishex = False
break
return ishex
---cut---

Can someone help me get further along please?

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

Re: Those two controversial 2nd & 3rd paragraphs of my ch 1

2010-01-14 Thread Lie Ryan

On 01/14/10 11:08, Alf P. Steinbach wrote:
> * Daniel Fetchinson:
>>
>> Nobody is deliberately trying to keep people from porting! I think you
>> misunderstand what is being said, these two statements are very
>> different: (1) single code base working on both python versions (2)
>> creating a second code from a code so that the second code works with
>> python 3 and the first one with python 2. Statement (2) is about
>> porting, statement (1) is about something else.
>>
>> Having said all that I actually seriously doubt (probably in agreement
>> with you) that Alf is able to write good and helpful material on the
>> relationship between python 2 and 3, porting, migrating, etc, based on
>> his emails :)
> 
> You're mostly absolutely right. :-)
> 
> I think it's OK to write things like "It's possible to travel to the
> moon" and "It's very difficult to travel to the moon", because those are
> just general observations  --  even though an astronaut may disagree
> with the latter stm.
> 
> But in order to write about the design of rockets, planning, economics,
> the physics of it, life support, etc., all the nitty gritty details
> about traveling to the moon so as to enable someone to do it, one needs
> to have done it.
> 
> And so far I haven't done that 2.x/3.x compatible code thing except for
> some very trivial stuff. It so happened that what I wrote in Oct 2009 or
> whenever it was, about "/", was verified just now by stumbling upon the
> "/" bug in [wave.py]. But that apparent detail was again just a general
> observation based on common sense and experience with similar
> differences in other languages, much like "you can expect problems if
> you have a big hole where your rocket's nose tip should be". To write
> about actual porting, version-compatible code, etc., so that it's useful
> to the reader would or will require far more. I'm probably not going to
> do that.
> 
> There are however some comments about 2.x/3.x differences, e.g. about
> "range" and "/", and I'm just now progressing into territory where I'll
> mention "long".
> 
> And I think that those comments constitute good and helpful material on
> the relationship between 2.x and 3.x?

The GNU Build System have succeeded in producing a program that can
write shell scripts (./configure) that works across any shell
implementation and any shell version on any OS (even on Windows with
Cygwin) generally without the need for manual tweaking.

It is common knowledge that a carefully written python scripts is easily
portable between different OS-es, and since there is only one "shell" to
support[1], why do you think this scenario is harder than what GNU Build
System developers were facing? They have shown that it is "possible" to
write a complex *and* portable shell script; why do you think it is
"impossible" to write a complex and portable python script?

Though keeping everything in one code base may often be difficult and
only of little practical benefit, it is not impossible. Modern version
control systems makes creating a fork not-so-difficult[2]; and
maintaining two or more codebase is much cheaper nowadays than they used
to be.


[1] we're ignoring other python implementations since they haven't
targeted 3.0; but anyway due to the much better defined standard,
alternative implementations doesn't pose much difference except for
occasional lack of the newest feature on many cases
[2] though not, by any definition, "easy"; but at least it's often
easier to fork than to keep things in one code base. Another, better,
alternative is to write a program that transform a human readable code
to portable code; which is what 2to3 is about.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a problem with writing a generator

2010-01-14 Thread Lie Ryan

On 01/15/10 01:49, Steven D'Aprano wrote:
> On Thu, 14 Jan 2010 15:11:29 +0100, Paweł Banyś wrote:
> 
>> Hello,
>>
>> Please forgive me if I repeat the subject anyhow. I am trying to write a
>> simple program in Python which scans a config file in search for
>> "include" lines. If those lines are found, the files included there are
>> followed and scanned and if any further "include" lines are found, the
>> whole procedure repeats itself. The program ends when the whole tree
>> structure of those "includes" is generated.
>>
>> I seem to have some blackout in my mind because I cannot understand how
>> to use a generator functionality to complete the task. 
> 
> Do you have to use a generator? Just write the code in whatever way feels 
> most comfortable to you. Generators aren't compulsory.
> 
> Anyway, here's an untested recursive generator solution that ignores 
> everything but include lines, and yields the names of the files indented 
> according to the depth of the structure.
> 
> def includes(filename, depth=0):
> yield "%s%s" % ("  "*depth, filename)
> f = open(filename, 'r')
> for line in f:
> if line.startswith('include '):
> inc, fname = line.split(None, 1)
> for line in includes(fname, depth=depth-1):
> yield line
> f.close()

that would always produce an empty file, no?

# another completely untested code; bugs may still be around
def includes(filename, depth=0):
yield "%s%s" % ("  "*depth, filename)
f = open(filename, 'r')
for line in f:
if line.startswith('include '):
inc, fname = line.split(None, 1)
for line in includes(fname, depth=depth+1):
yield line
else:
yield line
f.close()

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

Re: A simple-to-use sound file writer

2010-01-14 Thread Peter Otten

Alf P. Steinbach wrote:

> Just as a contribution, since someone hinted that I haven't really
> contributed much to the Python community.
> 
> The [simple_sound] code will probably go into my ch 3 at  http://tinyurl.com/programmingbookP3>, but sans sine wave generation since
> I haven't yet discussed trig functions, and maybe /with/ changes suggested
> by you?

> def _append_as_big_endian_int16_to( a, i ):
>  if i < 0:
>  i = i + 65536
>  assert( 0 <= i < 65536 )
>  a.append( i // 256 )
>  a.append( i % 256 )

>  data = array.array( "B" )   # B -> unsigned bytes.

Do you know that array.array() supports 16 bit signed integers? There's even 
a byteswap() method to deal with endianess.

> Utility class that may be used to capture output (an instance of this or
> any other file like class can be passed as "filename" to
> simple_sound.Writer):
> 
> 
> class BytesCollector:

Are you reinventing io.BytesIO() here?

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

Re: A simple-to-use sound file writer

2010-01-14 Thread Steve Holden

Alf P. Steinbach wrote:
> * Steve Holden:
[...]
> With the goal of just a rough approximation you can go about it like this:
> 
>   1. Divide a full cycle of the sine wave into n intervals. With
>  sine wave frequency f this corresponds to n*f sample rate for digital
>  representation.
> 
>   2. Each interval will be approximated by a rectangular bar extending
>  up to or down to the sine wave. As it happens this (the bar's
> height) is
>  the sample value in a digital representation.
> 
>   3. In the first half of the cycle, for each bar create that bar as
>  a square wave of frequency f, amplitude half the bar's height, and
> phase
>  starting at the bar's left, plus same square wave with negative sign
>  (inverted amplitude) and phase starting at the bar's right. And voilà,
>  not only this bar generated  but also the corresponding other-way
> bar in
>  second half of cycle.
> 
>   4. Sum all the square waves from step 3.
> 
>   5. Let n go to infinity for utter perfectness! :-)
> 
> And likewise for any other waveform.
> 
> After all, it's the basis of digital representation of sound!
> 
> 
I'm sorry, but this is merely hand-waving. It looks appealing, but
there's no rigor there.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010  http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

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

Re: A simple-to-use sound file writer

2010-01-14 Thread Mel

Alf P. Steinbach wrote:
> * Steve Holden:

>> It's not clear to me that you can approximate any waveform with a
>> suitable combination of square waves,
> 
> Oh. It's simple to prove. At least conceptually! :-)
> 
> Consider first that you need an infinite number of sine waves to create a
> perfect square wave.
> 
> The opposite also holds: infinite number of square waves to create a
> perfect sine wave (in a way sines and squares are opposites, the most
> incompatible).

No, it doesn't.  The infinite set of sine waves that make a square wave 
leave out the sine waves of frequency 2f, 4f, 6f, 8f, ... (2*n*f) ... .  
Once you've left them out, you can never get them back.  So sawtooth waves, 
for example, can't generally be built out of sets of square waves.

You can inject even harmonics up to a given limit by adding "rectangular 
waves" with given duty cycles, but the "given" part makes the math grubby.

Fourier transforms are cute to play with.  If you don't care about run-time 
there's:

#!/usr/bin/env python
# -*- coding: ASCII -*-
'''
$Id$'''
import math

def dft (sample):
'''Discrete Fourier Transform'''
n = len (sample)
n21 = n / 2 + 1
twopi = math.pi * 2.0
sin = math.sin
cos = math.cos
rex = [0]*n21
imx = [0]*n21
for k in xrange (n):
for i in xrange (n21):
a = twopi * k * i / n
rex[i] += sin(a) * sample[k]
imx[i] -= cos(a) * sample[k]
return rex, imx

#~ wave = [1]*32 + [-1]*32  # rectangular duty-cycle 1/2
#~ wave = [3]*16 + [-1]*48  # rectangular duty-cycle 1/4
wave = [7]*8 + [-1]*56  # rectangular duty-cycle 1/8
#~ wave = [15]*4 + [-1]*60  # rectangular duty-cycle 1/16
#~ wave = [31]*2 + [-1]*62  # rectangular duty-cycle 1/32
rex, imx = dft (wave)
print rex
print
print imx

The real coefficients show how the 8th, 16th, 24th, 32nd harmonics -- where 
the coefficients are near zero -- have dropped out of the waveform.

Mel.

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

Re: Those two controversial 2nd & 3rd paragraphs of my ch 1

2010-01-14 Thread Alf P. Steinbach


* Lie Ryan -> Alf P. Steinbach:

why do you think it is "impossible" to write a complex and portable
python script?


I don't. You're not quoting me.



Though keeping everything in one code base may often be difficult and
only of little practical benefit, it is not impossible. Modern version
control systems makes creating a fork not-so-difficult[2]; and
maintaining two or more codebase is much cheaper nowadays than they used
to be.


Huh.



[1] we're ignoring other python implementations since they haven't
targeted 3.0; but anyway due to the much better defined standard,
alternative implementations doesn't pose much difference except for
occasional lack of the newest feature on many cases
[2] though not, by any definition, "easy"; but at least it's often
easier to fork than to keep things in one code base. Another, better,
alternative is to write a program that transform a human readable code
to portable code; which is what 2to3 is about.


The upshot for 2.x/3.x compatible code base is to write in 2.x and convert 
automatically to 3.x, that is, to write the source code in *one* language.


That's because it's very hard to write code that works directly in both 
languages (or language versions, if you prefer).


The paragraph in the book is about why one, in practice, has to choose one 
version for one's source code, and why one shouldn't automatically think that 
what's learned about that version necessarily applies to the other version.



Cheers & hth.,

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

Re: A simple-to-use sound file writer

2010-01-14 Thread Alf P. Steinbach


* Mel:

Alf P. Steinbach wrote:

* Steve Holden:



It's not clear to me that you can approximate any waveform with a
suitable combination of square waves,

Oh. It's simple to prove. At least conceptually! :-)

Consider first that you need an infinite number of sine waves to create a
perfect square wave.

The opposite also holds: infinite number of square waves to create a
perfect sine wave (in a way sines and squares are opposites, the most
incompatible).


No, it doesn't.  The infinite set of sine waves that make a square wave 
leave out the sine waves of frequency 2f, 4f, 6f, 8f, ... (2*n*f) ... .  
Once you've left them out, you can never get them back.  So sawtooth waves, 
for example, can't generally be built out of sets of square waves.


The way to build a sine wave out of square waves is not a Fourier transform.

See the post you replied to for a simple procedure to build the sine wave.


Cheers & hth.,

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

1 2 >

1 - 100 of 131 matches

Mail list logo