Re: Packaging and deployment of standalone Python applications?
Hi Laura; and first off, thanks bunches for your comment. Am 17.09.2015 um 00:19 schrieb Laura Creighton: > Your problem is likely with the shared library search paths. Different distributions put them in different places. It's a real pain, and the reason why docker is getting more popular. Well I thought something like this but then again wondered whether this really would be the cause - after all, Thunderbird, Firefox, OpenOffice, Java and a bunch of other applications that are available as "binary" downloads for "generic Linux" do seem to work on RedHat/CentOS, Debian, Ubuntu without these issues. Are these all statically built? Would this be an option for distributing Python applications, as well? Or, other option: Would it work to, say, use venv, make sure there always is a Python of the same version on the target machine installed (say 3.4), and then distribute "just" the python parts without including the interpreter / binary itself? Thanks in advance and all the best, Kristian -- https://mail.python.org/mailman/listinfo/python-list
foldername change killed python
Heya, I just uninstalled Python 3.5 so I can reinstall it with the default path. Took me a day to figure out why my extra modules weren't importing in py2exe properly and why the Python for windows extensions kept on telling me I didn't have Python 3.5 installed while in fact I did. It wasn't a well known 64 bit/32 bit case this time but the fact that I installed Python 3.5 to C:\Python35 and changed the name to C:\Python 3.5 After that everything just went haywire cause the python for windows extensions where looking at the wrong folder and stuff was telling me that Python 3.5 didn't exist while IDLE was just sitting there in my start menu. It's a stupid thing but I know for sure a lot of people are going nuts because they did something like I did today. Kind Regards, Frank. -- https://mail.python.org/mailman/listinfo/python-list
Re: foldername change killed python
Still doesn't work with the default path. For some reason the script that worked 20 mins ago in IDLE using "import win32com.client" can't find the module anymore so I messed it up somewhere. 2015-09-17 1:45 GMT+02:00 Frank Huurman : > Heya, I just uninstalled Python 3.5 so I can reinstall it with the default > path. > > Took me a day to figure out why my extra modules weren't importing in > py2exe properly and why the Python for windows extensions kept on telling > me I didn't have Python 3.5 installed while in fact I did. > It wasn't a well known 64 bit/32 bit case this time but the fact that I > installed Python 3.5 to C:\Python35 > > and changed the name to C:\Python 3.5 > > After that everything just went haywire cause the python for windows > extensions where looking at the wrong folder and stuff was telling me that > Python 3.5 didn't exist while IDLE was just sitting there in my start menu. > > > It's a stupid thing but I know for sure a lot of people are going nuts > because they did something like I did today. > > > Kind Regards, > > Frank. > -- https://mail.python.org/mailman/listinfo/python-list
Sqlite pragma statement "locking_mode" set to "EXCLUSIVE" by default
hello I would like to have the Sqlite pragma statement "locking_mode" set to "EXCLUSIVE" by default (RO database). Does this need to be compiled in? How might this be achieved? There is some performance to be gained. I have a number of python scripts, and don't want to alter the pragma statement for every script. This computer never writes to the databases. thank you -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
Gregory Ewing writes: > My problem is that I find it difficult to remember that Python > considers 'in' to be a comparison operator. > > To me, comparison is something you do between things of the same kind, > whereas 'in' is a relationship between things of different > kinds. Calling it a comparison is like comparing apples and > oranges. Or apples and baskets of apples, or something. Ordinary binary operators not only combine things of the same type, they also produce a thing of that same type. So 'in' does not fit among them either. I feel it's _more_ at home among comparison operators. (Hm. That's 'operator' in a different sense.) -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging and deployment of standalone Python applications?
Am 16.09.15 um 21:29 schrieb Kristian Rink: Thanks, this already is pretty close to what I need. Playing with this and virtualenv, I figured out that this way it's pretty easily possible to have isolated Python environments _locally_. However I failed to package one of these environments and move it to, say, from my Ubuntu development host to a remote Debian server, I end up with errors like these while trying to run the Python off the environment on that host: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found This is a typical problem on Linux when moving binaries between different distributions. The libc is the most basic library, used by programs compiled from C (virtually everything). Fortunately it has a very good version management which makes it backwards compatible. Have you compiled everything from source? The solution is to compile everything on the oldest machine which you can get hold of. If you want portable binaries on Linux, I suggest that you carry along with your program all shared libraries except libc & friends (libm, libstdc++,...), which really are part of the operating system, and to setup a VM with an old libc6-distribution where you compile your stuff. For instance try Ubuntu 10.04 LTS. There is a nice management tools for these VMs called Vagrant https://www.vagrantup.com/ If you think, that this is lots of tedious work, you are right - deployment is hard work. Ideally, you would have Python installation that can be carried along as a binary directory and in variants for all major OSes. In the case of the Java VM this is just easier because somebody else already did the hard work. On Windows, I used PortablePython in the past for a similar project, but this is gone. Another possibility is ActivePython, but I think the free license does not allow to carry it to other computers - in principle it could work. IMHO this is one of the lacks of CPython. Distributing source is not always practical, especially if the project involves modules written in C, or a large number of 3rd party libraries. To provide linux binaries as .rpm and .deb, as suggested elsewhere in this thread, is even more cumbersome than binaries in this case - you'd have to set the right dependencies for a huge variety of distributions, such that the package manager pulls, e.g. "python-pillow" on one distro and "libpillow" on another etc. A well maintained portable distribution for all major platforms could substantially ease that out. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging and deployment of standalone Python applications?
On Thu, Sep 17, 2015 at 5:24 PM, Christian Gollwitzer wrote: > IMHO this is one of the lacks of CPython. Distributing source is not always > practical, especially if the project involves modules written in C, or a > large number of 3rd party libraries. To provide linux binaries as .rpm and > .deb, as suggested elsewhere in this thread, is even more cumbersome than > binaries in this case - you'd have to set the right dependencies for a huge > variety of distributions, such that the package manager pulls, e.g. > "python-pillow" on one distro and "libpillow" on another etc. A well > maintained portable distribution for all major platforms could substantially > ease that out. If you want to know what's state of the art there - and even more so: if you want to push the state of the art - join the distutils-sig mailing list: https://mail.python.org/mailman/listinfo/distutils-sig This is where these kinds of questions will be discussed, and (hopefully!) solved. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python how to load multiple C libraries
hi:
I use ctypes load multiple C libraries. Code like this:
.
history = CDLL("/usr/lib/libhistory.so", mode=RTLD_GLOBAL|RTLD_LAZY)
ncurses = CDLL("/usr/lib/libncurses.so", mode=RTLD_GLOBAL|RTLD_LAZY)
readline = CDLL("/usr/lib/libreadline.so", mode=RTLD_GLOBAL|RTLD_LAZY)
...
When I execute my python scripts, it come out followed error:
/var/app/python/scripts # python test.py
Traceback (most recent call last):
File "test.py", line 4, in
history = CDLL("/usr/lib/libhistory.so", mode=RTLD_GLOBAL|RTLD_LAZY)
NameError: name 'RTLD_LAZY' is not defined.
So, I checked my ctypes source code, I found RTLD_LAZY defined in
dlfcn.h header file like this:
/* The MODE argument to `dlopen' contains one of the following: */
#define RTLD_LAZY 0x1 /* Lazy function call binding. */
#define RTLD_NOW 0x2 /* Immediate function call binding. */
#define RTLD_BINDING_MASK 0x3 /* Mask of binding time value. */
#define RTLD_NOLOAD 0x4 /* Do not load the object. */
#if 0 /* uClibc doesnt support these */
#define RTLD_DEEPBIND 0x8 /* Use deep binding. */
#endif
/* If the following bit is set in the MODE argument to `dlopen',
the symbols of the loaded object and its dependencies are made
visible as if the object were linked directly into the program. */
#define RTLD_GLOBAL 0x00100
/* Unix98 demands the following flag which is the inverse to RTLD_GLOBAL.
The implementation does this by default and so we can define the
value to zero. */
#define RTLD_LOCAL 0
/* Do not delete object when closed. */
#define RTLD_NODELETE 0x01000
The first of all, I have added followed codes in function:
PyMODINIT_FUNC init_ctypes(void) {...} in _ctypes.c file.
/* add RTLD_LAZY and RTLD_NOW definitions*/
PyModule_AddObject(m, "RTLD_LAZY", PyInt_FromLong(RTLD_LAZY));
PyModule_AddObject(m, "RTLD_NOW", PyInt_FromLong(RTLD_NOW));
So, Is there anybody know how the CDLL can accept mode flag:RTLD_LAZY?
On 09/16/2015 09:13 PM, Laura Creighton wrote:
In a message of Wed, 16 Sep 2015 17:35:18 +0800, "chenc...@inhand.com.cn" write
s:
hi:
I encountered a problem. I use ctypes load multiple C libraries, but
the libraries have dependence each other.So, how can i load these
libraries. For example, I have two libraries:A、B, but A depends on B, B
depends on A. So how do I load them? Is there anybody know how to do it?
I don't know how to do this with ctypes (which doesn't mean it cannot be
done, just that I haven't ever wanted to do this). What happens if you
make a small file that loads both separately and loads that one first?
It may be that you can get what you want with by loading the first lib
RTLD_LAZY instead of RTLD_NOW. see:
http://stackoverflow.com/questions/22591472/dyanamic-library-linking-by-rtld-lazy
see: this very old thread, maybe CTypes knows about it now.
http://osdir.com/ml/python.ctypes/2006-10/msg00029.html
But I have never tried.
These days I used cffi instead of ctypes.
If you use cffi https://pypi.python.org/pypi/cffi
there should not be any problem if you use ffi.set_source(),
only once, but mentioning both libs in the libraries=[...] argument.
Laura
--
https://mail.python.org/mailman/listinfo/python-list
Re: Packaging and deployment of standalone Python applications?
In a message of Thu, 17 Sep 2015 08:23:52 +0200, Kristian Rink writes: >Hi Laura; > >and first off, thanks bunches for your comment. > >Am 17.09.2015 um 00:19 schrieb Laura Creighton: > > >> Your problem is likely with the shared library search paths. >> Different distributions put them in different places. It's a real >> pain, and the reason why docker is getting more popular. > >Well I thought something like this but then again wondered whether this >really would be the cause - after all, Thunderbird, Firefox, OpenOffice, >Java and a bunch of other applications that are available as "binary" >downloads for "generic Linux" do seem to work on RedHat/CentOS, Debian, >Ubuntu without these issues. Are these all statically built? Would this >be an option for distributing Python applications, as well? Mozilla uses a hybrid static and binary build thing. http://www-archive.mozilla.org/build/static-build.html and confusingly calls that a static build. My Java didn't come as a generic Linux download. I had to use the debian package. Same for libreoffice. I needed a .deb for that. For instance, if you look at the libre office instructions it first hops up and down saying you should use whatever your package manager provides. https://www.libreoffice.org/get-help/install-howto/linux/ Then it leads to the wiki which leads to the download page http://www.libreoffice.org/download/libreoffice-fresh/ If you download from this page you will see that it detects what sort of linux you are running and gets you a .rmp or a .deb depending on what you need. That's 4 choices, because 32 bit and 64 bit is also different. If it makes a mistake and decides you need the wrong sort of binary package, you can demand that you get the sort you want. This will handle most of them, but if you need Gentoo linux you will have to do something else, and there are undoubtably other linux versions that don't understand .deb or .rpms Now go back to the wiki and read https://wiki.documentfoundation.org/Documentation/Install/Linux the section Terminal-Based Install As I warned you, it is a real horror. >Or, other option: Would it work to, say, use venv, make sure there >always is a Python of the same version on the target machine installed >(say 3.4), and then distribute "just" the python parts without including >the interpreter / binary itself? Getting a Python of the same version is rarely necessary. That's not where your problem is. Except that Python 3.x are not compatible with Python 2.x, the general rule is that later versions of Python are backwards compatible with earlier ones. If you can turn your pure python code into a python package, this will probably simplify your problem. But, no promises here. I don't know enough about what you are trying to do, and this is only a general rule of thumb. >Thanks in advance and all the best, >Kristian Here's the PyPy Story. PyPy is a fast version of Python written in Python. It has a JIT. On our download page: http://pypy.org/download.html These days PyPy is really popular. So there is a real official debian package, ubuntu package, red hat package, and a gentoo package and all the rest. Which means there is a real human being who is reponsible for making such things for each distro. This is a welcome outcome of being popular. It wasn't always that way. We had to make binaries for wherever we wanted to run (everywhere). The download page still contains a list of possible binaries. Linux x86 binary (32bit, tar.bz2 built on Ubuntu 12.04 - 14.04) (see [1]) Linux x86-64 binary (64bit, tar.bz2 built on Ubuntu 12.04 - 14.04) (see [1]) ARM Hardfloat Linux binary (ARMHF/gnueabihf, tar.bz2, Raspbian) (see [1]) ARM Hardfloat Linux binary (ARMHF/gnueabihf, tar.bz2, Ubuntu Raring) (see [1]) ARM Softfloat Linux binary (ARMEL/gnueabi, tar.bz2, Ubuntu Precise) (see [1]) ... Note 1 contains more language about if this is not your exact distro, it will not work. We say this all over the place and people still do not get it. Our binrary list used to be a whole lot longer. And the situation was impossible. We couldn't build pypys for every linux distro on the planet, because we didn't own every one. So we were dependent on having happy users make one from source, and giving it to us. Which people did. But it meant that every time we made a release we had to spend forever talking to people over irc or on the mailing list who couldn't get the source build to build. Make a symlink here, make a symlink there. When you add to the mix that building pypy, starting with CPython instead of an earlier version of PyPy can grind away for 3 hours and then fall flat over when you first try to run it because you didn't get the dependencies quite right It was nothing but pain. So when docker came out, we jumped at the chance to get out of this mess. It worked. We're deliriously happy with the result. And now we have portable binaries that run anywhere. Armin Rigo (I think) figure
Re: Einstein's Riddle
This is not true that only two percent of this world can solve this puzzle. May be the 2% will solve it by a quick look on the statements. -- https://mail.python.org/mailman/listinfo/python-list
pyserial and threads
I'm trying to create a simple program in Python that opens N serial
ports (through pyserial) and forward every byte received on one of those
ports to the other ports.
At startup I open the ports and create and start a thread to manage the
receiving. When a byte is received, I call the .write() method for all
the other ports.
It works, but sometimes it seems to block. I think I haven't used
correctly the threads.
Below is my code, I hope someone can help me.
Consider that I'm a newbie in python and I never used threads before.
import serial
import threading
import sys, os
import signal
import time
class Miniterm(object):
def __init__(self, port, baudrate):
self.serial = serial.Serial(port, baudrate, timeout=1)
def start(self, com_list):
self.alive = True
self.com_list = com_list
self._reader_alive = True
self.receiver_thread = threading.Thread(target=self.reader)
self.receiver_thread.setDaemon(True)
self.receiver_thread.start()
def stop(self):
self.alive = False
def reader(self):
try:
while self.alive and self._reader_alive:
data = self.serial.read(1)
if len(data) > 0:
for p in self.com_list:
if p[1] != self:
p[1].write(data)
except serial.SerialException:
self.alive = False
raise
def write(self, data):
self.serial.write(data)
if __name__ == "__main__":
ports = []
for com in sys.argv[1:]:
try:
miniterm = Miniterm(com, 38400)
except serial.SerialException:
sys.stderr.write("could not open port " + com)
sys.exit(1)
ports.append((com, miniterm))
for p in ports:
p[1].start(ports)
print("Port " + p[0] + " has started", flush=True)
while True:
time.sleep(1)
--
https://mail.python.org/mailman/listinfo/python-list
Re: pyserial and threads
On Thu, Sep 17, 2015 at 7:28 PM, pozz wrote: > At startup I open the ports and create and start a thread to manage the > receiving. When a byte is received, I call the .write() method for all the > other ports. > > It works, but sometimes it seems to block. I think I haven't used correctly > the threads. > Seems a fairly reasonable model. From what I'm seeing here, you start a thread to read from each serial port, but then those threads will make blocking writes to all the other serial ports. Is it possible that one of them is getting full? When I do this kind of thing with TCP/IP sockets, I usually end up having to go non-blocking in both directions, and maintaining a buffer of unsent text for each socket. You may find that you need to do the same thing here. Where's the code getting blocked? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python how to load multiple C libraries
In a message of Thu, 17 Sep 2015 15:41:26 +0800, "chenc...@inhand.com.cn" write
s:
> So, I checked my ctypes source code, I found RTLD_LAZY defined in
>dlfcn.h header file like this:
>/* The MODE argument to `dlopen' contains one of the following: */
>#define RTLD_LAZY 0x1 /* Lazy function call binding. */
>#define RTLD_NOW 0x2 /* Immediate function call binding. */
>#define RTLD_BINDING_MASK 0x3 /* Mask of binding time value. */
>#define RTLD_NOLOAD 0x4 /* Do not load the object. */
>#if 0 /* uClibc doesnt support these */
>#define RTLD_DEEPBIND 0x8 /* Use deep binding. */
>#endif
>
>/* If the following bit is set in the MODE argument to `dlopen',
>the symbols of the loaded object and its dependencies are made
>visible as if the object were linked directly into the program. */
>#define RTLD_GLOBAL 0x00100
>
>/* Unix98 demands the following flag which is the inverse to RTLD_GLOBAL.
>The implementation does this by default and so we can define the
>value to zero. */
>#define RTLD_LOCAL 0
>
>/* Do not delete object when closed. */
>#define RTLD_NODELETE 0x01000
>The first of all, I have added followed codes in function:
>PyMODINIT_FUNC init_ctypes(void) {...} in _ctypes.c file.
>
> /* add RTLD_LAZY and RTLD_NOW definitions*/
> PyModule_AddObject(m, "RTLD_LAZY", PyInt_FromLong(RTLD_LAZY));
> PyModule_AddObject(m, "RTLD_NOW", PyInt_FromLong(RTLD_NOW));
>
>So, Is there anybody know how the CDLL can accept mode flag:RTLD_LAZY?
It's a known open bug.
https://bugs.python.org/issue20276
Some people who have really needed to get this to work with ctypes have
modified the source for ctypes as discribed here:
http://osdir.com/ml/python.ctypes/2006-10/msg00029.html
I just stopped using ctypes and use cffi instead.
https://cffi.readthedocs.org/en/latest/
Laura
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 17/09/2015 02:33, Steven D'Aprano wrote: On Thu, 17 Sep 2015 10:06 am, Mark Lawrence wrote: On 16/09/2015 23:15, Sven R. Kunze wrote: On 16.09.2015 23:30, Mark Lawrence wrote: Barry John art is also art. So, why does Python not have Barry John art to define graphs and diagrams? Too colorful for a grammer? I'm not with you, sorry. Is "grammer" the US spelling of the UK "grammar"? Mark, take a close look at Sven's name, and his email address. When your German is better than his English, then you can pick on his spelling. I've a German 'O' level from 42 years ago, is that close enough? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging and deployment of standalone Python applications?
W dniu 14.09.2015 o 08:58, Kristian Rink pisze: [...] > > Any pointers, ideas, inspirations on that greatly appreciated - even > in total different ways if what I am about to do is completely off > anyone would do it in a Python environment. ;) Look at https://github.com/jordansissel/fpm/wiki - it's really nice tool, which converts python package into .deb, .rpm - so assuming that "everyone has some (2.x/3.x) python" is true, you can just ship .deb or .rpm files. reg m -- https://mail.python.org/mailman/listinfo/python-list
Automating Sphinx generated documentation
Hi I have setup Sphinx for my Python project. We keep all our code and documentation in Subversion. So, following changes to the Python code, I need to regenerate and commit the Sphinx generated documentation. I just wondered how people manage this. I'm thinking of using Jenkins (a continuous integration tool) to check for changes, regenerate the docs and check them in. Any suggestions please? Best regards David -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging and deployment of standalone Python applications?
Hi Laura; and first off, thank you very much for your very insightful response. Some thoughts on that: Am 17.09.2015 um 11:06 schrieb Laura Creighton: Mozilla uses a hybrid static and binary build thing. http://www-archive.mozilla.org/build/static-build.html and confusingly calls that a static build. My Java didn't come as a generic Linux download. I had to use the debian package. Same for libreoffice. I needed a .deb for that. Ah ok. I haven't looked too deep into Mozilla or LibreOffice, but I know there are Firefox Linux und Linux 64bit downloads that, once unpacked, will run on Debian, Ubuntu, Fedora and any other distribution I tried so far. In LibreOffice, we do have some bundle (we didn't built ourselves) living somewhere in /opt, being copied to various production machines and this, too, runs on Debian and on CentOS without issues. I do have LibreOffice (off the Ubuntu ppa) installed on my workstation, but not on the production environment also because the LibreOffice in the Ubuntu repos, as far as I can tell, will pull X as dependency while we run headless servers. Similar about Java - here, at least in Ubuntu or Debian, in some situations I used Debian facilities to create deb packages out of the official Java download which is either an rpm or a tgz. That's why I wondered in the first place: In our current deployment of (Java) services, the Java runtime gets bundled with the service for some systems, zipped, moved to the host and started there. This works well across all Linux systems, as long as they are 64bit so far. That's why I tried doing the same for Python and initially thought about this in the first place. ;) [LibreOffice] If you download from this page you will see that it detects what sort of linux you are running and gets you a .rmp or a .deb depending on what you need. That's 4 choices, because 32 bit and 64 bit is also different. Well - yes, but have you so far tried unpacking, say, the rpm manually and running the files in there on Debian? Also, it's interesting to see they "just" make a difference between deb and rpm (32bit and 64bit of course). This would end up with the same deb being installed to Debian or Ubuntu - which works, while copying a Python interpreter binary from an Ubuntu to a Debian machine obviously doesn't seem to work. So in some ways they *do* get some sort of portability in this... ? If you can turn your pure python code into a python package, this will probably simplify your problem. But, no promises here. I don't know enough about what you are trying to do, and this is only a general rule of thumb. I will have a look at this, then, thanks. :) So far, this morning I followed the venv approach, created a venv locally on my Ubuntu development workstation, made sure to have the same python version (3.4) installed on the server (built from source in Debian), and then copied the whole venv structure (including my application) to that machine, replacing only the link to the python binary in the venv (which lives in /usr/local on the Debian system). So far this works, and if this generally would work, it seems an acceptable way to me. :) PyPy is a fast version of Python written in Python. It has a JIT. On our download page:http://pypy.org/download.html Neat. I just read about it but so far never actually used it. In our environment, Jython is pretty familiar (because mostly we're still a Java house and Jython integrates rather well with Java), but PyPy is interesting, definitely. So when docker came out, we jumped at the chance to get out of this mess. It worked. We're deliriously happy with the result. And now we have portable binaries that run anywhere. Armin Rigo (I think) figured out how to hack the RPATH to get it to work most everywhere. I am not sure how that goes, but Armin will either explain it to you or point you at the correct document to read if you ask. He's very nice that way. I will have a look at this and happily get back to this if it will become necessary. :) Two things come to mind, however (feel free to take this off list as I am unsure whether this still relates to Python): (a) Why is distributing PyPy so difficult, after all? From where I stand, by now I see this a "Python implementation on top of Python". How does this relate to (C)Python? How much of the PyPy core is actually platform dependent? (b) How did / does Docker help you here? So far I just experienced Docker as a solution to easily manage loads of virtual machines on top of certain machine templates; I haven't made much use of it so far nevertheless... Thanks very much anyway, all the best! Kristian -- https://mail.python.org/mailman/listinfo/python-list
Re: pyserial and threads
On Thu, 17 Sep 2015 11:28:04 +0200, pozz wrote:
> I'm trying to create a simple program in Python that opens N serial
> ports (through pyserial) and forward every byte received on one of those
> ports to the other ports.
>
> At startup I open the ports and create and start a thread to manage the
> receiving. When a byte is received, I call the .write() method for all
> the other ports.
>
> It works, but sometimes it seems to block. I think I haven't used
> correctly the threads.
>
> Below is my code, I hope someone can help me.
>
> Consider that I'm a newbie in python and I never used threads before.
>
>
> import serial import threading import sys, os import signal import time
>
> class Miniterm(object):
>def __init__(self, port, baudrate):
> self.serial = serial.Serial(port, baudrate, timeout=1)
>
>def start(self, com_list):
> self.alive = True self.com_list = com_list self._reader_alive =
> True self.receiver_thread = threading.Thread(target=self.reader)
> self.receiver_thread.setDaemon(True) self.receiver_thread.start()
>
>def stop(self):
> self.alive = False
>
>def reader(self):
> try:
>while self.alive and self._reader_alive:
> data = self.serial.read(1)
>if len(data) > 0:
>for p in self.com_list:
> if p[1] != self:
>p[1].write(data)
> except serial.SerialException:
>self.alive = False raise
>
>def write(self, data):
> self.serial.write(data)
>
> if __name__ == "__main__":
>ports = []
>for com in sys.argv[1:]:
> try:
>miniterm = Miniterm(com, 38400)
> except serial.SerialException:
>sys.stderr.write("could not open port " + com) sys.exit(1)
> ports.append((com, miniterm))
> for p in ports:
>p[1].start(ports)
>print("Port " + p[0] + " has started", flush=True)
> while True:
>time.sleep(1)
I would like to know more about how many serial ports are connected &
what the equipment they are connected to does and expects.
I can see the data being transmitted snowballing & running away in a +ve
feedback loop very easily.
--
The only "ism" Hollywood believes in is plagiarism.
-- Dorothy Parker
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, 17 Sep 2015 10:56:07 +0100, Mark Lawrence wrote: > On 17/09/2015 02:33, Steven D'Aprano wrote: >> On Thu, 17 Sep 2015 10:06 am, Mark Lawrence wrote: >> >>> On 16/09/2015 23:15, Sven R. Kunze wrote: On 16.09.2015 23:30, Mark Lawrence wrote: > Barry John art is also art. So, why does Python not have Barry John > art to define graphs and diagrams? Too colorful for a grammer? >>> >>> I'm not with you, sorry. Is "grammer" the US spelling of the UK >>> "grammar"? >> >> Mark, take a close look at Sven's name, and his email address. When >> your German is better than his English, then you can pick on his >> spelling. >> >> > I've a German 'O' level from 42 years ago, is that close enough? No -- Awright, which one of you hid my PENIS ENVY? -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 17/09/2015 13:07, alister wrote: On Thu, 17 Sep 2015 10:56:07 +0100, Mark Lawrence wrote: On 17/09/2015 02:33, Steven D'Aprano wrote: On Thu, 17 Sep 2015 10:06 am, Mark Lawrence wrote: On 16/09/2015 23:15, Sven R. Kunze wrote: On 16.09.2015 23:30, Mark Lawrence wrote: Barry John art is also art. So, why does Python not have Barry John art to define graphs and diagrams? Too colorful for a grammer? I'm not with you, sorry. Is "grammer" the US spelling of the UK "grammar"? Mark, take a close look at Sven's name, and his email address. When your German is better than his English, then you can pick on his spelling. I've a German 'O' level from 42 years ago, is that close enough? No Oh, I'm hurt :( -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, 17 Sep 2015 02:10:44 -0400, Random832 wrote: > On Wed, Sep 16, 2015, at 21:25, Steven D'Aprano wrote: >> So what? The intended purpose of `is` and `==` is not to return True. >> It is >> to perform a comparison which may return False, or True. > > Yeah, but there's no point in doing a comparison unless you're doing it > in a context where it *might* return true. Semantics matter. Have we all suddenly suffered a mass outbreak of early onset Alzheimer's Disease? :-) How about the most common use of `is` of all? if some_object is None: ... Next thing we know, people will be claiming that => is an operator *wink* -- Steven D'Aprano -- https://mail.python.org/mailman/listinfo/python-list
Re: Automating Sphinx generated documentation
If you have watchdog installed: https://pypi.python.org/pypi/watchdog Jacob Kaplan Moss came up with this very nice one liner to do this. $ watchmedo shell-command \ --patterns="*.txt" \ --ignore-pattern='_build/*' \ --recursive \ --command='make html' change to .rst if that is what your Sphinx docs make, etc. -- https://mail.python.org/mailman/listinfo/python-list
Re: pyserial and threads
Il 17/09/2015 14:00, alister ha scritto: I would like to know more about how many serial ports are connected One real serial port and two virtual serial ports, created by com0com (it's a free virtual serial port for Windows). what the equipment they are connected to does and expects. Raw bytes arranged in a well defined protocol. I'm the author of the protocol and equipments :-) I can see the data being transmitted snowballing & running away in a +ve feedback loop very easily. No, because the byte received by first COM port is forwarded/transmitted to all the OTHERS COM ports in the list. -- https://mail.python.org/mailman/listinfo/python-list
Re: pyserial and threads
Il 17/09/2015 15:04, Dennis Lee Bieber ha scritto: On Thu, 17 Sep 2015 12:00:08 + (UTC), alister declaimed the following: I can see the data being transmitted snowballing & running away in a +ve feedback loop very easily. Especially if a few of the remote devices are configured to ECHO data... No ECHO. Main thing I'd probably change is... Since the COM port identification is already being provided during initialization of the handler object, why maintain a list of (com, handler) pairs, and the subsequent subscripting -- just save the com port as an attribute of the object. One could also make a copy of the object list in the start method, and at that point, scan the list and remove that one's own identity. That would remove the need for always testing "is the object I'm about to send to really me?" Ok, they are optimizations, but I don't think they solve my issue. -- https://mail.python.org/mailman/listinfo/python-list
Re: pyserial and threads
Il 17/09/2015 11:42, Chris Angelico ha scritto: On Thu, Sep 17, 2015 at 7:28 PM, pozz wrote: At startup I open the ports and create and start a thread to manage the receiving. When a byte is received, I call the .write() method for all the other ports. It works, but sometimes it seems to block. I think I haven't used correctly the threads. Seems a fairly reasonable model. From what I'm seeing here, you start a thread to read from each serial port, but then those threads will make blocking writes to all the other serial ports. Is it possible that one of them is getting full? When I do this kind of thing with TCP/IP sockets, I usually end up having to go non-blocking in both directions, and maintaining a buffer of unsent text for each socket. You may find that you need to do the same thing here. How to have a non-blocking write? Maybe the problem happens when port 1 thread is in .read() (it blocks for 1 second) and port 2 thread tries to write one byte (that was just received) to port 1. Where's the code getting blocked? I don't knwo exactly. I can only see no more bytes are received on COM ports. -- https://mail.python.org/mailman/listinfo/python-list
Re: pyserial and threads
On Thu, Sep 17, 2015 at 11:26 PM, pozz wrote:
> How to have a non-blocking write?
>
> Maybe the problem happens when port 1 thread is in .read() (it blocks for 1
> second) and port 2 thread tries to write one byte (that was just received)
> to port 1.
I'm not sure, as I've never worked with serial ports in this way. What
you'd want is some form of call that says "write these bytes if you
can, but don't if you can't, and just tell me how many you wrote". A
quick look at the pyserial docs suggests that you may be able to
accomplish this by opening the port with writeTimeout=0, or possibly
some other value (it'll wait that many seconds - float allowed -
before giving up).
If it returns 0, stating that the byte wasn't written, you'd need to
hang onto that byte until it can write successfully. I've no idea how
you'd go about knowing that. With TCP sockets, select.select() is your
friend; if you're really lucky, pyserial will work with the same kind
of structure.
>> Where's the code getting blocked?
>
> I don't knwo exactly. I can only see no more bytes are received on COM
> ports.
Here's a way to test: Bracket each potentially-blocking call with a
status update, and then have your main loop collect the statuses and
print them out. Something like this:
def reader(self):
try:
while self.alive and self._reader_alive:
self.status = 'R' # Reading
data = self.serial.read(1)
self.status = 'P' # Processing
if len(data) > 0:
for n,p in enumerate(self.com_list):
if p[1] != self:
self.status = n # Writing to port n
p[1].write(data)
self.status = 'P'
except serial.SerialException:
# This looks like a job for try/finally, actually
self.status = 'Z' # Dead
self.alive = False
raise
Then your main thread, instead of just sleeping forever, does this:
while True:
time.sleep(1)
print(" ".join(port.status for port in ports), end="\r", flush=True)
You should normally see most of the threads blocked on reading,
assuming that the traffic levels are lower than the ports' capacities.
If you start seeing them blocked on writing, chances are they'll all
be blocking on the same port, and that's the port that's holding you
up.
Caution: Code utterly untested. You may have to debug some stuff.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Writing a module to abstract a REST api
I need to write a module to abstract the RabbitMQ HTTP REST api. Before I do this, I would like to see how other projects have done similar in the hopes I make something consistent and generic etc. Does anyone regularly work with a library that abstracts a REST API and can recommend it for review? Thanks, jlc -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a module to abstract a REST api
On 2015-09-17, Joseph L. Casale wrote: > I need to write a module to abstract the RabbitMQ HTTP REST api. > Before I do this, I would like to see how other projects have done > similar in the hopes I make something consistent and generic etc. > > Does anyone regularly work with a library that abstracts a REST API > and can recommend it for review? There is https://pypi.python.org/pypi/librabbitmq ? -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a module to abstract a REST api
> There is https://pypi.python.org/pypi/librabbitmq ? Hi Jon, That is the AMQP client that utilizes the c extensions, I am writing a module to interact with a plugin that exposes a REST API. So I am not really after anything AMQP specific, just a pointer to a project that abstracts anything with a REST API so I can see how they work with requests in an async nature. Thanks, jlc -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a module to abstract a REST api
On 2015-09-17, Joseph L. Casale wrote: >> There is https://pypi.python.org/pypi/librabbitmq ? > > Hi Jon, > That is the AMQP client that utilizes the c extensions, I am writing a > module to interact with a plugin that exposes a REST API. > > So I am not really after anything AMQP specific, just a pointer to > a project that abstracts anything with a REST API so I can see how > they work with requests in an async nature. There's a bunch of Python Twitter libraries listed at the link below, they're all using a REST API? https://dev.twitter.com/overview/api/twitter-libraries -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a module to abstract a REST api
In a message of Thu, 17 Sep 2015 14:44:00 -, "Joseph L. Casale" writes: >I need to write a module to abstract the RabbitMQ HTTP REST api. >Before I do this, I would like to see how other projects have done >similar in the hopes I make something consistent and generic etc. > >Does anyone regularly work with a library that abstracts a REST API >and can recommend it for review? > >Thanks, >jlc If I understand you: http://www.python-requests.org/en/latest/ is an example of what you are looking for? It's great. Also check out http://cramer.io/2014/05/20/mocking-requests-with-responses/ if you need to mock requests. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a module to abstract a REST api
> If I understand you: > http://www.python-requests.org/en/latest/ > > is an example of what you are looking for? > > It's great. > > Also check out > http://cramer.io/2014/05/20/mocking-requests-with-responses/ > > if you need to mock requests. Hi Laura, The twitter samples Jon sent were good. What I am after is examples of modules that are written to interact with REST services. Its just not something I have written a module for and I am keen to see how well written modules have been implemented. Thanks, jlc -- https://mail.python.org/mailman/listinfo/python-list
Re: Einstein's Riddle
On Thu, Sep 17, 2015 at 3:19 AM, wrote: > This is not true that only two percent of this world can solve this puzzle. > May be the 2% will solve it by a quick look on the statements. Are you replying to this thread? https://mail.python.org/pipermail/python-list/2001-March/063293.html I had to google to find it, because if you'll take a look at the date you'll notice that it's over fourteen years old. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, Sep 17, 2015 at 1:06 AM, Jussi Piitulainen wrote: > Ordinary binary operators not only combine things of the same type, they > also produce a thing of that same type. So 'in' does not fit among them > either. > > I feel it's _more_ at home among comparison operators. (Hm. That's > 'operator' in a different sense.) Comparison operators *are* binary operators. All that "binary" means is that it takes two arguments. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Fri, Sep 18, 2015 at 4:49 AM, Ian Kelly wrote: > On Thu, Sep 17, 2015 at 1:06 AM, Jussi Piitulainen > wrote: >> Ordinary binary operators not only combine things of the same type, they >> also produce a thing of that same type. So 'in' does not fit among them >> either. >> >> I feel it's _more_ at home among comparison operators. (Hm. That's >> 'operator' in a different sense.) > > Comparison operators *are* binary operators. All that "binary" means > is that it takes two arguments. I think what Jussi is saying is that int+int yields int, and float*float yields float, and so on - but even that is true only of the arithmetic operators, and not all of them (int/int -> float in Py3). But generalizing from "arithmetic operators" to "ordinary operators" is a little unfair, unless you assume that the sole purpose of programming is to represent algebra. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
Ian Kelly writes:
> On Thu, Sep 17, 2015 at 1:06 AM, Jussi Piitulainen wrote:
>> Ordinary binary operators not only combine things of the same type,
>> they also produce a thing of that same type. So 'in' does not fit
>> among them either.
>>
>> I feel it's _more_ at home among comparison operators. (Hm. That's
>> 'operator' in a different sense.)
>
> Comparison operators *are* binary operators. All that "binary" means
> is that it takes two arguments.
I confused two words. It's operation I meant, not operator. A binary
_operation_ is defined as any map X * X -> X (by Lawvere and Schanuel,
Lawvere and Rosebrugh, at least; let's allow division as close enough).
(The asterisk stands for the Cartesian product. I'm too lazy to look up
the proper Unicode character for it and not willing to see a non-ASCII
symbol come back to me in a mangled form again anyway. Not today.)
Then comparisons are not binary _operations_ except in a very restricted
case. Their types are of the form X * X -> W, where W stands for a set
of truth values, {True, False}. A comparison of truth-values could be
taken as a binary operation, W * W -> W; other comparisons, under this
definition, not.
And I'm saying 'in', being truth-valued, is more like a comparison than
a proper binary operation that has its value in the same set as its two
arguments. Proper binary operations produce results that can be fed back
to them, as in either ((x - y) - z) or (x - (y -z)).
((x < y) < z) or (x < (y < z)) does not usually make sense.
((x in y) in z) more or less fails.
(x in (y in z)) fails.
Just trying to explain what I had in mind when I said that I feel that
'in' is more at home with comparisons (where it is now) than with, hm,
arithmetic operations.
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
Chris Angelico writes: > On Fri, Sep 18, 2015 at 4:49 AM, Ian Kelly wrote: >> On Thu, Sep 17, 2015 at 1:06 AM, Jussi Piitulainen >> wrote: >>> Ordinary binary operators not only combine things of the same type, they >>> also produce a thing of that same type. So 'in' does not fit among them >>> either. >>> >>> I feel it's _more_ at home among comparison operators. (Hm. That's >>> 'operator' in a different sense.) >> >> Comparison operators *are* binary operators. All that "binary" means >> is that it takes two arguments. > > I think what Jussi is saying is that int+int yields int, and > float*float yields float, and so on - but even that is true only of > the arithmetic operators, and not all of them (int/int -> float in > Py3). But generalizing from "arithmetic operators" to "ordinary > operators" is a little unfair, unless you assume that the sole purpose > of programming is to represent algebra. Yes, that's what I was trying to say, though I should have used the word "operation" not "operator". The operators that denote something like operations are routinely used to feed their values back to the same or related operations; doing that with truth-valued operators does not often make sense; their results are combined with and, or, and not instead. I can easily make up special cases myself, but now I'm trying to think of typical uses and say that Python got this quite right. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 17.09.2015 08:39, Gregory Ewing wrote: Sven R. Kunze wrote: Btw. ASCII art is also art. So, why does Python not have ASCII art to define graphs and diagrams? Nowadays it would have to support Unicode art. Mustn't leave out all the world's non-English-speaking artists! How do I debug and more importantly fix graphs and diagrams made of non-English Unicode art? o.O -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a module to abstract a REST api
Well, I would be interested in seeing such a module as well. Most modules and frameworks, I know, providing REST and interacting with REST are more like traditional SOAP-like web services. You got your functions which have a 1-to-1 correspondence with some resource URLs and that's it. Actually REST is far more flexible than that, thus I still would love to see an authentic REST module. Best, Sven On 17.09.2015 16:44, Joseph L. Casale wrote: I need to write a module to abstract the RabbitMQ HTTP REST api. Before I do this, I would like to see how other projects have done similar in the hopes I make something consistent and generic etc. Does anyone regularly work with a library that abstracts a REST API and can recommend it for review? Thanks, jlc -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Thu, Sep 17, 2015, at 16:24, Jussi Piitulainen wrote: > And I'm saying 'in', being truth-valued, is more like a comparison than > a proper binary operation that has its value in the same set as its two > arguments. The problem is that except for very specialized cases (strings), the two arguments are not (semantically, at least) in the same set as each other, either. It may be "more" like a comparison, but it's not *really* like either one. > Just trying to explain what I had in mind when I said that I feel that > 'in' is more at home with comparisons (where it is now) than with, hm, > arithmetic operations. Why does it have to be either one? I don't even think chaining should work for all *actual* comparison operations. Say you have this statement: (1) a < b = c <= d While it may *actually* mean this: (2) a < b and b = c and c <= d It *semantically* means this: (3) a < b and a < c and a < d and b = c and b <= d and c <= d The ones that are included logically imply the ones that are not, for any sane definition of these operators. And if your operators *aren't* sane, it's better to be explicit about what you are doing. It should not be applied to any combination of operations that cannot meaningfully be read as such a statement (e.g. mixing directions of less/greater comparisons, or including in, is not, or != at all), or to any values expected to have (2) not imply (3). It being *easier to implement* to have comparison operators be a single class and have chaining apply equally to all of them may be an excuse for the language to allow it, but it's certainly not an excuse for *actually* using it from a standpoint of good style and readability. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 2015-09-17 22:46, Sven R. Kunze wrote: > >> Btw. ASCII art is also art. So, why does Python not have ASCII > >> art to define graphs and diagrams? > > > > Nowadays it would have to support Unicode art. Mustn't > > leave out all the world's non-English-speaking artists! > > How do I debug and more importantly fix graphs and diagrams made of > non-English Unicode art? o.O Um, use a decent editor? I mean, even GNU ed(1) handles UTF-8 just fine, as do Vim & Emacs. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
Random832 : > It being *easier to implement* to have comparison operators be a > single class and have chaining apply equally to all of them may be an > excuse for the language to allow it, but it's certainly not an excuse > for *actually* using it from a standpoint of good style and > readability. In general, I don't like such caveats. Either something is in the language or it is not. You don't have to use all language features (I certainly don't), but if somebody takes advantage of them, you shouldn't consider it bad style. So if you don't like if prev_node is not node in excluded: ... take your complaints to whoever accepted the syntax in the language. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 17.09.2015 23:38, Marko Rauhamaa wrote: Random832 : It being *easier to implement* to have comparison operators be a single class and have chaining apply equally to all of them may be an excuse for the language to allow it, but it's certainly not an excuse for *actually* using it from a standpoint of good style and readability. In general, I don't like such caveats. Either something is in the language or it is not. You don't have to use all language features (I certainly don't), but if somebody takes advantage of them, you shouldn't consider it bad style. So if you don't like if prev_node is not node in excluded: ... take your complaints to whoever accepted the syntax in the language. One cannot blame it all to the languages designers. They try hard to optimize the programming workflows. The responsibility is evenly split between the users and the designers to use and to design reasonable, maintainable and robust language features. Best, Sven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 17.09.2015 23:26, Tim Chase wrote: On 2015-09-17 22:46, Sven R. Kunze wrote: Btw. ASCII art is also art. So, why does Python not have ASCII art to define graphs and diagrams? Nowadays it would have to support Unicode art. Mustn't leave out all the world's non-English-speaking artists! How do I debug and more importantly fix graphs and diagrams made of non-English Unicode art? o.O Um, use a decent editor? I mean, even GNU ed(1) handles UTF-8 just fine, as do Vim & Emacs. Since when has debugging and fixing something to do with the encoding? I somehow would need to actually understand and type those characters. Btw. PyCharm handles utf-8 as well. ;) Best, Sven -- https://mail.python.org/mailman/listinfo/python-list
Automating build from source (was: Automating Sphinx generated documentation)
David Aldrich writes: > I have setup Sphinx for my Python project. We keep all our code and > documentation in Subversion. It's a good idea to keep *source* files in VCS. It's a bad idea to keep automatically-generated files in VCS; it's especially bad to do so if they need to be generated again after changing the source files. > So, following changes to the Python code, I need to regenerate and > commit the Sphinx generated documentation. Instead, the build products – anything generated automatically by the computer, such as the compiled code, compiled documentation – should be flagged for “ignore” by the VCS, and never committed. The VCS should track only those files that humans edit directly. > I just wondered how people manage this. I'm thinking of using Jenkins > (a continuous integration tool) to check for changes, regenerate the > docs and check them in. Deploying the code base, whether for testing or to staging or production or wherever, should entail a build step. That build step is responsible for going from source-files-only, checked out from the VCS, to a complete ready-to-deploy tree of files. That build step should always start from a clean source tree, so that you always know the end result reflects what was committed to VCS. Build tools include old-school Makefile, or newer tools like Meson. Note that this is automated build. This is a different question from automated deployment (you might like Fabric for that), and is a different question from automated integration (you might like Jenkins for that). First, though, you need an automated build, so you can separate “what's tracked in VCS” versus “what's generated automatically”. -- \ “If we listen only to those who are like us, we will squander | `\ the great opportunity before us: To live together peacefully in | _o__)a world of unresolved differences.” —David Weinberger | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Automating build from source (was: Automating Sphinx generated documentation)
On 2015-09-17, Ben Finney wrote: > The VCS should track only those files that humans edit directly. While I agree that files automatically generated shouldn't be checked in to a VCS, I'm in favor of putting key binary files under VCS if they are required to do the build. We often check deveopment toolchains into Subversion. Subversion handles it just fine, and it saves having to come up with an entirely different scheme for archiving toolchain binaries. [If we build the toolchains ourselves, we will archive those sources as well.] -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Tuesday, September 15, 2015 at 5:36:52 PM UTC+8, Ben Finney wrote: > Jondy Zhao writes: > > > Pyarmor is a simple to use tool which is capable of importing or > > running encrypted Python script files. Moreover, it can apply encoding > > algorithms to your Python scripts, in order to help you protect them > > before you can distribute them. You may also generate license files > > with custom validity conditions. > > Protect them from whom? What is the threat model against which Pyarmor > is claimed to protect? Who is the attacker, who is being protected? > > > The program allows you to encrypt files, but to also open and run them > > as if no protection was applied. Moreover, it can run or import > > encrypted Python scripts in any target machine, only in specified > > machines or before a specified date. This aspect can be controlled by > > the creation of the license files: bound to a hard disk serial number > > or by an expiration date. > > So a Python file encrypted this way will be arbitrarily restricted in > how it can be inspected for debugging, performance monitoring, and > testing? > > This seems to explicitly treat the user of the Python software as a > hostile attacker. That is not a friendly or respectful position, and I > hope I misunderstand Pyarmor's operation. > > -- > \ "Any fool can write code that a computer can understand. Good | > `\ programmers write code that humans can understand." --Martin | > _o__) Fowler, _Refactoring_, 2000 | > Ben Finney Think that python developer is manufacturer, and he want to sell his product to the customers who don't know anything about programming. He don't hope his customers redistribute his product, that's protected by Pyarmor. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Fri, Sep 18, 2015 at 7:38 AM, Marko Rauhamaa wrote: > Random832 : > >> It being *easier to implement* to have comparison operators be a >> single class and have chaining apply equally to all of them may be an >> excuse for the language to allow it, but it's certainly not an excuse >> for *actually* using it from a standpoint of good style and >> readability. > > In general, I don't like such caveats. Either something is in the > language or it is not. > > You don't have to use all language features (I certainly don't), but if > somebody takes advantage of them, you shouldn't consider it bad style. > So if you don't like > > if prev_node is not node in excluded: > ... > > take your complaints to whoever accepted the syntax in the language. Strongly disagree. We have style guides because the language allows many things which are not good code. Given that Python programmers can't decide on whether the line limit should be 79, 80, 100, 120, or "79 but you can stretch to 100 if you have to", what should the syntax be coded to? It's just as bad style to produce a 500-character line as it is to abuse operator chaining, so should we take our complaints about over-long lines to "whoever didn't put a length limit into language syntax"? What about indenting with 5 spaces - should that have been disallowed at the language level? And what about misspelled comments - obviously they're bad style, so clearly Python should raise SyntaxError any time it comes across one, right? No. The language should be kept simple, and on matters of style, it should have MORE flexibility than we use - otherwise it's a straitjacket. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Fri, Sep 18, 2015 at 11:58 AM, Jondy Zhao wrote: > Think that python developer is manufacturer, and he want to sell his product > to the customers who don't know anything about programming. He don't hope his > customers redistribute his product, that's protected by Pyarmor. > The trouble with that thinking is that they _can_ redistribute his product. In fact, PyArmor isn't going to do anything about that. It might make it harder for them to reverse engineer that product, but it does nothing whatsoever for redistribution. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
Jondy Zhao writes: > Think that python developer is manufacturer, and he want to sell his > product to the customers who don't know anything about programming. Are you also assuming those customers have no-one they can talk with who knows programming? > He don't hope his customers redistribute his product, that's protected > by Pyarmor. Pyarmor is not going to stop them redistributing anything. If they're motivated to redistribute the code, this won't stop them. If they're motivated to examine what the code does, this will increase the effort but not stop them. At best, it will annoy customers who want to get someone's help in debugging the product. That sounds like an anti-feature. -- \ “This world in arms is not spending money alone. It is spending | `\ the sweat of its laborers, the genius of its scientists, the | _o__) hopes of its children.” —Dwight Eisenhower, 1953-04-16 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Tuesday, September 15, 2015 at 5:49:15 PM UTC+8, Chris Angelico wrote: > On Tue, Sep 15, 2015 at 7:21 PM, Jondy Zhao wrote: > > Pyarmor is dedicated to users who create their applications, components, > > scripts or any file with the help of the Python programming language. You > > may use this application to encrypt the files, in order to protect their > > content and your intellectual property, by encoding the scripts. > > > > > > The program allows you to encrypt files, but to also open and run them as > > if no protection was applied. > > If they can be run as if no protection had been applied, that > presumably means the loader is capable of decrypting them, right? So > what's to stop anyone from reading the loader, using it to decrypt the > actual code, and running it? > > ChrisA The loader only can see the compiled scripts as ast nodes, even if the load some tools could dump the separated ast node to bytecode and de-compile it, think of one script is divided into thousands of pieces, it's not easy to assemble them again. The final solution is to distribute the loader with encrypted scripts, only my own loader can run the encrypted scripts. Besides, -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Friday, September 18, 2015 at 10:06:30 AM UTC+8, Chris Angelico wrote: > On Fri, Sep 18, 2015 at 11:58 AM, Jondy Zhao wrote: > > Think that python developer is manufacturer, and he want to sell his > > product to the customers who don't know anything about programming. He > > don't hope his customers redistribute his product, that's protected by > > Pyarmor. > > > > The trouble with that thinking is that they _can_ redistribute his > product. In fact, PyArmor isn't going to do anything about that. It > might make it harder for them to reverse engineer that product, but it > does nothing whatsoever for redistribution. > > ChrisA The encrypted scripts could be distributed to bind to hard disk of computer, so the customers could not simplely copy them to somewhere else. Except they could reverse all the bytecodes, and pyarmor does make it harder to reverse bytecode to source. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Friday, September 18, 2015 at 10:27:35 AM UTC+8, Ben Finney wrote: > Jondy Zhao writes: > > > Think that python developer is manufacturer, and he want to sell his > > product to the customers who don't know anything about programming. > > Are you also assuming those customers have no-one they can talk with who > knows programming? > > > He don't hope his customers redistribute his product, that's protected > > by Pyarmor. > > Pyarmor is not going to stop them redistributing anything. If they're > motivated to redistribute the code, this won't stop them. If they're > motivated to examine what the code does, this will increase the effort > but not stop them. > > At best, it will annoy customers who want to get someone's help in > debugging the product. That sounds like an anti-feature. > > -- > \ "This world in arms is not spending money alone. It is spending | > `\ the sweat of its laborers, the genius of its scientists, the | > _o__) hopes of its children." --Dwight Eisenhower, 1953-04-16 | > Ben Finney For example, I develop a game by python. What I want to do is that the player or the agent could not simply copy the game to others. For the player or the agent, they needn't research the game. That's cases concerned by PyArmor. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
Jondy Zhao writes: > For example, I develop a game by python. What I want to do is that the > player or the agent could not simply copy the game to others. For the > player or the agent, they needn't research the game. Deciding for the customer what they may not do, on their own computer, is quite hostile. Please don't enable such restrictions. -- \ “We must find our way to a time when faith, without evidence, | `\disgraces anyone who would claim it.” —Sam Harris, _The End of | _o__) Faith_, 2004 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Fri, Sep 18, 2015 at 12:40 PM, Jondy Zhao wrote: > The loader only can see the compiled scripts as ast nodes, even if the load > some tools could dump the separated ast node to bytecode and de-compile it, > think of one script is divided into thousands of pieces, it's not easy to > assemble them again. > > The final solution is to distribute the loader with encrypted scripts, only > my own loader can run the encrypted scripts. So anyone who's going to run your program needs your loader. If someone wants to redistribute your code, s/he can simply distribute the loader as well - and you're right back where you started. You have still achieved nothing in terms of preventing redistribution. Please do not do this. Not only are you not achieving the goal you think you are, you're making a mess for people to have to deal with. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Friday, September 18, 2015 at 1:02:09 PM UTC+8, Chris Angelico wrote: > On Fri, Sep 18, 2015 at 12:40 PM, Jondy Zhao wrote: > > The loader only can see the compiled scripts as ast nodes, even if the load > > some tools could dump the separated ast node to bytecode and de-compile it, > > think of one script is divided into thousands of pieces, it's not easy to > > assemble them again. > > > > The final solution is to distribute the loader with encrypted scripts, only > > my own loader can run the encrypted scripts. > > So anyone who's going to run your program needs your loader. If > someone wants to redistribute your code, s/he can simply distribute > the loader as well - and you're right back where you started. You have > still achieved nothing in terms of preventing redistribution. > > Please do not do this. Not only are you not achieving the goal you > think you are, you're making a mess for people to have to deal with. > > ChrisA But the loader and the encrypted scripts could be bind to one fixed computer when I distribute them to end users, so the end users can't redistribute them to any other machines. Actually this is what some commercial software does. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Friday, September 18, 2015 at 11:06:25 AM UTC+8, Ben Finney wrote: > Jondy Zhao writes: > > > For example, I develop a game by python. What I want to do is that the > > player or the agent could not simply copy the game to others. For the > > player or the agent, they needn't research the game. > > Deciding for the customer what they may not do, on their own computer, > is quite hostile. Please don't enable such restrictions. > This is only one possible way to distribute encrypted scripts. As I thought the user of Pyarmor would be the producer of commercial software, so they could bind their license file to netcard, harddisk, cpu, etc. > -- > \ "We must find our way to a time when faith, without evidence, | > `\disgraces anyone who would claim it." --Sam Harris, _The End of | > _o__) Faith_, 2004 | > Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Automating build from source (was: Automating Sphinx generated documentation)
On Fri, Sep 18, 2015 at 9:37 AM, Ben Finney wrote: > David Aldrich writes: > >> I have setup Sphinx for my Python project. We keep all our code and >> documentation in Subversion. > > It's a good idea to keep *source* files in VCS. > > It's a bad idea to keep automatically-generated files in VCS; it's > especially bad to do so if they need to be generated again after > changing the source files. While I broadly agree, I would say this is a case of code smell rather than something outright verboten. There are a few situations where it's easier to commit the generated files as well; for instance, it can help you get around a bootstrapping problem - you use a previous build of Python to generate the frozen importlib, I think, and use that to build the next Python. (If that's not how CPython is built, my apologies; there are other projects that _do_ use this method, so it's just a flawed example.) If you don't commit the generated files, someone who wants to build from source has to first pick up a precompiled binary or somesuch. (Or, looking the other way: Disallowing generated files in source control restricts the generator to something that's already available on every build system.) But yes, as a general rule, I prefer to list all generated files in .gitignore or equivalent. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Automating build from source (was: Automating Sphinx generated documentation)
Ben Finney wrote: > David Aldrich writes: > >> I have setup Sphinx for my Python project. We keep all our code and >> documentation in Subversion. > > It's a good idea to keep *source* files in VCS. > > It's a bad idea to keep automatically-generated files in VCS; it's > especially bad to do so if they need to be generated again after > changing the source files. > >> So, following changes to the Python code, I need to regenerate and >> commit the Sphinx generated documentation. > > Instead, the build products – anything generated automatically by the > computer, such as the compiled code, compiled documentation – should be > flagged for “ignore” by the VCS, and never committed. > > The VCS should track only those files that humans edit directly. Isn't this a case of purity versus practicality? I imagine it might be nice to get fairly up-to-date documentation along with your source code checkout "for free". -- https://mail.python.org/mailman/listinfo/python-list
Re: Automating Sphinx generated documentation
David Aldrich wrote: > I have setup Sphinx for my Python project. We keep all our code and > documentation in Subversion. So, following changes to the Python code, I > need to regenerate and commit the Sphinx generated documentation. > > I just wondered how people manage this. I'm thinking of using Jenkins (a > continuous integration tool) to check for changes, regenerate the docs and > check them in. > > Any suggestions please? VCS typically have a few hooks to trigger scripts. I found "Making the Most of Commit Hooks with Subversion" http://www.linux-mag.com/id/7151/ Maybe you can use one of these to trigger a rebuilt of the docs. -- https://mail.python.org/mailman/listinfo/python-list
