Serial & reset of the device
Hello, I'm trying to access a hardware board of my company through a serial connection using a Python script and the pyserial module. I use Python 2.7.1 with Ubuntu 11.04 (pyserial is the package python- serial with version 2.5.2, http://pyserial.sourceforge.net/pyserial_api.html). The board to which I'm trying to connect works correctly with serial as some other guys did some TCL scripts to manage it. My problem is that every time I open a new connection, the device is reset. I'd like to not have the device reset. The code is the following : handler = serial.Serial(port=self.portname, baudrate=9600, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stHello, I'm trying to access a hardware board of my company through a serial connection using a Python script and the pyserial module. I use Python 2.7.1 with Ubuntu 11.04 (pyserial is the package python- serial with version 2.5.2, http://pyserial.sourceforge.net/pyserial_api.html). The board to which I'm trying to connect works correctly with serial as some other guys did some TCL scripts to manage it. My problem is that every time I open a new connection, the device is reset. I'd like to not have the device reset. The code is the following : handler = serial.Serial(port=self.portname, baudrate=9600, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, timeout=None, dsrdtr=False) # here the device is reset ... handler.close() I found the following post http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1274205532 but I haven't tested it yet as I don't like the idea to change files managed by the system (and it is for Windows). Is there any possibility to not reset the device when opening the connection ? Thanks, Yorickopbits=serial.STOPBITS_ONE, timeout=None, dsrdtr=False) # here the device is reset ... handler.close() I found the following post http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1274205532 but I haven't tested it yet as I don't like the idea to change files managed by the system (and it is for Windows). Is there any possibility to not reset the device when opening the connection ? Thanks, Yorick -- http://mail.python.org/mailman/listinfo/python-list
access to the namespace of a function from within its invocation
In the example below, the attribute "data" is added to a function object. "me" can be used to get the function when it is invoked using an identifier that matches the "co_name" attribute of function's code object. Can anyone conjure an example of accessing fun2.data from without prior knowledge of the value of fun2.f_code.co_name? ###code begin### #!/bin/python import sys def me(): t = sys._getframe(0) return t.f_back.f_globals[t.f_back.f_code.co_name] def fun1(): m = me print me().data def makefun () : def tmpfunc(): print 'need something like me().data' return tmpfunc fun1.s = fun1 fun1.data=['one', 'two', 'three'] fun1() fun2 = makefun() fun2.data=['four', 'five','six'] fun2() ###code end### -- Poor Yorick -- http://mail.python.org/mailman/listinfo/python-list
install python to custom prefix with custom library directories
Today I needed to install python from source on linux to a custom path. /usr/lib/libtk8.3.so existed, but I wanted python to link to /my/custom/path/lib/libtk8.4.so. I had LDFLAGS set: LDFLAGS="-L/my/custom/path/lib -Wl,-rpath,$base/lib -Wl,--enable-new-dtags" configure looked like this: ./configure --prefix=/my/custom/path/python-2.5.1 --enable-shared but python always linked against /usr/lib/libtk8.3.so instead of libtk8.4.so I ended up modifying setup.py (see below) but there must be a more user-friendly way to do this. Right? Thank you for your time! BTW, I don't have root access on this machine --- setup.py.original 2007-07-17 12:51:27 -04:00 +++ setup.py2007-07-17 13:21:57 -04:00 @@ -293,10 +293,14 @@ # lib_dirs and inc_dirs are used to search for files; # if a file is found in one of those directories, it can # be assumed that no additional -I,-L directives are needed. +self.compiler.library_dirs.insert(0, +'/my/custom/path/lib') lib_dirs = self.compiler.library_dirs + [ '/lib64', '/usr/lib64', '/lib', '/usr/lib', ] +self.compiler.include_dirs.insert(0, +'/my/custom/path/include') inc_dirs = self.compiler.include_dirs + ['/usr/include'] exts = [] -- Poor Yorick -- http://mail.python.org/mailman/listinfo/python-list
Python3: sorting image objects according to a cmp function
I'm looking for a Python3-compatible way to sort a list of PIL image objects based on a computed difference between the two images. In 2.x, this would work: imagelist.sort(cmp=image_diff(a,b)) Maybe this could be done by creating a new class with the appropriate __lt__, gt__, __eq__ methods, but that seems like more work than should be necessary. Any suggestions? -- Yorick -- http://mail.python.org/mailman/listinfo/python-list
__future__ and unrecognised flags
I have a future statement in a script I intend to work on 2.6 and 3. Shouldn't __future__ statements basically be noops for versions that already support the feature? doctest is complaining about compiler flags. This illustrates the problem: Python 3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import unicode_literals >>> src = 'a = "hello"' >>> c1 = compile(src,'','exec',unicode_literals.compiler_flag) Traceback (most recent call last): File "", line 1, in ValueError: compile(): unrecognised flags -- Yorick -- http://mail.python.org/mailman/listinfo/python-list
__future__ and compile: unrecognised flags
I have a future statement in a script which is intended to work in 2.6 and 3. Shouldn't compile flags in __future__ objects essentially be noops for versions that already support the feature? doctest is complaining about unrecognised flags. This illustrates the problem: Python 3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import unicode_literals >>> src = 'a = "hello"' >>> c1 = compile(src,'','exec',unicode_literals.compiler_flag) Traceback (most recent call last): File "", line 1, in ValueError: compile(): unrecognised flags -- Yorick -- http://mail.python.org/mailman/listinfo/python-list
loop performance in global namespace (python-2.6.1)
In the following snippet, the loop in the global namespace takes twice as long
as the loop in the function namespace. Why?
limit = 5000
def f1():
counter = 0
while counter < limit:
counter += 1
time1 = time.time()
f1()
print(time.time() - time1)
print('number of locals: ', len(locals()))
time1 = time.time()
counter = 0
while counter < limit:
counter += 1
print(time.time() - time1)
print('number of locals: ', len(locals()))
--
Yorick
--
http://mail.python.org/mailman/listinfo/python-list
python-2.6.2 Exception: TypeError: "'NoneType' object is not callable" in ignored
The following code produces an error (python-2.6.2). Either of the following
eliminates the error:
. assign something besides mod1 (the newly-created module) to d1
. remove the call to shelve.open
Why is there an error produced in the first place? What is the interaction
between d1, mod1, and shelve about? This code runs without error in python-3.1
$ cat test1.py
import test2
newmodule = test2.load()
$ cat test2.py
import imp
import shelve
def load():
text='import test2\n'
text += '''print('hello from test3')\n'''
code = compile(text,'', 'exec')
mod1 = imp.new_module('newmodule')
newdict = mod1.__dict__
#newdict = {}
exec(code,newdict)
mod1
mode = mod1
d1['unique'] = mod1
#d1['unique'] = ''
return mod1
print('hello from test2')
d1 = {}
cache = shelve.open('persist')
$ python2.6 test1.py
hello from test2
hello from test3
Exception TypeError: "'NoneType' object is not callable" in ignored
Exception TypeError: "'NoneType' object is not callable" in ignored
--
Yorick
--
http://mail.python.org/mailman/listinfo/python-list
Re: python-2.6.2 Exception: TypeError: "'NoneType' object is not callable" in ignored
Terry Reedy wrote: > Poor Yorick wrote: >> The following code produces an error (python-2.6.2). > > You forgot to post the error traceback. > There was no traceback, but following John Machin's prodding, I read back through some older posts (including one of yours) which I hadn't guessed were relevant the first time around. It seems that the program itself was functioning properly, but when the interpreter exited, objects were being deleted in an order which did not permit orderly teardown of other objects. I hadn't thought to look, before, but despite the warnings, the exit status of the interpreter was 0. The solution to the errors was to register a teardown function in the module: import atexit def teardown(): del globals()['d1'] atexit.register(teardown) -- Yorick -- http://mail.python.org/mailman/listinfo/python-list
