Changing the system clock with pexpect confuses pexpect!

[Saqib Ali]

See my code below.

I'm controlling a shell logged in as root with pexpect.

The class below has a method (startProc) which spawns a shell and
keeps it alive until told to destroy it (stopProc).

The other 2 methods in this class allow me to change the system clock
and to get the IP Address of this machine.

They all work fine except when I advance the system clock, and
then try to get the IP Address.
In that case, I get an exception because pexpect incorrectly thinks
the output it is getting from ifconfig is invalid. But it is not.
Pexpect is just confused. This doesn't happen when I move the clock
backwards. It only happens when I move the clock forward.

I believe what is going on is that internally pexpect uses the system
clock to keep track of when it receives data from spawned processes.
When I mess with the clock, that messes up the internal workings of
pexpect.

Any suggestions what I should do? I have numerous concurrent pexpect
processes running when I modify the clock. Is there anyway to prevent
them all from getting totally screwed up??

-


#!/usr/bin/env python
import pexpect, os, time, datetime, re

def reportPrint(string):
print string

def reportAssert(condition, string)
if condition == False:
print string
raise Exception


class rootManager:

rootProc = None
rootPrompt = "] % "
myPrompt = "] % "

def __init__(self):
pass




def startProc(self):
if self.rootProc != None:
reportPrint("\t\t- Root Process is already created")
else:
self.rootProc = pexpect.spawn ('/bin/tcsh',)
i = self.rootProc.expect([pexpect.TIMEOUT,
self.myPrompt,])
reportAssert(i != 0, "Time-Out exiting")

reportPrint("\t\t- Sending su")
self.rootProc.sendline("su")
i = self.rootProc.expect([pexpect.TIMEOUT, "Password: ",])
reportAssert(i != 0, "Time-Out exiting")

reportPrint("\t\t- Sending Password")
self.rootProc.sendline(ROOT_PASSWORD)
i = self.rootProc.expect([pexpect.TIMEOUT,
self.rootPrompt,])
reportAssert(i != 0, "Time-Out exiting")

reportPrint("\t\t- Root Process created")


def getIPAddr(self):
reportAssert(self.rootProc != None, "No active Root Process!")

reportPrint("\t\t- Sending ifconfig -a")
self.rootProc.sendline("ifconfig -a")
i = self.rootProc.expect([pexpect.TIMEOUT, self.rootPrompt,])
reportAssert(i != 0, "Time-Out exiting")

outputTxt = self.rootProc.before
ipList = [i for i in re.compile("(?<=inet )\d{1,3}\.\d{1,3}\.
\d{1,3}\.\d{1,3}").findall(outputTxt) if i != "127.0.0.1"]
reportAssert(len(ipList) == 1, "Cannot determine IP Address
from 'ifconfig -a': \n%s" % outputTxt)
return ipList[0]


def changeClock(self, secondsDelta):
reportAssert(self.rootProc != None, "No active Root Process!")

newTime = datetime.datetime.now() +
datetime.timedelta(seconds=secondsDelta)
dateStr = "%02d%02d%02d%02d%s" % (newTime.month, newTime.day,
newTime.hour, newTime.minute, str(newTime.year)[-2:])
reportPrint("\t\t- Sending 'date %s' command" % dateStr)
self.rootProc.sendline("date %s" % dateStr)
#Remember, by changing the clock, you are confusing pexpect's
timeout measurement!
# so ignore timeouts in this case
i = self.rootProc.expect([pexpect.TIMEOUT,
self.rootPrompt,],)






def stopProc(self):
if self.rootProc == None:
reportPrint("\t\t- Root Process is already destroyed")
else:

reportPrint("\t\t- Sending exit command")
rootProc.sendline("exit")
i = rootProc.expect([pexpect.TIMEOUT, self.myPrompt])
reportAssert(i != 0, "Time-Out exiting")

reportPrint("\t\t- Sending exit command")
rootProc.sendline("exit")
i = rootProc.expect([pexpect.TIMEOUT, pexpect.EOF])
reportAssert(i != 0, "Time-Out exiting")
self.rootProc.close()
self.rootProc = None
reportPrint("\t\t- Root Process Destroyed")



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

Re: Python Openings

[vivek poddar]

Hi,

I have just completed my B.tech this year and have above six months
experience in OpenERP framework as a technical consultant.In these six
months I have completed nearly 5 modules and acted as an active
member.Now, my company is going under a financial crisis and so, I
think I have to leave this job.But I want to continue my career in
OpenERP or Python.

Thanks and Regards!
Vivek Poddar
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Plot seems weird

[Lie Ryan]

On 12/26/2011 05:27 AM, Yigit Turgut wrote:

On Dec 25, 7:06 pm, Rick Johnson  wrote:

On Dec 25, 9:33 am, Yigit Turgut  wrote:

Hi all,



I have a text file as following;



0.2000470.00
0.2000530.16
0.2000590.00
0.2000650.08
0.2000720.00
0.2000780.16



And I am trying to plot it with ;



filenames = sys.argv[1:]
if len(filenames) == 0:
 filenames = [sys.stdin]
for filename in filenames:
 t,y1 = numpy.genfromtxt(filename, unpack=True)
 pyplot.plot(t,y1)
 pyplot.show()



But graph seems weird, not as it supposed to be. Any ideas ?


Interesting. Of course "weird" leaves a LOT to be desired. On a scale
of 1-10, how "weird" is the result?


I apply a 1Khz test signal just to see if things run smoothly, but I
see spikes at lower and higher ends (logic 0,1) where I should see a
clean rectangle pwm signal. By the look of it I say weirdness is
around 3/10.


What are you expecting? Your data produces something that looks like the 
plot on the right of this screenshot 
(http://i44.tinypic.com/wwhlvp.jpg), I don't see anything weird with 
that; if you are expecting a square-wave-like plot (like on the left), 
then you should use a square-wave-like data, pyplot wouldn't magically 
transform a spiked-plot to squared-plot.


Here's what I use to convert the data on right plot to data on left 
plot, I don't know much about numpy so it might be possible to do it 
more efficiently or numpy might even have something like it already.


from itertools import izip_longest
def to_square(t, y1):
sq_data = [[], []]
for x,y, xn in izip_longest(data[0], data[1], data[0][1:]):
sq_data[0].append(x)
sq_data[1].append(y)
sq_data[0].append(xn)
sq_data[1].append(y)
return numpy.array(sq_data, dtype=float)

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

Re: Backslash Escapes

[Lie Ryan]

On 12/26/2011 12:04 PM, Felipe O wrote:

Hi all,
Whenever I take any input (raw_input, of course!) or I read from a
file, etc., any backslashes get escaped automatically.


Python never escapes backslashes when reading from raw_input or files. 
Python only ever escapes backslashes when displaying data on the 
interactive shell since the interactive shell uses __repr__ by default.



Is there any
elegant way of parsing the backslashes as though they were written in
a python string. The best I have so far right now goes like this:


You shouldn't ever need to unless your file are backslash-escaped.

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

Re: Test None for an object that does not implement ==

[Roy Smith]

In article ,
 Devin Jeanpierre  wrote:

> > Um -- if you don't want a and c being passed in, why put them in the
> > function signature?
> 
> He wants both or neither to be passed in.

assert sum(foo is None for foo in [a, c]) % 2 == 0
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Changing the system clock with pexpect confuses pexpect!

[Roy Smith]

In article 
<1f342621-0c96-447c-ad5d-f8c9dc777...@i6g2000vbe.googlegroups.com>,
 Saqib Ali  wrote:

> I believe what is going on is that internally pexpect uses the system
> clock to keep track of when it receives data from spawned processes.
> When I mess with the clock, that messes up the internal workings of
> pexpect.
> 
> Any suggestions what I should do?

Yeah.  Don't mess with the system clock.  Seriously.

There is pretty much no reason for anybody not to be running NTP these 
days.  Every OS ships with it, and there's gazillions of open NTP 
servers to use as references.

NTP will keep your system clock accurate to within a fraction of a 
second and avoid all the horrible problems such as the one you've 
discovered with pexpect when you reset your clock.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: installing matplotlib in MacOs 10.6.8.

[Ned Deily]

In article 
,
 Alex Ter-Sarkissov  wrote:
> hi everyone, I run python 2.7.2. in Eclipse (recently upgraded from 2.6). I
> have a problem with installing matplotlib (I found the version for python
> 2.7. MacOs 10.3, no later versions). If I run python in terminal using arch
> -i386 python, and then
> 
> from matplotlib.pylab import *
> 
> and similar stuff, everything works fine. If I run python in eclipse or
> just without arch -i386, I can import matplotlib as
> 
> from matplotlib import  *
> 
> but actually nothing gets imported. If I do it in the same way as above, I
> get the message
> 
> no matching architecture in universal wrapper
> 
> which means there's conflict of versions or something like that. I tried
> reinstalling the interpreter and adding matplotlib to forced built-ins, but
> nothing helped. For some reason I didn't have this problem with numpy and
> tkinter.

The message means almost certainly means that the Python you are using 
is a 64-bit/32-bit universal version.  When you launch Python with -arch 
i386, you force the Python to run in 32-bit mode so it is compatible 
with the 32-bit-only version of matplotlib you've installed in it.  When 
you launch Python by default, it is runnning in 64-bit mode so the 
32-bit-only C extension modules in that version of matplotlib cannot be 
loaded.  You might want to ask the matplotlib developers to make a 
64-bit version available.  In the mean time, you could try to configure 
Eclipse to invoke the python with `python2.7-32`, which is included with 
distributions like the python.org one to force Python to run in 32-bit 
mode on OS X.

-- 
 Ned Deily,
 n...@acm.org

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

Re: Python education survey

[Rick Johnson]

On Dec 25, 9:27 pm, Chris Angelico  wrote:
> On Mon, Dec 26, 2011 at 4:44 AM, Rick Johnson
> > [...]
> Conversely, why write an IDE into IDLE when perfectly-good IDEs
> already exist? I don't use IDLE for development per se; it's for
> interactive Python execution, but not editing of source files.

I believe the answer is two fold:

1. Including an IDE like IDLE into the Python distro helps noobs to
get started quickly without needing to traverse a gauntlet of unknown
IDEs on their own. If later they find something that they feel is more
appropriate; so be it.

2. (and most important to me... IDLE is written in Python using the
Tkinter GUI (which ships with python also). Therefore, the source code
for IDLE can be a GREAT teaching resource for how to write
professional Tkinter applications. I KNOW THE CURRENT SOURCE SUCKS!
However, we could change that.

So, with those points being covered, i believe IDLE is very important
to the Python community and could be useful to more people IF we clean
it up a bit. It's really a great little IDE with even greater
potential. If Guido would just say something (or at least some of the
top Pythionistas (Hettinger i am looking at you!)) this community
might work together to fix this problem.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Test None for an object that does not implement ==

[Paul Rudin]

GZ  writes:


> I run into a weird problem. I have a piece of code that looks like the
> following:
>
> f(, a=None, c=None):
> assert  (a==None)==(c==None)
>

There is only one 'None' - so use 'a is None' rather than 'a == None'.

(In common lisp there is a particular language construct that allows you
do determine whether an argument was passed in or was defaulted.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python education survey

[Nathan Rice]

On Mon, Dec 26, 2011 at 9:52 AM, Rick Johnson
 wrote:
> On Dec 25, 9:27 pm, Chris Angelico  wrote:
>> On Mon, Dec 26, 2011 at 4:44 AM, Rick Johnson
>> > [...]
>> Conversely, why write an IDE into IDLE when perfectly-good IDEs
>> already exist? I don't use IDLE for development per se; it's for
>> interactive Python execution, but not editing of source files.
>
> I believe the answer is two fold:
>
> 1. Including an IDE like IDLE into the Python distro helps noobs to
> get started quickly without needing to traverse a gauntlet of unknown
> IDEs on their own. If later they find something that they feel is more
> appropriate; so be it.
>
> 2. (and most important to me... IDLE is written in Python using the
> Tkinter GUI (which ships with python also). Therefore, the source code
> for IDLE can be a GREAT teaching resource for how to write
> professional Tkinter applications. I KNOW THE CURRENT SOURCE SUCKS!
> However, we could change that.
>
> So, with those points being covered, i believe IDLE is very important
> to the Python community and could be useful to more people IF we clean
> it up a bit. It's really a great little IDE with even greater
> potential. If Guido would just say something (or at least some of the
> top Pythionistas (Hettinger i am looking at you!)) this community
> might work together to fix this problem.

Not everyone who has Python installed wants to learn the language.  I
do think that a "learning" distro that has a lot of core tools
pre-installed, and ships with some tutorials, would be a decent idea.
Sort of like Enthought for new users :)  I don't feel IDLE is worth
salvaging though.

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

Re: Plot seems weird

[Yigit Turgut]

On Dec 26, 11:28 am, Lie Ryan  wrote:
> On 12/26/2011 05:27 AM, Yigit Turgut wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 25, 7:06 pm, Rick Johnson  wrote:
> >> On Dec 25, 9:33 am, Yigit Turgut  wrote:
> >>> Hi all,
>
> >>> I have a text file as following;
>
> >>> 0.200047        0.00
> >>> 0.200053        0.16
> >>> 0.200059        0.00
> >>> 0.200065        0.08
> >>> 0.200072        0.00
> >>> 0.200078        0.16
>
> >>> And I am trying to plot it with ;
>
> >>> filenames = sys.argv[1:]
> >>> if len(filenames) == 0:
> >>>      filenames = [sys.stdin]
> >>> for filename in filenames:
> >>>      t,y1 = numpy.genfromtxt(filename, unpack=True)
> >>>      pyplot.plot(t,y1)
> >>>      pyplot.show()
>
> >>> But graph seems weird, not as it supposed to be. Any ideas ?
>
> >> Interesting. Of course "weird" leaves a LOT to be desired. On a scale
> >> of 1-10, how "weird" is the result?
>
> > I apply a 1Khz test signal just to see if things run smoothly, but I
> > see spikes at lower and higher ends (logic 0,1) where I should see a
> > clean rectangle pwm signal. By the look of it I say weirdness is
> > around 3/10.
>
> What are you expecting? Your data produces something that looks like the
> plot on the right of this screenshot
> (http://i44.tinypic.com/wwhlvp.jpg), I don't see anything weird with
> that; if you are expecting a square-wave-like plot (like on the left),
> then you should use a square-wave-like data, pyplot wouldn't magically
> transform a spiked-plot to squared-plot.
>
> Here's what I use to convert the data on right plot to data on left
> plot, I don't know much about numpy so it might be possible to do it
> more efficiently or numpy might even have something like it already.
>
> from itertools import izip_longest
> def to_square(t, y1):
>      sq_data = [[], []]
>      for x,y, xn in izip_longest(data[0], data[1], data[0][1:]):
>          sq_data[0].append(x)
>          sq_data[1].append(y)
>          sq_data[0].append(xn)
>          sq_data[1].append(y)
>      return numpy.array(sq_data, dtype=float)

Thanks for the tip. I know that I feed a square wave signal and record
this data. Thus I believe the situation can be related to sampling
frequency.
Couldn't get your code working, maybe because I import the data from
file.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python education survey

[Rick Johnson]

On Dec 26, 10:11 am, Nathan Rice 
wrote:
> On Mon, Dec 26, 2011 at 9:52 AM, Rick Johnson
>
>
>
>
>
>
>
>
>
>  wrote:
> > On Dec 25, 9:27 pm, Chris Angelico  wrote:
> >> On Mon, Dec 26, 2011 at 4:44 AM, Rick Johnson
> >> > [...]
> >> Conversely, why write an IDE into IDLE when perfectly-good IDEs
> >> already exist? I don't use IDLE for development per se; it's for
> >> interactive Python execution, but not editing of source files.
>
> > I believe the answer is two fold:
>
> > 1. Including an IDE like IDLE into the Python distro helps noobs to
> > get started quickly without needing to traverse a gauntlet of unknown
> > IDEs on their own. If later they find something that they feel is more
> > appropriate; so be it.
>
> > 2. (and most important to me... IDLE is written in Python using the
> > Tkinter GUI (which ships with python also). Therefore, the source code
> > for IDLE can be a GREAT teaching resource for how to write
> > professional Tkinter applications. I KNOW THE CURRENT SOURCE SUCKS!
> > However, we could change that.
>
> > So, with those points being covered, i believe IDLE is very important
> > to the Python community and could be useful to more people IF we clean
> > it up a bit. It's really a great little IDE with even greater
> > potential. If Guido would just say something (or at least some of the
> > top Pythionistas (Hettinger i am looking at you!)) this community
> > might work together to fix this problem.
>
> Not everyone who has Python installed wants to learn the language.

I'll admit you make a very valid point. But since "they" are not
familiar with the language, what they don't know cannot hurt them.
Although i do see a need to keep the core distro small. If we remove
IDLE then we face the next big question... Should we remove Tkinter?

> I
> do think that a "learning" distro that has a lot of core tools
> pre-installed, and ships with some tutorials, would be a decent idea.
> Sort of like Enthought for new users :)

This is the kind of inventiveness i have been looking for in this
group. I think this is a great idea!

>  I don't feel IDLE is worth salvaging though.

Agreed. Not in it's current state anyway.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Test None for an object that does not implement ==

[Ethan Furman]

Devin Jeanpierre wrote:

Um -- if you don't want a and c being passed in, why put them in the
function signature?


He wants both or neither to be passed in.


Ah -- right.

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

Re: Python education survey

[Steven D'Aprano]

On Mon, 26 Dec 2011 06:52:03 -0800, Rick Johnson wrote:

> If Guido would just say something (or at least some of the top
> Pythionistas (Hettinger i am looking at you!)) this community might work
> together to fix this problem.

The sheer cluelessness displayed here about open source is painful.

If Guido would "just say something", this community would yawn. He's not 
the boss of us. Python development is an all-volunteer effort. "The 
community" works on projects that we find interesting, or that we need 
ourselves, not just because Guido "says something" about it -- and 
certainly not projects that you demand we work on.

Instead of demanding that GvR order us to work on IDLE, put your money 
where your mouth is, Rick, and stop being a blow-hard. You've been 
nagging us about IDLE for long enough -- what is it now, two years? 
Three? I haven't been counting, but it feels like geological ages.

Start a project to fix IDLE. There is plenty of free hosting on the 
Internet for open source projects, like GitHub and Google Code Hosting. 
Track some bugs. Plan some concrete enhancements. Write some actual code. 
Demonstrate actual effort, and you may attract others who care. 
Otherwise, you're wasting our time.


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

Re: Is my IDLE problem caused by .idlerc? Permissions.

[W. eWatson]

On 12/24/2011 11:35 AM, Dennis Lee Bieber wrote:

On Sat, 24 Dec 2011 10:55:48 -0800, "W. eWatson"
  wrote:



Permissions as follows:
SYSTEM: All. From Full control to write
Account Unknown(S-1-5-21...): read&exec, Read
Wayne: (normal use) All. From Full control to write
Admin: All. From Full control to write
WMPNetwork:  Read

Comments?

.idlerc permissions are slightly different for Account Unknown.


"Account Unknown" refers to a user account that has been deleted
(or, via some other system corruption, is no longer associated with a
login name -- happened to me earlier this year: my user account "name"
had been "Wulfraed" but the user account directory was under "Dennis Lee
Bieber"... When the registry crashed it disconnected name "Wulfraed"
from directory "Dennis Lee Bieber"... Lost a month of email once I got
done creating a new user account where directory and name matched and
restored from backup [I failed to back-up the old user directory before
trying a remove/create user]).

My suggestion would be, first, remove privileges for that remnant
account where-ever found; check higher directory levels too, and try to
propagate the privilege downwards.

Second -- could the file itself be set for read-only on the simple
properties? I just tested with Win7 -- setting the general "read-only"
did not make any changes to any of the security tab "users". Third,
confirm the owner of the file is your current user account; if not,see
if you can get "take ownership" option for the file to work.


I wonder if removing the "Account Unknown" account might just do it. Not 
quite familiar with Owner, but I'll look around.


I'll check the file for "read only".
--
http://mail.python.org/mailman/listinfo/python-list

Multithreading

[Yigit Turgut]

I have a loop as following ;

start = time.time()
end = time.time() - start
 while(endhttp://mail.python.org/mailman/listinfo/python-list

Re: Plot seems weird

[Lie Ryan]

On 12/27/2011 04:08 AM, Yigit Turgut wrote:

On Dec 26, 11:28 am, Lie Ryan  wrote:

On 12/26/2011 05:27 AM, Yigit Turgut wrote:










On Dec 25, 7:06 pm, Rick Johnsonwrote:

On Dec 25, 9:33 am, Yigit Turgutwrote:

Hi all,



I have a text file as following;



0.2000470.00
0.2000530.16
0.2000590.00
0.2000650.08
0.2000720.00
0.2000780.16



And I am trying to plot it with ;



filenames = sys.argv[1:]
if len(filenames) == 0:
  filenames = [sys.stdin]
for filename in filenames:
  t,y1 = numpy.genfromtxt(filename, unpack=True)
  pyplot.plot(t,y1)
  pyplot.show()



But graph seems weird, not as it supposed to be. Any ideas ?



Interesting. Of course "weird" leaves a LOT to be desired. On a scale
of 1-10, how "weird" is the result?



I apply a 1Khz test signal just to see if things run smoothly, but I
see spikes at lower and higher ends (logic 0,1) where I should see a
clean rectangle pwm signal. By the look of it I say weirdness is
around 3/10.


What are you expecting? Your data produces something that looks like the
plot on the right of this screenshot
(http://i44.tinypic.com/wwhlvp.jpg), I don't see anything weird with
that; if you are expecting a square-wave-like plot (like on the left),
then you should use a square-wave-like data, pyplot wouldn't magically
transform a spiked-plot to squared-plot.

Here's what I use to convert the data on right plot to data on left
plot, I don't know much about numpy so it might be possible to do it
more efficiently or numpy might even have something like it already.

from itertools import izip_longest
def to_square(t, y1):
  sq_data = [[], []]
  for x,y, xn in izip_longest(data[0], data[1], data[0][1:]):
  sq_data[0].append(x)
  sq_data[1].append(y)
  sq_data[0].append(xn)
  sq_data[1].append(y)
  return numpy.array(sq_data, dtype=float)


Thanks for the tip. I know that I feed a square wave signal and record
this data. Thus I believe the situation can be related to sampling
frequency.


It is due to sampling frequency, but also because you cannot sample a 
square wave perfectly because square wave has infinite steepness at the 
transitions. Although if you know the exact timing of the transitions, 
it may be possible to reconstruct the transitions perfectly.



Couldn't get your code working, maybe because I import the data from
file.


not your fault, I made a mistake when copy-pasteing the code, here's the 
fixed code:


from itertools import izip_longest
def to_square(data):
 sq_data = [[], []]
 for x,y, xn in izip_longest(data[0], data[1], data[0][1:]):
 sq_data[0].append(x)
 sq_data[1].append(y)
 sq_data[0].append(xn)
 sq_data[1].append(y)
 return numpy.array(sq_data, dtype=float)


use it like this:

t,y1 = to_square(numpy.genfromtxt(filename, unpack=True))
pyplot.plot(t,y1)
pyplot.show()

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

Re: Plot seems weird

[Yigit Turgut]

On Dec 26, 8:58 pm, Lie Ryan  wrote:
> On 12/27/2011 04:08 AM, Yigit Turgut wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 26, 11:28 am, Lie Ryan  wrote:
> >> On 12/26/2011 05:27 AM, Yigit Turgut wrote:
>
> >>> On Dec 25, 7:06 pm, Rick Johnson    wrote:
>  On Dec 25, 9:33 am, Yigit Turgut    wrote:
> > Hi all,
>
> > I have a text file as following;
>
> > 0.200047        0.00
> > 0.200053        0.16
> > 0.200059        0.00
> > 0.200065        0.08
> > 0.200072        0.00
> > 0.200078        0.16
>
> > And I am trying to plot it with ;
>
> > filenames = sys.argv[1:]
> > if len(filenames) == 0:
> >       filenames = [sys.stdin]
> > for filename in filenames:
> >       t,y1 = numpy.genfromtxt(filename, unpack=True)
> >       pyplot.plot(t,y1)
> >       pyplot.show()
>
> > But graph seems weird, not as it supposed to be. Any ideas ?
>
>  Interesting. Of course "weird" leaves a LOT to be desired. On a scale
>  of 1-10, how "weird" is the result?
>
> >>> I apply a 1Khz test signal just to see if things run smoothly, but I
> >>> see spikes at lower and higher ends (logic 0,1) where I should see a
> >>> clean rectangle pwm signal. By the look of it I say weirdness is
> >>> around 3/10.
>
> >> What are you expecting? Your data produces something that looks like the
> >> plot on the right of this screenshot
> >> (http://i44.tinypic.com/wwhlvp.jpg), I don't see anything weird with
> >> that; if you are expecting a square-wave-like plot (like on the left),
> >> then you should use a square-wave-like data, pyplot wouldn't magically
> >> transform a spiked-plot to squared-plot.
>
> >> Here's what I use to convert the data on right plot to data on left
> >> plot, I don't know much about numpy so it might be possible to do it
> >> more efficiently or numpy might even have something like it already.
>
> >> from itertools import izip_longest
> >> def to_square(t, y1):
> >>       sq_data = [[], []]
> >>       for x,y, xn in izip_longest(data[0], data[1], data[0][1:]):
> >>           sq_data[0].append(x)
> >>           sq_data[1].append(y)
> >>           sq_data[0].append(xn)
> >>           sq_data[1].append(y)
> >>       return numpy.array(sq_data, dtype=float)
>
> > Thanks for the tip. I know that I feed a square wave signal and record
> > this data. Thus I believe the situation can be related to sampling
> > frequency.
>
> It is due to sampling frequency, but also because you cannot sample a
> square wave perfectly because square wave has infinite steepness at the
> transitions. Although if you know the exact timing of the transitions,
> it may be possible to reconstruct the transitions perfectly.
>
> > Couldn't get your code working, maybe because I import the data from
> > file.
>
> not your fault, I made a mistake when copy-pasteing the code, here's the
> fixed code:
>
> from itertools import izip_longest
> def to_square(data):
>       sq_data = [[], []]
>       for x,y, xn in izip_longest(data[0], data[1], data[0][1:]):
>           sq_data[0].append(x)
>           sq_data[1].append(y)
>           sq_data[0].append(xn)
>           sq_data[1].append(y)
>       return numpy.array(sq_data, dtype=float)
>
> use it like this:
>
> t,y1 = to_square(numpy.genfromtxt(filename, unpack=True))
> pyplot.plot(t,y1)
> pyplot.show()

Significant improvement on the plot, pretty interesting. It runs ok
but I need to know how?! (:
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is my IDLE problem caused by .idlerc? Permissions.

[W. eWatson]

On 12/26/2011 10:16 AM, W. eWatson wrote:

On 12/24/2011 11:35 AM, Dennis Lee Bieber wrote:

On Sat, 24 Dec 2011 10:55:48 -0800, "W. eWatson"
 wrote:



Permissions as follows:
SYSTEM: All. From Full control to write
Account Unknown(S-1-5-21...): read&exec, Read
Wayne: (normal use) All. From Full control to write
Admin: All. From Full control to write
WMPNetwork: Read

Comments?

.idlerc permissions are slightly different for Account Unknown.


"Account Unknown" refers to a user account that has been deleted
(or, via some other system corruption, is no longer associated with a
login name -- happened to me earlier this year: my user account "name"
had been "Wulfraed" but the user account directory was under "Dennis Lee
Bieber"... When the registry crashed it disconnected name "Wulfraed"
from directory "Dennis Lee Bieber"... Lost a month of email once I got
done creating a new user account where directory and name matched and
restored from backup [I failed to back-up the old user directory before
trying a remove/create user]).

My suggestion would be, first, remove privileges for that remnant
account where-ever found; check higher directory levels too, and try to
propagate the privilege downwards.

Second -- could the file itself be set for read-only on the simple
properties? I just tested with Win7 -- setting the general "read-only"
did not make any changes to any of the security tab "users". Third,
confirm the owner of the file is your current user account; if not,see
if you can get "take ownership" option for the file to work.



I wonder if removing the "Account Unknown" account might just do it. Not
quite familiar with Owner, but I'll look around.

I'll check the file for "read only".
Solved. Moving .idlerc to another folder for safe keeping, and letting 
IDLE create a new .idlerc folder did it. I don't have the slightest idea 
why that worked, but the troublesome file was dated 2/2010, probably 
from installing 2.5.2, and never touched again by attempts either to 
re-install 2.5.2 or move up to 2.7.2.

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

Re: Python education survey

[Chris Angelico]

On Tue, Dec 27, 2011 at 5:32 AM, Rick Johnson
 wrote:
> Why has Guido not, at the very least, contacted me
> privately? He could remain anonymous.

And how would you know if he did contact you anonymously?

As to your demand that one of the "top Pythionistas" [sic] say
something? I declare hereby that I am, in fact, a top Pythonista. [1]

Rick, go fork Python onto Bitbucket. Call it Python 4000 if you like,
or just "Python with a better IDLE" or whatever. Go! Shoo! Code!

There. A top Pythonista has spoken. And if the above satisfy you not,
I actually said it out loud too, just to be sure. That's how important
you are to The Python Community (capital letters and all).

ChrisA


[1] Start here and follow the thread. I've done all of them. (Actually
I probably haven't, and I haven't even read the whole thread, which
just came up when I googled 'pythonista', but I defy you to prove me
lying.) http://mail.python.org/pipermail/python-list/2003-June/207114.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multithreading

[Ian Kelly]

On Mon, Dec 26, 2011 at 11:31 AM, Yigit Turgut  wrote:
> I have a loop as following ;
>
> start = time.time()
> end = time.time() - start
>  while(end          data1 = self.chan1.getWaveform()
>          end = time.time() - start
>          timer.tick(10)  #FPS
>          screen.fill((255,255,255) if white else(0,0,0))
>          white = not white
>          pygame.display.update()
>          for i in range(self.size):
>              end = time.time() - start
>              f.write("%3.8f\t%f\n"%(end,data1[i]))
>
> Roughly speaking, this loop displays something at 10 frames per second
> and writes data1 to a file with timestamps.
>
> At first loop data1 is grabbed but to grab the second value (second
> loop) it needs to wait for timer.tick to complete. When I change FPS
> value [timer.tick()], capturing period (time interval between loops)
> of data1 also changes. What I need is to run ;
>
>          timer.tick(10)  #FPS
>          screen.fill((255,255,255) if white else(0,0,0))
>          white = not white
>          pygame.display.update()
>
> for N seconds but this shouldn't effect the interval between loops
> thus I will be able to continuously grab data while displaying
> something at X fps.
>
> What would be an effective workaround for this situation ?

You essentially have two completely independent loops that need to run
simultaneously with different timings.  Sounds like a good case for
multiple threads (or processes if you prefer, but these aren:

def write_data(self, f, N):
start = time.time()
while self.has_more_data():
data1 = self.chan1.getWaveform()
time.sleep(N)
for i in range(self.size):
end = time.time() - start
f.write("%3.8f\t%f\n" % (end, data[i]))

def write_data_with_display(self, f, N, X):
thread = threading.Thread(target=self.write_data, args=(f, N))
thread.start()
white = False
while thread.is_alive():
timer.tick(X)
screen.fill((255, 255, 255) if white else (0, 0, 0))
white = not white
pygame.display.update()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multithreading

[Ian Kelly]

On Mon, Dec 26, 2011 at 1:01 PM, Ian Kelly  wrote:
> You essentially have two completely independent loops that need to run
> simultaneously with different timings.  Sounds like a good case for
> multiple threads (or processes if you prefer, but these aren:

I accidentally sent before I was finished.  I was saying "or processes
if you prefer, but these aren't CPU-bound, so why complicate things?"

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

Re: Multithreading

[Yigit Turgut]

On Dec 26, 10:03 pm, Ian Kelly  wrote:
> On Mon, Dec 26, 2011 at 1:01 PM, Ian Kelly  wrote:
> > You essentially have two completely independent loops that need to run
> > simultaneously with different timings.  Sounds like a good case for
> > multiple threads (or processes if you prefer, but these aren:
>
> I accidentally sent before I was finished.  I was saying "or processes
> if you prefer, but these aren't CPU-bound, so why complicate things?"
>
> Cheers,
> Ian

I had thought the same workaround but unfortunately loop is already
under a def ;

def writeWaveform(self, fo, header=''):
data1 = numpy.zeros(self.size)
screen = pygame.display.set_mode((0, 0), pygame.FULLSCREEN)
timer = pygame.time.Clock()
white = True
fo.write(header)
start = time.time()
end = time.time() - start
while(end<10):
  data1 = self.chan1.getWaveform()
  end = time.time() - start
  timer.tick(10) #FPS
  screen.fill((255,255,255) if white else(0,0,0))
  white = not white
  pygame.display.update()
  for i in range(self.size):
  end = time.time() - start
  f.write("%3.8f\t%f\n"%(end,data1[i]))
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multithreading

[Ian Kelly]

On Mon, Dec 26, 2011 at 1:13 PM, Yigit Turgut  wrote:
> I had thought the same workaround but unfortunately loop is already
> under a def ;

So nest the functions, or refactor it.  Either way, that shouldn't be
a significant obstacle.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 25, 5:15 pm, Steven D'Aprano  wrote:
> On Sun, 25 Dec 2011 06:55:28 -0800, Eelco wrote:
> > Anyway,  braces are used at
> > least an order of magnitude more than collection packing/ unpacking in
> > typical code.
>
> That's a wild and unjustified claim. Here's a quick and dirty test, using
> the standard library as an example of typical idiomatic code:
>
> [steve@orac ~]$ cd /usr/lib/python2.6
> [steve@orac python2.6]$ grep "[*]args" *.py | wc -l
> 270
> [steve@orac python2.6]$ grep "{" *.py | wc -l
> 550
>
> Doesn't look like a factor of 10 difference to me.

Now try it without changing the subject from round braces to
everything but round braces.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 25, 5:23 pm, Chris Angelico  wrote:
> On Mon, Dec 26, 2011 at 2:38 AM, Eelco  wrote:
> > Until that time, im going
> > to ask you to take 'type constraint' by its literal meaning; a
> > coercion of the type of a symbol, rather than whatever particular
> > meaning it has acquired for you (it might help if you explained that).
> > Im not sure if it was you that brought that up, but let me reiterate
> > that I dont mean a 'type cast', which is a runtime concept. A 'type
> > constraint' is purely a linguistic construct that will be 'compiled
> > out')
>
> The dictionary definition of constraint is "a limitation or
> restriction", and you're right that it can be "compiled out". In fact,
> that is probably the best definition. Assuming everything is written
> correctly, you should be able to eliminate all constraints and the
> code will still function correctly*; but having the constrains means
> that certain illegal operations will throw errors.
>
> Here's two examples of tuple unpacking, one with a type constraint,
> the other without:
>
> a, b = ('hello', [1,2,3] )
> a, b::list = ('hello', [1,2,3] )
>
> The constraint on the second line means that, if the second element is
> not a list, the interpreter should throw an error. It does NOT mean to
> completely change the meaning of the statement to _make_ the last
> argument into a list. That is not the job of a constraint.

Thank you for providing clarification on what a 'type constraint'
means to you. That clears things up a bit.

What you are talking about goes by the name of a 'dynamic type CHECK';
some kind of syntactic sugar for something like
'assert(type(obj)==sometype)'. Like a 'type cast', this is also a
runtime concept. How you manage to confuse that with what I am talking
about, given that ive stated many times I am not talking about a
runtime construct but a compile-time construct, is quite beyond me.
(not to mention that ive quite explicitly stated what I mean by 'type
constraint' many times now).

By contrast, here is the first google hit for 'type constraint'.

http://msdn.microsoft.com/en-us/library/d5x73970.aspx

Note that this is a different application of the concept of a type
constraint, but nonetheless,  the concept is as I stated it: a
constraint to the type of a symbol to modify its compile-time
semantics. To cite from its first paragraph:

"...you can apply restrictions to the kinds of types ... by using a
type that is not allowed by a constraint, the result is a COMPILE-TIME
ERROR" (emphasis mine)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Chris Angelico]

On Tue, Dec 27, 2011 at 7:39 AM, Eelco  wrote:
> Now try it without changing the subject from round braces to
> everything but round braces.

Around here, the term "braces" means the curly ones - { and } - that
delimit blocks of code in C, and dictionaries/sets in Python.
"Brackets" may be what you're looking for, if you mean all of ()[]{}.
Or if you just mean (), they're called "parentheses".

If your point is that parens are used more often than
packing/unpacking, that's almost certainly true, since function calls
(including method invocations) are so prevalent in pretty much any
code. But what does that prove?

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

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Chris Angelico]

On Tue, Dec 27, 2011 at 7:58 AM, Eelco  wrote:
> What you are talking about goes by the name of a 'dynamic type CHECK';
> some kind of syntactic sugar for something like
> 'assert(type(obj)==sometype)'. Like a 'type cast', this is also a
> runtime concept...
>
> By contrast, here is the first google hit for 'type constraint'.
>
> http://msdn.microsoft.com/en-us/library/d5x73970.aspx
>
> "...you can apply restrictions to the kinds of types ... by using a
> type that is not allowed by a constraint, the result is a COMPILE-TIME
> ERROR" (emphasis mine)

A constraint can be applied at compile time or at run time. It'd be
valid to apply them at edit time, if you so chose - your editor could
refuse to save your file until you fix the problem. Doesn't mean a
thing. Python, by its nature, cannot do compile-time type checking.
Under no circumstances, however, does this justify the use of the term
"constraint" to mean "utterly different semantics of the same code".

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

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 25, 6:05 pm, Steven D'Aprano  wrote:
> On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:
> > On Dec 25, 2:12 pm, Steven D'Aprano  > +comp.lang.pyt...@pearwood.info> wrote:
> >> On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:
> >> > On Dec 20, 4:30 am, alex23  wrote:
> >> >> On Dec 19, 8:15 pm, Eelco  wrote:
>
> >> >> > What does that have to do with collection packing/unpacking?
>
> >> >> It's mocking your insistance that collection unpacking is a type
> >> >> constraint.
>
> >> > This is really going to be the last time I waste any words on this:
>
> >> If only that were true, but after sending this post, you immediately
> >> followed up with FIVE more posts on this subject in less than half an
> >> hour.
>
> > Did I waste any more words on collection packing and type constraints?
> > No, I did not. (though I am about to, and am willing to do so for every
> > question that seems genuinely aimed at engaging me on the matter)
>
> > Did I intend to say that I was going to let a single troll shut down my
> > entire topic? No, I did not.
>
> Ah, well whatever you *intended* wasn't clear from your comment. At least
> not clear to *me*.

Always glad to help.

> > Yes, indeed it would be abuse of language to call this a type
> > constraint, since the fact that y is a list is indeed an outcome of
> > whatever happens to pop out at the right hand side. One could redefine
> > the identifier list to return any kind of object.
>
> So far, we agree on this.

Good.

> > How is 'head, *tail = sequence' or semantically entirely equivalently,
> > 'head, tail::list = sequence' any different then? Of course after
> > interpretation/compilation, what it boils down to is that we are
> > constructing a list and binding it to the identifier tail, but that is
> > not how it is formulated in python as a language
>
> I'm afraid it is.
>
> Here's the definition of assignment in Python 
> 3:http://docs.python.org/py3k/reference/simple_stmts.html#assignment-
> statements

Que?

'head, *tail = sequence'

Is how one currently unpacks a head and tail in idiomatic python

This is semantically equivalent to

'head = sequence[0]'
'tail = list(sequence[1:])'

But these forms are linguistically different, in too many different
ways to mention.

> > We dont have
> > something of the form 'tail = list_tail(sequence)'.
>
> I'm afraid we do. See the definition of assignment again.

Que?

My claim is that the two semantically identical formulations above do
not have isomorphic linguistic form. As far as I can make sense of
your words, you seem to be disputing this claim, but its a claim as
much worth debating as that the sun rises in the east.

> > Rather, we annotate
> > the identifier 'tail' with an attribute that unquestionably destinates
> > it to become a list*. It is no longer that 'tail' will just take
> > anything that pops out of the expression on the right hand side;
>
> Of course it will. Python is a dynamically typed language. It doesn't
> suddenly develop static types to ensure that 'tail' becomes a list;
> 'tail' is bound to a list because that's what the assignment statement
> provides.

How python accomplishes any of this under the hood is entirely
immaterial. The form is that of a compile-time type constraint,
regardless of whether the BDFL ever thought about it in these terms.

> > rather,
> > the semantics of what will go on at right hand side is coerced by the
> > constraint placed on 'tail'.
>
> But it isn't a constraint placed on 'tail'. It is a consequence of the
> definition of assignment in Python 3. 'tail' becomes bound to a list
> because that is what the assignment statement is defined to do in that
> circumstance, not because the identifier (symbol) 'tail' is constrained
> to only accept lists. 'tail' may not even exist before hand, so talking
> about constraints on 'tail' is an abuse of language, AS YOU AGREED ABOVE.

'tail' is (re)declared on the spot as a brand-new identifier (type
constraint included); whether it exists before has no significance
whatsoever, since python allows rebinding of identifiers.

> > *(I call that a 'type constraint', because that is what it literally is;
>
> No. It is literally a name binding of a dynamically typed, unconstrained
> name to an object which happens to be a list.

Let me take a step back and reflect on the form of the argument we are
having. I claim the object in front of us is a 'cube'. You deny this
claim, by countering that it is 'just a particular configuration of
atoms'.

'look at the definition!', you say; 'its just a list of coordinates,
no mention of cubes whatsoever.'.

'Look at the definition of a cube', I counter. 'This particular list
of coordinates happens to fit the definition, whether the BDFT
intended to or not'.

You are correct, in the sense that I do not disagree that it is a
particular configuration of atoms. But if you had a better
understanding of cubes, youd realize it meets the definition; the fact
that people might not make a habit of pausing a

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 26, 10:01 pm, Chris Angelico  wrote:
> On Tue, Dec 27, 2011 at 7:39 AM, Eelco  wrote:
> > Now try it without changing the subject from round braces to
> > everything but round braces.
>
> Around here, the term "braces" means the curly ones - { and } - that
> delimit blocks of code in C, and dictionaries/sets in Python.
> "Brackets" may be what you're looking for, if you mean all of ()[]{}.
> Or if you just mean (), they're called "parentheses".
>
> If your point is that parens are used more often than
> packing/unpacking, that's almost certainly true, since function calls
> (including method invocations) are so prevalent in pretty much any
> code. But what does that prove?

That proves the original point of contention: that the below* is
suboptimal language design, not because terseness always trumps
verbosity, but because commonly-used constructs (such as parenthesis
or round brackets or whatever you wish to call them) are more
deserving of the limited space in both the ascii table and your
reflexive memory, than uncommonly used ones.


*original mock code by steve:

class MyClass superclasslist A, B C:
def method argumentlist self, x, y:
t = tuple 1, 2 tuple 3, 4 endtuple endtuple
return group x + y endgroup * group x - y endgroup
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 26, 10:05 pm, Chris Angelico  wrote:
> On Tue, Dec 27, 2011 at 7:58 AM, Eelco  wrote:
> > What you are talking about goes by the name of a 'dynamic type CHECK';
> > some kind of syntactic sugar for something like
> > 'assert(type(obj)==sometype)'. Like a 'type cast', this is also a
> > runtime concept...
>
> > By contrast, here is the first google hit for 'type constraint'.
>
> >http://msdn.microsoft.com/en-us/library/d5x73970.aspx
>
> > "...you can apply restrictions to the kinds of types ... by using a
> > type that is not allowed by a constraint, the result is a COMPILE-TIME
> > ERROR" (emphasis mine)
>
> A constraint can be applied at compile time or at run time. It'd be
> valid to apply them at edit time, if you so chose - your editor could
> refuse to save your file until you fix the problem. Doesn't mean a
> thing.

A constraint in the sense that I have explained many times now, can in
no way, shape or form be applied at run time. Youd have better luck
applying a consternation to a squirrel. Perhaps you meant 'type check'
again? But then again, that makes no sense whatsoever at compile-
time... Im starting to doubt if there is any sense to be found here at
all.

Anyway, ill take your further silence on the matter as a 'sorry I
derailed your thread with my confusion of terminology'

> Python, by its nature, cannot do compile-time type checking.

Python can do whatever its designers have put into it. In this case,
that includes the emission of different code based on a (type)
annotation at the point of declaration of an identifier (only in the
particular circumstance of collection unpacking though, as far as I am
aware).

> Under no circumstances, however, does this justify the use of the term
> "constraint" to mean "utterly different semantics of the same code".

Thank you for your theory on justice. Im sure its fascinating, but
until you get around to actually explaining it, im going to have to be
conservative and stick with the jargon in common use though, sorry.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Chris Angelico]

On Tue, Dec 27, 2011 at 8:51 AM, Eelco  wrote:
> That proves the original point of contention: that [Steve's demo code] is
> suboptimal language design, not because terseness always trumps
> verbosity, but because commonly-used constructs (such as parenthesis
> or round brackets or whatever you wish to call them) are more
> deserving of the limited space in both the ascii table and your
> reflexive memory, than uncommonly used ones.

In Magic: The Gathering R&D, they have a term (the article reporting
which I can't actually find at the moment) called "spread complexity"
or "fan complexity" - the idea being that as you fan out a booster
pack, you see a certain amount of complexity in front of you. The
designers can afford to put more complex cards in as rares than they
can as commons, because you see ten commons for every rare - so a
common factors ten times as much as a rare in spread complexity. (Mark
Rosewater, my apologies if I'm misremembering here!)

The same applies here. When you cast your eye over a program, you're
going to see certain syntactic elements a lot. Assignment, arithmetic,
blocks of code (ie indent/dedent), and function calls are all
extremely common; lambdas, the use of decorators, and exception
handling are somewhat uncommon; and metaclasses, the writing of
decorators, and reloading of modules are all quite rare.

The elements that occur frequently should be:
a) Readable and grokkable;
b) Easily typed on a regular keyboard - no using ASCII character 126
to mean negation, tyvm!
c) Make sense.

Rarer elements (and I'm not talking about xenon and plutonium here)
are allowed to have long names, obscure syntax, or even be shoved away
in odd modules (the way module reloading is in Python 3). If 0.1% of
your code is suddenly twice as large as it used to be, will you
notice? But if a new syntax adds even 5% to the mindspace requirement
of basic assignment, your code will majorly suffer.

In summary: Terseness trumps verbosity primarily for common
operations, and only when doing so does not violate rules a and c
above.

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

Possible bug in string handling (with kludgy work-around)

[Charles Hixson]

This doesn't cause a crash, but rather incorrect results.

self.wordList=["The", "quick", "brown", "fox", "carefully",
"jumps", "over", "the", "lazy", "dog", "as", "it",
"stealthily", "wends", "its", "way", "homewards", '\b.']
foriinrange (len (self.wordList) ):
   ifnot isinstance(self.wordList[i], str):
   self.wordList = ""
  elif self.wordList[i] != "" and self.wordList[i][0] == "\b":
   print ("0: wordList[", i, "] = \"", self.wordList[i], "\"", sep 
= "")
   print ("0a: wordList[", i, "][1] = \"", self.wordList[i][1], 
"\"", sep = "")
   tmp=self.wordList[i][1] ## !! Kludge -- 
remove tmp to see the error
   self.wordList[i]=tmp + self.wordList[i][1:-1]  ## !! 
Kludge -- remove tmp + to see the error
   print ("1: wordList[", i, "] = \"", self.wordList[i], "\"", sep 
= "")

   print("len(wordList[", i, "]) = ", len(self.wordList[i]) )

--
Charles Hixson

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

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Chris Angelico]

On Tue, Dec 27, 2011 at 9:12 AM, Eelco  wrote:
> On Dec 26, 10:05 pm, Chris Angelico  wrote:
>> A constraint can be applied at compile time or at run time. It'd be
>> valid to apply them at edit time, if you so chose - your editor could
>> refuse to save your file until you fix the problem. Doesn't mean a
>> thing.
>
> A constraint in the sense that I have explained many times now, can in
> no way, shape or form be applied at run time. Youd have better luck
> applying a consternation to a squirrel. Perhaps you meant 'type check'
> again? But then again, that makes no sense whatsoever at compile-
> time... Im starting to doubt if there is any sense to be found here at
> all.

A constraint failure causes an error at the time it's discovered.
1) Your editor pops up a message the instant you type something with
such an error, and forces you to correct it before going on.
2) Your compiler refuses to produce byte-code for the module.
3) When the line of code is executed, an exception is thrown.
All of these are valid ways of handling a constraint. Here is a Python
example of a type constraint:

def foo(arg):
if not isinstance(arg,list): raise "This won't work."

If you call it with something that's not a list, you get an error.
Call it with a list, and execution continues normally. That's a
constraint. Of course, it might not be a _type_ constraint:

def foo(arg):
   if arg>5: raise "This won't work either." # and yes, that's oddly
truer in Python 3

(Aside: In Pike, I can actually put that into a type constraint
(declare the argument to be int(5..) for instance). This, however, is
not germane to the conversation.)

> Anyway, ill take your further silence on the matter as a 'sorry I
> derailed your thread with my confusion of terminology'

Like Mary Poppins, I never apologize for derailing threads :)

>> Python, by its nature, cannot do compile-time type checking.
>
> Python can do whatever its designers have put into it. In this case,
> that includes the emission of different code based on a (type)
> annotation at the point of declaration of an identifier (only in the
> particular circumstance of collection unpacking though, as far as I am
> aware).

Of course, but how can Python, without a completely different
structure, do compile-time checking of object types? Everything can be
monkey-patched at run-time. Anything could be affected by any function
call. It's impossible to say for certain, at compile time, what data
type anything will have.

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

Re: Possible bug in string handling (with kludgy work-around)

[Chris Angelico]

On Tue, Dec 27, 2011 at 9:23 AM, Charles Hixson
 wrote:
> This doesn't cause a crash, but rather incorrect results.

You may need to be a bit clearer. What line of code (or what
expression)? What did you expect to see, and what did you see?

>From examining your code, I've come up with one most-likely scenario.
In Python, indexing is zero-based and, in effect, indexes the
boundaries between items rather than the items themselves. Referencing
string[-1] actually means asking for the boundary between the
second-last and last characters; using that as your end marker
actually trims off the last character. What you may want is simply:

self.wordList[i][1:]

which means "from character position 1 to the end of the string".

Hope that helps!

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

Re: How to check for single character change in a string?

[tinnews]

Roy Smith  wrote:
> In article ,
>  Roy Smith  wrote:
> 
> > >>> len([x for x in zip(s1, s2) if x[0] != x[1]])
> 
> Heh, Ian Kelly's version:
> 
> > sum(a == b for a, b in zip(str1, str2))
> 
> is cleaner than mine.  Except that Ian's counts matches and the OP asked 
> for non-matches, but that's an exercise for the reader :-)

:-)

I'm actually walking through a directory tree and checking that file
characteristics don't change in a sequence of files.  

What I'm looking for is 'unusual' changes in file characteristics
(they're image files with camera information and such in them) in a
sequential list of files.

Thus if file001, file002, file003, file004 have the same camera type
I'm happy, but if file003 appears to have been taken with a different
camera something is probably amiss.  I realise there will be *two*
character changes when going from file009 to file010 but I can cope
with that.  I can't just extract the sequence number because in some
cases they have non-numeric names, etc.

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

Re: Possible bug in string handling (with kludgy work-around)

[Rick Johnson]

On Dec 26, 4:23 pm, Charles Hixson  wrote:
> This doesn't cause a crash, but rather incorrect results.
>
> self.wordList    =    ["The", "quick", "brown", "fox", "carefully",
>                  "jumps", "over", "the", "lazy", "dog", "as", "it",
>                  "stealthily", "wends", "its", "way", "homewards", '\b.']
> for    i    in    range (len (self.wordList) ):
>     if    not isinstance(self.wordList[i], str):
>         self.wordList = ""
>    elif self.wordList[i] != "" and self.wordList[i][0] == "\b":
>         print ("0: wordList[", i, "] = \"", self.wordList[i], "\"", sep
> = "")
>         print ("0a: wordList[", i, "][1] = \"", self.wordList[i][1],
> "\"", sep = "")
>         tmp    =    self.wordList[i][1]             ## !! Kludge --
> remove tmp to see the error
>         self.wordList[i]    =    tmp + self.wordList[i][1:-1]  ## !!
> Kludge -- remove tmp + to see the error
>         print ("1: wordList[", i, "] = \"", self.wordList[i], "\"", sep
> = "")
>         print    ("len(wordList[", i, "]) = ", len(self.wordList[i]) )
>
> --
> Charles Hixson

Handy rules for reporting bugs:

1. Always format code properly.
2. Always trim excess fat from code.
3. Always include relative dependencies ("self.wordlist" is only valid
inside a class. In this case, change the code to a state that is NOT
dependent on a class definition.)

Most times after following these simple rules, you'll find egg on your
face BEFORE someone else has a chance to see it and ridicule you.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Possible bug in string handling (with kludgy work-around)

[Chris Angelico]

On Tue, Dec 27, 2011 at 9:48 AM, Rick Johnson
 wrote:
> Handy rules for reporting bugs:
>
> 1. Always format code properly.
> 2. Always trim excess fat from code.
> 3. Always include relative dependencies ("self.wordlist" is only valid
> inside a class. In this case, change the code to a state that is NOT
> dependent on a class definition.)
>
> Most times after following these simple rules, you'll find egg on your
> face BEFORE someone else has a chance to see it and ridicule you.

4. Don't take it personally when a known troll insults you. His
advice, in this case, is valid; but don't feel that you're going to be
ridiculed. We don't work that way on this list.

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

Re: Multithreading

[Yigit Turgut]

On Dec 26, 10:01 pm, Ian Kelly  wrote:
> On Mon, Dec 26, 2011 at 11:31 AM, Yigit Turgut  wrote:
> > I have a loop as following ;
>
> > start = time.time()
> > end = time.time() - start
> >  while(end >          data1 = self.chan1.getWaveform()
> >          end = time.time() - start
> >          timer.tick(10)  #FPS
> >          screen.fill((255,255,255) if white else(0,0,0))
> >          white = not white
> >          pygame.display.update()
> >          for i in range(self.size):
> >              end = time.time() - start
> >              f.write("%3.8f\t%f\n"%(end,data1[i]))
>
> > Roughly speaking, this loop displays something at 10 frames per second
> > and writes data1 to a file with timestamps.
>
> > At first loop data1 is grabbed but to grab the second value (second
> > loop) it needs to wait for timer.tick to complete. When I change FPS
> > value [timer.tick()], capturing period (time interval between loops)
> > of data1 also changes. What I need is to run ;
>
> >          timer.tick(10)  #FPS
> >          screen.fill((255,255,255) if white else(0,0,0))
> >          white = not white
> >          pygame.display.update()
>
> > for N seconds but this shouldn't effect the interval between loops
> > thus I will be able to continuously grab data while displaying
> > something at X fps.
>
> > What would be an effective workaround for this situation ?
>
> You essentially have two completely independent loops that need to run
> simultaneously with different timings.  Sounds like a good case for
> multiple threads (or processes if you prefer, but these aren:
>
> def write_data(self, f, N):
>     start = time.time()
>     while self.has_more_data():
>         data1 = self.chan1.getWaveform()
>         time.sleep(N)
>         for i in range(self.size):
>             end = time.time() - start
>             f.write("%3.8f\t%f\n" % (end, data[i]))

Why is there N variable in write_data function ? N is related to
timer.tick(N) which is related to display function ? time.sleep(N)
will pause writing to file for specified amount of time which is
exactly what I am trying to avoid.
-- 
http://mail.python.org/mailman/listinfo/python-list

Regular expressions

[mauricel...@acm.org]

Hi

I am trying to change "@HWI-ST115:568:B08LLABXX:1:1105:6465:151103 1:N:
0:" to "@HWI-ST115:568:B08LLABXX:1:1105:6465:151103/1".

Can anyone help me with the regular expressions needed?

Thanks in advance.

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

installing matplotlib in MacOs 10.6.8.

[Alex Ter-Sarkissov]

thanks Ned,

that's quite weird: if I run python2.7-32 in terminal, it works like you
said, but when I add it as an interpreter in Eclipse, matplotlib.pyplot
doesn't get imported for some reason. Even more strange, either way
platform.architecture() reports 64-bit. What's wrong here?

cheers,

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

Re: installing matplotlib in MacOs 10.6.8.

[Alex Ter-Sarkissov]

thanks Ned,

that's quite weird: if I run python2.7-32 in terminal, it works like you
said, but when I add it as an interpreter in Eclipse, matplotlib.pyplot
doesn't get imported for some reason. Even more strange, either way
platform.architecture() reports 64-bit. What's wrong here?

cheers,

Alex

27 декабря 2011 г. 3:54 пользователь Ned Deily  написал:

> In article
> ,
>  Alex Ter-Sarkissov  wrote:
> > hi everyone, I run python 2.7.2. in Eclipse (recently upgraded from
> 2.6). I
> > have a problem with installing matplotlib (I found the version for python
> > 2.7. MacOs 10.3, no later versions). If I run python in terminal using
> arch
> > -i386 python, and then
> >
> > from matplotlib.pylab import *
> >
> > and similar stuff, everything works fine. If I run python in eclipse or
> > just without arch -i386, I can import matplotlib as
> >
> > from matplotlib import  *
> >
> > but actually nothing gets imported. If I do it in the same way as above,
> I
> > get the message
> >
> > no matching architecture in universal wrapper
> >
> > which means there's conflict of versions or something like that. I tried
> > reinstalling the interpreter and adding matplotlib to forced built-ins,
> but
> > nothing helped. For some reason I didn't have this problem with numpy and
> > tkinter.
>
> The message means almost certainly means that the Python you are using
> is a 64-bit/32-bit universal version.  When you launch Python with -arch
> i386, you force the Python to run in 32-bit mode so it is compatible
> with the 32-bit-only version of matplotlib you've installed in it.  When
> you launch Python by default, it is runnning in 64-bit mode so the
> 32-bit-only C extension modules in that version of matplotlib cannot be
> loaded.  You might want to ask the matplotlib developers to make a
> 64-bit version available.  In the mean time, you could try to configure
> Eclipse to invoke the python with `python2.7-32`, which is included with
> distributions like the python.org one to force Python to run in 32-bit
> mode on OS X.
>
> --
>  Ned Deily,
>  n...@acm.org
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Regular expressions

[Chris Angelico]

On Tue, Dec 27, 2011 at 10:45 AM, mauricel...@acm.org
 wrote:
> Hi
>
> I am trying to change  to .
>
> Can anyone help me with the regular expressions needed?

A regular expression defines a string based on rules. Without seeing a
lot more strings, we can't know what possibilities there are for each
part of the string. You probably know your data better than we ever
will, even eyeballing the entire set of strings; just write down, in
order, what the pieces ought to be - for instance, the first token
might be a literal @ sign, followed by three upper-case letters, then
a hyphen, then any number of alphanumerics followed by a colon, etc.
Once you have that, it's fairly straightforward to translate that into
regex syntax.

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

Re: Regular expressions

[Roy Smith]

In article 
<495b6fe6-704a-42fc-b10b-484218ad8...@b20g2000pro.googlegroups.com>,
 "mauricel...@acm.org"  wrote:

> Hi
> 
> I am trying to change "@HWI-ST115:568:B08LLABXX:1:1105:6465:151103 1:N:
> 0:" to "@HWI-ST115:568:B08LLABXX:1:1105:6465:151103/1".
> 
> Can anyone help me with the regular expressions needed?

Easy-peasy:

import re
input = "@HWI-ST115:568:B08LLABXX:1:1105:6465:151103 1:N: 0:"
output = "@HWI-ST115:568:B08LLABXX:1:1105:6465:151103/1"
pattern = re.compile(
r'@HWI-ST115:568:B08LLABXX:1:1105:6465:151103 1:N: 0:')
out = pattern.sub(
r'@HWI-ST115:568:B08LLABXX:1:1105:6465:151103/1',
input)
assert out == output

To be honest, I wouldn't do this with a regex.  I'm not quite sure what 
you're trying to do, but I'm guessing it's something like "Get 
everything after the first space in the string; keep just the integer 
that's before the first ':' in that and turn the space into a slash".  
In that case, I'd do something like:

head, tail = input.split(' ', 1)
number, _ = tail.split(':')
print "%s/%s" % (head, number)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Regular expressions

[Jason Friedman]

> On Tue, Dec 27, 2011 at 10:45 AM, mauricel...@acm.org
>  wrote:
>> Hi
>>
>> I am trying to change  to .
>>
>> Can anyone help me with the regular expressions needed?
>
> A regular expression defines a string based on rules. Without seeing a
> lot more strings, we can't know what possibilities there are for each
> part of the string. You probably know your data better than we ever
> will, even eyeballing the entire set of strings; just write down, in
> order, what the pieces ought to be - for instance, the first token
> might be a literal @ sign, followed by three upper-case letters, then
> a hyphen, then any number of alphanumerics followed by a colon, etc.
> Once you have that, it's fairly straightforward to translate that into
> regex syntax.
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list

The OP told me, off list, that my guess was true:

> Can we say that your string:
> 1) Contains 7 colon-delimited fields, followed by
> 2) whitespace, followed by
> 3) 3 colon-delimited fields (A, B, C), followed by
> 4) a colon?
> The transformation needed is that the whitespace is replaced by a
> slash, the "A" characters are taken as is, and the colons and fields
> following the "A" characters are eliminated?

Doubtful that my guess was 100% accurate, but nevertheless:

>>> import re
>>> string1 = "@HWI-ST115:568:B08LLABXX:1:1105:6465:151103 1:N:0:"
>>> re.sub(r"(\S+)\s+(\S+?):.+", "\g<1>/\g<2>", string1)
'@HWI-ST115:568:B08LLABXX:1:1105:6465:151103/1'
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Regular expressions

[mauricel...@acm.org]

On Dec 27, 8:00 am, Chris Angelico  wrote:
> On Tue, Dec 27, 2011 at 10:45 AM, mauricel...@acm.org
>
>  wrote:
> > Hi
>
> > I am trying to change  to .
>
> > Can anyone help me with the regular expressions needed?
>
> A regular expression defines a string based on rules. Without seeing a
> lot more strings, we can't know what possibilities there are for each
> part of the string. You probably know your data better than we ever
> will, even eyeballing the entire set of strings; just write down, in
> order, what the pieces ought to be - for instance, the first token
> might be a literal @ sign, followed by three upper-case letters, then
> a hyphen, then any number of alphanumerics followed by a colon, etc.
> Once you have that, it's fairly straightforward to translate that into
> regex syntax.
>
> ChrisA

I've tried

re.sub('@\S\s[1-9]:[A-N]:[0-9]', '@\S\s', '@HWI-ST115:568:B08LLABXX:
1:1105:6465:151103 1:N:0:')

but it does not seems to work.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Regular expressions

[mauricel...@acm.org]

On Dec 27, 8:16 am, Jason Friedman  wrote:
> > On Tue, Dec 27, 2011 at 10:45 AM, mauricel...@acm.org
> >  wrote:
> >> Hi
>
> >> I am trying to change  to .
>
> >> Can anyone help me with the regular expressions needed?
>
> > A regular expression defines a string based on rules. Without seeing a
> > lot more strings, we can't know what possibilities there are for each
> > part of the string. You probably know your data better than we ever
> > will, even eyeballing the entire set of strings; just write down, in
> > order, what the pieces ought to be - for instance, the first token
> > might be a literal @ sign, followed by three upper-case letters, then
> > a hyphen, then any number of alphanumerics followed by a colon, etc.
> > Once you have that, it's fairly straightforward to translate that into
> > regex syntax.
>
> > ChrisA
> > --
> >http://mail.python.org/mailman/listinfo/python-list
>
> The OP told me, off list, that my guess was true:
>
> > Can we say that your string:
> > 1) Contains 7 colon-delimited fields, followed by
> > 2) whitespace, followed by
> > 3) 3 colon-delimited fields (A, B, C), followed by
> > 4) a colon?
> > The transformation needed is that the whitespace is replaced by a
> > slash, the "A" characters are taken as is, and the colons and fields
> > following the "A" characters are eliminated?
>
> Doubtful that my guess was 100% accurate, but nevertheless:
>
> >>> import re
> >>> string1 = "@HWI-ST115:568:B08LLABXX:1:1105:6465:151103 1:N:0:"
> >>> re.sub(r"(\S+)\s+(\S+?):.+", "\g<1>/\g<2>", string1)
>
> '@HWI-ST115:568:B08LLABXX:1:1105:6465:151103/1'

Thanks a lot everyone.

Can anyone suggest a good place to learn REs?

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

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 26, 11:27 pm, Chris Angelico  wrote:
> On Tue, Dec 27, 2011 at 8:51 AM, Eelco  wrote:
> > That proves the original point of contention: that [Steve's demo code] is
> > suboptimal language design, not because terseness always trumps
> > verbosity, but because commonly-used constructs (such as parenthesis
> > or round brackets or whatever you wish to call them) are more
> > deserving of the limited space in both the ascii table and your
> > reflexive memory, than uncommonly used ones.
>
> In Magic: The Gathering R&D, they have a term (the article reporting
> which I can't actually find at the moment) called "spread complexity"
> or "fan complexity" - the idea being that as you fan out a booster
> pack, you see a certain amount of complexity in front of you. The
> designers can afford to put more complex cards in as rares than they
> can as commons, because you see ten commons for every rare - so a
> common factors ten times as much as a rare in spread complexity. (Mark
> Rosewater, my apologies if I'm misremembering here!)
>
> The same applies here. When you cast your eye over a program, you're
> going to see certain syntactic elements a lot. Assignment, arithmetic,
> blocks of code (ie indent/dedent), and function calls are all
> extremely common; lambdas, the use of decorators, and exception
> handling are somewhat uncommon; and metaclasses, the writing of
> decorators, and reloading of modules are all quite rare.
>
> The elements that occur frequently should be:
> a) Readable and grokkable;
> b) Easily typed on a regular keyboard - no using ASCII character 126
> to mean negation, tyvm!
> c) Make sense.
>
> Rarer elements (and I'm not talking about xenon and plutonium here)
> are allowed to have long names, obscure syntax, or even be shoved away
> in odd modules (the way module reloading is in Python 3). If 0.1% of
> your code is suddenly twice as large as it used to be, will you
> notice? But if a new syntax adds even 5% to the mindspace requirement
> of basic assignment, your code will majorly suffer.
>
> In summary: Terseness trumps verbosity primarily for common
> operations, and only when doing so does not violate rules a and c
> above.
>
> ChrisA

Good to see there is something we agree upon completely.

Not that I mean to say the question as to how verbose a syntax is
appropriate for collection (un)packing is settled; one could
reasonably argue they find tail::tuple too verbose. But parenthesis
are not a terribly good example to compare to, since they are infact
so much more used they are clearly in another category.

*args and **kwargs are debateable in the appropriateness of their
terseness (but I personally like to err on the side of verbosity), but
extended collection unpacking, as in 'head,*tail=sequence', is quite a
rare construct indeed, and here I very strongly feel a more explicit
syntax is preferrable. That is, as a seasoned python 2 user, I wouldnt
have been willing to gamble on what this does when id come across it
for the first time in python 3. Could as well be a completely new use
of the asterisk. But if collection packing/unpacking would be
presented as a more general construct from the start,
'head,tail::tuple=sequence' would be hard to miss.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pythonification of the asterisk-based collection packing/unpacking syntax

[Chris Angelico]

On Tue, Dec 27, 2011 at 10:44 AM, Eelco  wrote:
> extended collection unpacking, as in 'head,*tail=sequence', is quite a
> rare construct indeed, and here I very strongly feel a more explicit
> syntax is preferrable.

You may be right, but...

> ... if collection packing/unpacking would be
> presented as a more general construct from the start,
> 'head,tail::tuple=sequence' would be hard to miss.

... it doesn't really justify a _change_. When a language is in its
infancy and the only code written in it is on the designers' own
computers, these sorts of debates can be tipped by relatively small
differences - is it more readable, is it quick enough to type, etc.
But once a language reaches a level of maturity, changes need to
overwhelm the "but it's a change" hurdle - breaking existing code is
majorly dangerous, and keeping two distinct ways of doing something
means you get the worst of both worlds.

We can argue till the cows come home as to which way would be better,
_had Python started with it_. I don't think there's anything like
enough difference to justify the breakage/duplication.

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

Re: Possible bug in string handling (with kludgy work-around)

[Steven D'Aprano]

On Mon, 26 Dec 2011 14:23:03 -0800, Charles Hixson wrote:

> This doesn't cause a crash, but rather incorrect results.

Charles, your code is badly formatted and virtually unreadable. You have 
four spaces between some tokens, lines are too long to fit in an email or 
News post without word-wrapping. It is a mess of unidiomatic code filled 
with repeated indexing and unnecessary backslash escapes.

You also don't tell us what result you expect, or what result you 
actually get. What is the intention of the code? What are you trying to 
do, and what happens instead?

The code as given doesn't run -- what's self?

Despite all these problems, I can see one obvious problem in your code: 
you test to see if self.wordList[i] is a string, and if not, you replace 
the *entire* wordList with the empty string. That is unlikely to do what 
you want, although I admit I'm guessing what you are trying to do (since 
you don't tell us).

Some hints for you:

(1) Python has two string delimiters, " and ' and you should use them 
both. Instead of hard-to-read backslash escapes, just swap delimiters:

print "A string including a \" quote mark."  # No!
print 'A string including a " quote mark.'  # Yes, much easier to read.

The only time you should backslash-escape a quotation mark is if you need 
to include both sorts in a single string:

print "Python has both single ' and double \" quotation marks."
print 'Python has both single \' and double " quotation marks.'


(2) Python is not Pascal, or whatever language you seem to be writing in 
the style of. You almost never should write for-loops like this:


for i in range(len(something)):
print something[i]


Instead, you should just iterate over "something" directly:


for obj in something:
print obj


If you also need the index, use the enumerate function:


for i,obj in enumerate(something):
print obj, i


If you are forced to use an ancient version of Python without enumerate, 
do yourself a favour and write your loops like this:


for i in range(len(something)):
obj = something[i]
print obj, i


instead of repeatedly indexing the list over and over and over and over 
again, as you do in your own code. The use of a temporary variable makes 
the code much easier to read and understand.



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

Re: Regular expressions

[Jason Friedman]

> Thanks a lot everyone.
>
> Can anyone suggest a good place to learn REs?

Start with the manual:
http://docs.python.org/py3k/library/re.html#module-re
-- 
http://mail.python.org/mailman/listinfo/python-list

Daemon management

[Fredrik Tolf]

Dear list,

Lately, I've had a personal itch to scratch, in that I run a couple of 
Python programs as daemons, and sometimes want to inspect or alter them in 
ad-hoc ways, or other times need to do things to them that are less 
ad-hoc in nature, but nevertheless lack a natural user interface.


In order to solve that problem, I wrote a small library to allow the 
daemon to simply listen to some socket and accept arbitrary, but easily 
definable, commands. It also provides a "remote REPL" to allow me to run 
arbitrary Python code interactively in the context of the daemon.


I was actually a bit surprised that I couldn't find any obvious 
existing solution to the problem, so I'm writing this message in order 
to share mine, just in case anyone else would happen to have the same 
problem as I had and doesn't want to reinvent the wheel yet again:




Humbly,

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

confused about __new__

[K. Richard Pixley]

I'm confused about the following.  The idea here is that the set of 
instances of some class are small and finite, so I'd like to create them 
at class creation time, then hijack __new__ to simply return one of the 
preexisting classes instead of creating a new one each call.


This seems to work in python3, but fails in python2 with:

Foo(23)
TypeError: unbound method __Foo__new__() must be called with Foo 
instance as first argument (got type instance instead)


I don't understand.  Can anyone explain?

--rich
class Foo(object):
def __init__(self, val):
self.val = val

foos = [Foo(0), Foo(1)]

def __Foo__new__(cls, val):
if val & 0x1:
return foos[0]
else:
return foos[1]

Foo.__new__ = __Foo__new__

Foo(23)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: confused about __new__

[Steven D'Aprano]

On Mon, 26 Dec 2011 20:28:26 -0800, K. Richard Pixley wrote:

> I'm confused about the following.  The idea here is that the set of
> instances of some class are small and finite, so I'd like to create them
> at class creation time, then hijack __new__ to simply return one of the
> preexisting classes instead of creating a new one each call.

I'm surprised it works in Python3. Try this in Python 2 instead:

Foo.__new__ = staticmethod(__Foo__new__)



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

Re: Regular expressions

[Fredrik Tolf]

On Mon, 26 Dec 2011, mauricel...@acm.org wrote:

I've tried

re.sub('@\S\s[1-9]:[A-N]:[0-9]', '@\S\s', '@HWI-ST115:568:B08LLABXX:
1:1105:6465:151103 1:N:0:')

but it does not seems to work.


Indeed, for several reasons. First of all, your backslash sequences are 
interpreted by Python as string escapes. You'll need to write either "\\S" 
or r"\S" (the r, for raw, turns off backslash escapes).


Second, when you use only "\S", that matches a single non-space character, 
not several; you'll need to quantify them. "\S*" will match zero or more, 
"\S+" will match one or more, "\S?" will match zero or one, and there are 
a couple of other possibilities as well (see the manual for details). In 
this case, you probably want to use "+" for most of those.


Third, you're not marking the groups that you want to use in the 
replacement. Since you want to retain the entire string before the space, 
and the numeric element, you'll want to enclose them in parentheses to 
mark them as groups.


Fourth, your replacement string is entirely wacky. You don't use sequences 
such as "\S" and "\s" to refer back to groups in the original text, but 
numbered references, to refer back to parenthesized groups in the order 
they appear in the regex. In accordance what you seemed to want, you 
should probably use "@\1/\2" in your case ("\1" refers back to the first 
parentesized group, which you be the first "\S+" part, and "\2" to the 
second group, which should be the "[1-9]+" part; the at-mark and slash 
are inserted as they are into the result string).


Fifth, you'll probably want to match the last colon as well, in order not 
to retain it into the result string.


All in all, you will probably want to use something like this to correct 
that regex:


re.sub(r'@(\S+)\s([1-9]+):[A-N]+:[0-9]+:', r'@\1/\2',
   '@HWI-ST115:568:B08LLABXX:1:1105:6465:151103 1:N:0:')

Also, you may be interested to know that you can use "\d" instead of 
"[0-9]".


--

Fredrik Tolf

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

Re: Multithreading

[Ian Kelly]

On Dec 26, 2011 4:13 PM, "Yigit Turgut"  wrote:
> Why is there N variable in write_data function ? N is related to
> timer.tick(N) which is related to display function ? time.sleep(N)
> will pause writing to file for specified amount of time which is
> exactly what I am trying to avoid.

My understanding from your first post was that the pygame loop was supposed
to run at X FPS while the other loop was supposed to run every N seconds.
If that is not the case and the data loop is supposed to run as fast as
possible, then you don't need threads for this.  Just stream the data in a
tight loop, and on each iteration check the timer for how much time has
elapsed to determine whether to run the pygame code without using
timer.tick.  If not enough time has elapsed for your target framerate, just
skip that part.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: confused about __new__

[K Richard Pixley]

On 12/26/11 20:53 , Steven D'Aprano wrote:

On Mon, 26 Dec 2011 20:28:26 -0800, K. Richard Pixley wrote:


I'm confused about the following.  The idea here is that the set of
instances of some class are small and finite, so I'd like to create them
at class creation time, then hijack __new__ to simply return one of the
preexisting classes instead of creating a new one each call.


I'm surprised it works in Python3. Try this in Python 2 instead:

Foo.__new__ = staticmethod(__Foo__new__)


Excellent.  Thank you.

--rich

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

Re: confused about __new__

[Fredrik Tolf]

On Mon, 26 Dec 2011, K. Richard Pixley wrote:

I don't understand.  Can anyone explain?


I'm also a bit confused about __new__. I'd very much appreciate it if 
someone could explain the following aspects of it:


 * The manual () says
   that __new__ is "a static method (special-cased so you need not declare
   it as such)". What does "special-cased" mean? Apparently, for
   instance, in OP's case,  Python did not automatically detect that it
   should not be bound as a method.

 * Is there any part of the manual that explains, holistically, the
   greater context of object instantiation into which __new__ fits? I can
   only find small parts of it spread around the documentation for __new__
   and __init__, but no complete explanation of it. There are several
   things I'm wondering about, like what it means to call a type object at
   all; how methods, properties and the like are bound; how pickle can
   instantiate a class without calling __init__; when and whether __dict__
   is created and a couple of other things. Is there a complete
   documentation of the process anywhere that I haven't managed to find?

--

Fredrik Tolf

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

Re: Python education survey

[Carl Smith]

On Dec 20, 10:58 am, Andrea Crotti  wrote:
> On 12/20/2011 03:51 AM, Raymond Hettinger wrote:
>
>
>
>
>
>
>
>
>
> > Do you use IDLE when teaching Python?
> > If not, what is the tool of choice?
>
> > Students may not be experienced with the command-line and may be
> > running Windows, Linux, or Macs.  Ideally, the tool or IDE will be
> > easy to install and configure (startup directory, path, associated
> > with a particular version of Python etc).
>
> > Though an Emacs user myself, I've been teaching with IDLE because it's
> > free; it runs on multiple OSes, it has tooltips and code colorization
> > and easy indent/dedent/comment/uncomment commands, it has tab
> > completion; it allows easy editing at the interactive prompt; it has
> > an easy run-script command (F5); it has direct access to source code
> > (File OpenModule) and a class browser (Cntl+B).
>
> > On the downside, some python distros aren't built with the requisite
> > Tcl/Tk support; some distros like the Mac OS ship with a broken Tcl/Tk
> > so users have to install a fix to that as well; and IDLE sometimes
> > just freezes for no reason.  It also doesn't have an easy way to
> > specify the startup directory.
>
> > If your goal is to quickly get new users up and running in Python,
> > what IDE or editor do you recommend?
>
> > Raymond
>
> I think ipython and a good editor gives a much nicer experience
> than IDLE, which I actually almost never used, and
> for everything else there is python and python-mode.
>
> New users however can be pointed to something like PyCharm
> or Eclipse+PyDev if they are more familiar to IDEs..

I agree; IPython is a excellent choice. You have a much more powerful
interactive Python experience, with all the features you need from an
IDE. You can use any editor (VIM) and you can also readily hack
IPython to death.

I think the fact that anyone with basic programming skills can
substantially enhance their console is a big winner in CS education.
It gives students something they personally value to work on, it's a
place to store all their little bits of code and actually benefit from
them in real life.

I've never met a programmer that got familiar with IPython and then
went on to stop using it. It should be included in the standard
library and used as the default Python interactive environment.

The last line of my .bashrc file:

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

Re: Python education survey

[Carl Smith]

On Dec 25, 5:44 pm, Rick Johnson  wrote:
> On Dec 19, 9:51 pm, Raymond Hettinger 
> wrote:
>
> > Do you use IDLE when teaching Python?
> > If not, what is the tool of choice?
>
> I believe IDLE has the potential to be a very useful teaching tool and
> even in it's current abysmal state, i find it to be quite useful.
>
> > Students may not be experienced with the command-line and may be
> > running Windows, Linux, or Macs.  Ideally, the tool or IDE will be
> > easy to install and configure (startup directory, path, associated
> > with a particular version of Python etc).
>
> Why install an IDE when IDLE is already there? Oh, yes, IDLE SUCKS. I
> know that already. But this revelation begs the question... Why has
> this community allowed IDLE to rot? Why has guido NOT started a public
> discussion on the matter?
>
> > Though an Emacs user myself, I've been teaching with IDLE because it's
> > free; it runs on multiple OSes, it has tooltips and code colorization
> > and easy indent/dedent/comment/uncomment commands, it has tab
> > completion; it allows easy editing at the interactive prompt; it has
> > an easy run-script command (F5); it has direct access to source code
> > (File OpenModule) and a class browser (Cntl+B).
>
> Yes, IDLE has all the basic tools anyone would need. Some people
> complain about a debugger, but i never use a debugger anyway. I feel
> debuggers just wreaken your debugging skills.
>
> > On the downside, some python distros aren't built with the requisite
> > Tcl/Tk support;
>
> And who's fault is that?
>
> > some distros like the Mac OS ship with a broken Tcl/Tk
> > so users have to install a fix to that as well; and IDLE sometimes
> > just freezes for no reason.
>
> And who's fault is that?
>
> >  [IDLE] also doesn't have an easy way to
> > specify the startup directory.
>
> Are you kidding me? That could be fixed so easily!
>
> > If your goal is to quickly get new users up and running in Python,
> > what IDE or editor do you recommend?
>
> IDLE, of course. But NOT in its current state.
>
> Why would myself (or anyone) go to the trouble of downloading third
> party IDEs when IDLE is just waiting there for us to use? I for one,
> like to use tools that have open source code.  And what is a better
> Python IDE than a Python IDE written in PYTHON? I ask ya?
>
> Also, what is the purpose of this thread Raymond? Are you (and others)
> considering removing IDLE from the source distro?
>
> You know. Many folks in this community have known for a long time how
> much i love IDLE, but at the same time how much i loath it's atrocious
> code base. I also know for a fact, that many "movers and shakers"
> within this community simultaneously use IDLE, and want to see IDLE
> code improved. However. None of these fine folks have taken the time
> to contact me privately so we can discuss such an evolution. Why is
> that? It boggles the mind really.

Do people seriously use IDLE? I thought it was just there for
scratchers, like turtle.
-- 
http://mail.python.org/mailman/listinfo/python-list

python logging module:a quick question

[Littlefield, Tyler]

Hello all:
I have a basic server I am working on, and wanted some input with an 
error I'm getting.

I am initializing the logger like so:
if __name__ == "__main__":
  observer = log.PythonLoggingObserver()
  observer.start()
  logging.basicConfig(filename='logs/server.log', level=logging.DEBUG, 
format='%(asctime)s [%(levelname)s] %(module)s:%(funcname)s:%(lineno)d 
%(message)s')

  logger = logging.getLogger()
  logger.addHandler(logging.handlers.TimedRotatingFileHandler)
...
I get the following error:
  File 
"/home/gserver/alpine/lib/python2.7/site-packages/twisted/internet/protoc

ol.py", line 52, in doStart
log.msg("Starting factory %r" % self)
---  ---
  File 
"/home/gserver/alpine/lib/python2.7/site-packages/twisted/python/log.py",

 line 284, in msg
self.observers[i](actualEventDict)
  File 
"/home/gserver/alpine/lib/python2.7/site-packages/twisted/python/log.py",

 line 532, in emit
self.logger.log(level, text)
  File "/usr/local/lib/python2.7/logging/__init__.py", line 1195, in log
self._log(level, msg, args, **kwargs)
  File "/usr/local/lib/python2.7/logging/__init__.py", line 1250, in _log
self.handle(record)
  File "/usr/local/lib/python2.7/logging/__init__.py", line 1260, in handle
self.callHandlers(record)
  File "/usr/local/lib/python2.7/logging/__init__.py", line 1299, in 
callHandler

s
if record.levelno >= hdlr.level:
exceptions.AttributeError: type object 'TimedRotatingFileHandler' has no 
attribute 'level'
I'm also curious how this rotating handler works. Will it just log to a 
file per day for a week, then start rotating those out with newer ones? 
Can I change the interval?


--

Take care,
Ty
Web: http://tds-solutions.net
The Aspen project: a light-weight barebones mud engine
http://code.google.com/p/aspenmud

Sent from my toaster.

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

Re: installing matplotlib in MacOs 10.6.8.

[Ned Deily]

In article 
,
 Alex Ter-Sarkissov  wrote:
> that's quite weird: if I run python2.7-32 in terminal, it works like you
> said, but when I add it as an interpreter in Eclipse, matplotlib.pyplot
> doesn't get imported for some reason. Even more strange, either way
> platform.architecture() reports 64-bit. What's wrong here?

platform.architecture() is not accurate for OS X 64-/32-bit builds.  Use 
sys.maxsize instead.  I have no experience with Eclipse so I really 
can't say how Eclipse might be launching the interpreter.  Sorry!

-- 
 Ned Deily,
 n...@acm.org

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

Re: confused about __new__

[Ian Kelly]

On Mon, Dec 26, 2011 at 10:48 PM, Fredrik Tolf  wrote:
> I'm also a bit confused about __new__. I'd very much appreciate it if
> someone could explain the following aspects of it:
>
>  * The manual () says
>   that __new__ is "a static method (special-cased so you need not declare
>   it as such)". What does "special-cased" mean? Apparently, for
>   instance, in OP's case,  Python did not automatically detect that it
>   should not be bound as a method.

It apparently has to do with the class creation.  For the
special-casing to happen, the __new__ method has to be present when
the class is created.  If it is, then it automatically gets wrapped in
a staticmethod.  In the OP's case, he was adding the __new__ method
after class creation, so the wrapping did not happen automatically.
Compare:

>>> def my_new(cls): return object.__new__(cls)
...
>>> class Foo(object):
... __new__ = my_new
...
>>> class Bar(object): pass
...
>>> Bar.__new__ = my_new
>>> Foo.__dict__['__new__']

>>> Bar.__dict__['__new__']


>  * Is there any part of the manual that explains, holistically, the
>   greater context of object instantiation into which __new__ fits? I can
>   only find small parts of it spread around the documentation for __new__
>   and __init__, but no complete explanation of it. There are several
>   things I'm wondering about, like what it means to call a type object at
>   all;

I don't know of anything that organizes it that way specifically, but
I believe the Data Model reference pretty much covers what you're
looking for.  From the type hierarchy, under "Callable Types":
http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy
"""
Class Types
Class types, or “new-style classes,” are callable. These objects
normally act as factories for new instances of themselves, but
variations are possible for class types that override __new__(). The
arguments of the call are passed to __new__() and, in the typical
case, to __init__() to initialize the new instance.
"""

AFAIK, that's pretty much it.  When a type is called, __new__ is
called to create the new instance, and then __init__ is called to
initialize it (if __new__ returned an instance of the type).

> how methods, properties and the like are bound;

When they're accessed, using the descriptor protocol, not as part of
the instantiation process.  See:
http://docs.python.org/reference/datamodel.html#invoking-descriptors

> how pickle can
>   instantiate a class without calling __init__;

By calling the __new__ method directly instead of calling the type:
http://docs.python.org/library/pickle.html#object.__getnewargs__

> when and whether __dict__
>   is created and a couple of other things.

Under the hood as part of the object creation process, unless the
class uses __slots__.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: confused about __new__

[Lie Ryan]

On 12/27/2011 04:48 PM, Fredrik Tolf wrote:

On Mon, 26 Dec 2011, K. Richard Pixley wrote:

I don't understand. Can anyone explain?


I'm also a bit confused about __new__. I'd very much appreciate it if
someone could explain the following aspects of it:

* The manual () says
that __new__ is "a static method (special-cased so you need not declare
it as such)". What does "special-cased" mean? Apparently, for
instance, in OP's case, Python did not automatically detect that it
should not be bound as a method.


If you declare new in the regular way:

class Foo(object):
def __new__(cls):
...

Python would create __new__ as a static method even without applying the 
staticmethod decorator; that python does not detect to special case 
__new__ when it is added dynamically is probably an oversight in Python 
2.x that was fixed in Python 3.x.


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