Re: True == 1 weirdness
Random832 writes: > 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. Agreed. (In hierarchical set theories like ZFC, the membership predicate is between things of the same type, too: sets, the only things there are. That's hardly relevant in a typed setting.) >> 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. To keep the rules simple. To keep the language comprehensible, and then I can take the responsibility to keep my code comprehensible. > 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 I prefer (1) with no hesitation. I start to worry about typos and thinkos when the expression gets longer, and transitivity is such a fundamental notion that I'd rather blame myself for not understanding transitivity than the code for being too concise. (Also, == :) Would really hate to be forced to spell it all out if there were more complicated expressions in the chain. > 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. Yes. Those, in (1), are sane. > 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). I think (x != w != y) is ok to check that neither of x and y equals w. Even (x < w > y) seems surprisingly clear to me: it's comparing the extreme values to the middle value but not to each other. When in doubt, I might add a comment next to the expression. So in principle I agree. I just seem to tolerate more uses of chained comparisons than you. But longer chains are even rarer than 2-chains, and even 2-chains do not happen so often, and when they do happen, they tend to be (j < k < n). Shrug. > 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. It's also easier to document and comprehend, and on the whole they are a natural class. If something does go wrong, it's nice to find out that the explanation is simple, and not yet another special case that I was supposed to keep in mind. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Fri, Sep 18, 2015 at 3:55 PM, Jondy Zhao wrote: > 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. > Great. Please put a big warning notice on your application: ATTENTION ALL USERS The author of this program believes that he controls your usage of it, to the extent that a legitimately-purchased copy will refuse to run if you upgrade your computer's hardware. It is therefore recommended that you pirate this program as per XKCD 488. If you don't like this, don't use the program. At least then you'll be being honest. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Friday, September 18, 2015 at 3:27:28 PM UTC+8, Chris Angelico wrote: > On Fri, Sep 18, 2015 at 3:55 PM, Jondy Zhao wrote: > > 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. > > > > Great. Please put a big warning notice on your application: > > ATTENTION ALL USERS > The author of this program believes that he controls your usage of it, > to the extent that a legitimately-purchased copy will refuse to run if > you upgrade your computer's hardware. > It is therefore recommended that you pirate this program as per XKCD 488. > If you don't like this, don't use the program. > > > At least then you'll be being honest. > I know you hate it. But I have purchased some commercial software in this way before, a tool named ERWIN used to create relation database. The license I got from software provider is bind to the network card of my PC. I can't use this tool in any other machine. This is true case. The world is wide, maybe it's better to be tolerant of all things. > ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Thu, 17 Sep 2015 22:38:32 -0700, Jondy Zhao wrote: > 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. Making life difficult for legitimate users whilst causing Pirates minor difficulties at best (crack once distribute many).. Copyright legislation is what provides you with protection if you need it Commercial users do not risk running unlicensed software because of the damage a piracy case against them would cause to their business, not because they cant get it! -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Fri, Sep 18, 2015 at 6:05 PM, Jondy Zhao wrote: > I know you hate it. But I have purchased some commercial software in this way > before, a tool named ERWIN used to create relation database. The license I > got from software provider is bind to the network card of my PC. I can't use > this tool in any other machine. This is true case. > > The world is wide, maybe it's better to be tolerant of all things. Tolerant, perhaps - but that doesn't mean we encourage it. So, first and foremost, I *will not* code anything that encourages people to do this. And secondly, I generally will not buy anything that uses any form of DRM. (There are a *very* few exceptions.) Frankly, I'd prefer to pirate something and then make a donation to the author than buy it with DRM. So. no. No matter how wide the world is, I *WILL NOT* encourage the use of this software. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Friday, September 18, 2015 at 4:08:57 PM UTC+8, alister wrote: > On Thu, 17 Sep 2015 22:38:32 -0700, Jondy Zhao wrote: > > > 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. > > Making life difficult for legitimate users whilst causing Pirates minor > difficulties at best (crack once distribute many).. > > Copyright legislation is what provides you with protection if you need it > > Commercial users do not risk running unlicensed software because of the > damage a piracy case against them would cause to their business, not > because they cant get it! I agree with you absolutely. Maybe I can show you the purpose of Pyarmor by the following case: When we express a box, we can close this box with a lock, this equals encrypted scripts, or we just close the box without a lock. Pyarmor is just as this lock, it make the box more security, but it can not protect the box completely. -- https://mail.python.org/mailman/listinfo/python-list
.bat file trouble.
Hi, I have two files called module_scripts.py and build_q_scripts.bat. The problem being that when I go to run the bat file it produces a few errors which neither myself or the original owner of the files could understand. Errors: https://gyazo.com/c680f0d70cefe855c21ab0882d7c17b7 We originally thought that it was because it was missing the files: process_init.py and process_global_variables.py however they are right there in the same directory. File contents for the bat file: @echo off python process_init.py python process_global_variables.py python process_scripts.py @del *.pyc echo. echo __ echo. echo Script processing has ended. echo Press any key to exit. . . pause>nul If there is anyone with any idea how to fix it I'd love you forever :) -- https://mail.python.org/mailman/listinfo/python-list
Re: .bat file trouble.
On Fri, 18 Sep 2015 07:06 pm, bobert...@googlemail.com wrote: > Hi, > > I have two files called module_scripts.py and build_q_scripts.bat. > > The problem being that when I go to run the bat file it produces a few > errors which neither myself or the original owner of the files could > understand. Can you copy and paste the errors? I presume that they are words rather than pictures. That way, people who use a screen reader can hear them, and so can people who aren't able or willing to click on random URLs to strange websites that will do who knows what. > Errors: > > https://gyazo.com/c680f0d70cefe855c21ab0882d7c17b7 I get: SSL error:host(gyazo.com)!=cert(*.gyazo.com) and when I continue, I get: Your browser is not supported in Gyazo. so I'm afraid I cannot help you further unless I guess: > We originally thought that it was because it was missing the files: > process_init.py and process_global_variables.py however they are right > there in the same directory. I'm going to look into my crystal ball and see what the spirits say... They say... - is it a permissions problem? - is it a path problem? - what happens if you run this batch file instead? @echo off python -c "import sys; print(sys.version)" echo Press any key to exit. . . pause>nul Is the printed version the version you expect? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Einstein's Riddle
On Fri, 18 Sep 2015 04:44 am, Ian Kelly wrote: > 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. Time is relative. Perhaps the poster has been travelling at close to the speed of light, and for him it is only a few minutes after the original post was sent. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Einstein's Riddle
On Fri, Sep 18, 2015 at 10:33 AM, Steven D'Aprano wrote: > On Fri, 18 Sep 2015 04:44 am, Ian Kelly wrote: > > > 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. > > Time is relative. Perhaps the poster has been travelling at close to the > speed of light, and for him it is only a few minutes after the original > post was sent. > > > -- > Steven > > -- > https://mail.python.org/mailman/listinfo/python-list > I prefer to think that it just took him this long to do it. - Nick -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Fri, 18 Sep 2015 01:31:50 -0700, Jondy Zhao wrote: > On Friday, September 18, 2015 at 4:08:57 PM UTC+8, alister wrote: >> On Thu, 17 Sep 2015 22:38:32 -0700, Jondy Zhao wrote: >> >> > 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. >> >> Making life difficult for legitimate users whilst causing Pirates minor >> difficulties at best (crack once distribute many).. >> >> Copyright legislation is what provides you with protection if you need >> it >> >> Commercial users do not risk running unlicensed software because of the >> damage a piracy case against them would cause to their business, not >> because they cant get it! > > I agree with you absolutely. Maybe I can show you the purpose of Pyarmor > by the following case: > > When we express a box, we can close this box with a lock, this equals > encrypted scripts, or we just close the box without a lock. Pyarmor is > just as this lock, it make the box more security, but it can not protect > the box completely. And if the person at the other end looses the key it causes a great deal of trouble. Alternatively the highway man that holds up the delivery truck simply takes a pair of bolt cutters to the lock... yes it stops a casual snooper but that is all -- A statesman is a politician who's been dead 10 or 15 years. -- Harry S. Truman -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Friday, September 18, 2015 at 6:06:51 PM UTC+8, alister wrote: > On Fri, 18 Sep 2015 01:31:50 -0700, Jondy Zhao wrote: > > > On Friday, September 18, 2015 at 4:08:57 PM UTC+8, alister wrote: > >> On Thu, 17 Sep 2015 22:38:32 -0700, Jondy Zhao wrote: > >> > >> > 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. > >> > >> Making life difficult for legitimate users whilst causing Pirates minor > >> difficulties at best (crack once distribute many).. > >> > >> Copyright legislation is what provides you with protection if you need > >> it > >> > >> Commercial users do not risk running unlicensed software because of the > >> damage a piracy case against them would cause to their business, not > >> because they cant get it! > > > > I agree with you absolutely. Maybe I can show you the purpose of Pyarmor > > by the following case: > > > > When we express a box, we can close this box with a lock, this equals > > encrypted scripts, or we just close the box without a lock. Pyarmor is > > just as this lock, it make the box more security, but it can not protect > > the box completely. > > And if the person at the other end looses the key it causes a great deal > of trouble. > > Alternatively the highway man that holds up the delivery truck simply > takes a pair of bolt cutters to the lock... > > yes it stops a casual snooper but that is all > > In reality, when we leave the house, we lock the door, even the lock could not make sure the safe of our property. It's just make it difficult. It's same in the software world. Someone need the lock in both of the world. And if the highway man need leave the trunk for many days, whether they lock the truck or ask someone to take care of it or not. > > > -- > A statesman is a politician who's been dead 10 or 15 years. > -- Harry S. Truman -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
Jondy Zhao writes: > In reality, when we leave the house, we lock the door, even the lock > could not make sure the safe of our property. It's just make it > difficult. It's same in the software world. Someone need the lock in > both of the world. Yes, please don't encourage authors to put locks into people's computers that restrict those people's access to use them. And we won't come to install a lock that restricts your access to your house. In other words: Please don't arrogate to anyone the presumed right to restrict how people run programs on their own computers. -- \ “It ain't so much the things we don't know that get us in | `\trouble. It's the things we know that ain't so.” —Artemus Ward | _o__) (1834–1867), U.S. journalist | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Fri, 18 Sep 2015 07:26 am, Random832 wrote: > I don't even think chaining should > work for all *actual* comparison operations. I don't see why. Mathematicians chain comparisons all the time. If the language implements the same semantics as mathematicians already use, why do you dislike that? I don't see the benefit in restricting the language to something less expressive and more verbose than standard comparison chaining. > 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 Only if the comparisons are transitive, which they may not be. If they are, then something like this: a < b < c implies a < c too. But not all comparisons are transitive. > The ones that are included logically imply the ones that are not, for > any sane definition of these operators. Transitivity is *not* required for sanity. Nontransitivity is a very useful property for games, e.g. Rock-Paper-Scissors. It would be a very boring game indeed if the relation Rock < Paper < Scissors (where < means "is beaten by") was transitive. https://en.wikipedia.org/wiki/Nontransitive_game Intransitivity is likewise very important in consumer preferences, psychology, and voting (voter preferences are often nontransitive, e.g. voters prefer the Flog-em-and-hang-em Party over the Treehugger Party, the Treehugger Party over the Raving Monster Loony Party, and the Raving Monster Loony Party over the Flog-em-and-hang-em Party. [Aside: some voting systems do guarantee transitivity, but only at the cost of some other desirable property, such as no negative votes or no dictator. Other voting systems make nontransitive elections unlikely.] Other real-world examples include status hierarchies and pecking orders, and nontransitive dice. (Google it, I'm too lazy to provide a link.) > And if your operators *aren't* > sane, it's better to be explicit about what you are doing. Why? The results are perfectly well-defined however you write them. Transitivity or not, "Rock beats Scissors beats Paper beats Rock" means the same thing as "Rock beats Scissors, and Scissors beats Paper, and Paper beats Rock" except it's much shorter. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Fri, Sep 18, 2015, at 08:30, Steven D'Aprano wrote: > On Fri, 18 Sep 2015 07:26 am, Random832 wrote: > > > I don't even think chaining should > > work for all *actual* comparison operations. > > I don't see why. Mathematicians chain comparisons all the time. If the > language implements the same semantics as mathematicians already use, why > do you dislike that? Please provide a citation for this claim. > Only if the comparisons are transitive, which they may not be. My *entire point* is that it *shouldn't be used* for non-transitive comparisons!!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On 18/09/2015 13:41, Jondy Zhao wrote: [...] In reality, when we leave the house, we lock the door, even the lock could not make sure the safe of our property. It's just make it difficult. It's same in the software world. Someone need the lock in both of the world. I think you meant "in the *proprietary* software world". This discussion on the topic, and in particular this answer, on Stackoverflow are quite inspiring: http://stackoverflow.com/questions/261638/how-do-i-protect-python-code/261727#261727 Lorenzo. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Fri, 18 Sep 2015 10:47 pm, Random832 wrote: > On Fri, Sep 18, 2015, at 08:30, Steven D'Aprano wrote: >> On Fri, 18 Sep 2015 07:26 am, Random832 wrote: >> >> > I don't even think chaining should >> > work for all *actual* comparison operations. >> >> I don't see why. Mathematicians chain comparisons all the time. If the >> language implements the same semantics as mathematicians already use, why >> do you dislike that? > > Please provide a citation for this claim. Really? You're disputing that chained comparisons are a standard maths notation? https://en.wikipedia.org/wiki/Inequality_(mathematics)#Chained_notation Mathworld, for example, says: Solutions to the inequality |x-a|http://mathworld.wolfram.com/Inequality.html >> Only if the comparisons are transitive, which they may not be. > > My *entire point* is that it *shouldn't be used* for non-transitive > comparisons!!! And my point is that there is no good reason for such a restriction, even if it were technically possible to enforce (which it is not). The mathematical chained notation doesn't rely on, or imply, transitivity. Given a < b < c, *if* the operator is transitive, then AND ONLY THEN can you conclude that a < c, but that's not implied by the chaining. It happens to be true for real numbers, but it isn't necessarily true. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Fri, Sep 18, 2015, at 09:14, Steven D'Aprano wrote: > On Fri, 18 Sep 2015 10:47 pm, Random832 wrote: > > > On Fri, Sep 18, 2015, at 08:30, Steven D'Aprano wrote: > >> On Fri, 18 Sep 2015 07:26 am, Random832 wrote: > >> > >> > I don't even think chaining should > >> > work for all *actual* comparison operations. > >> > >> I don't see why. Mathematicians chain comparisons all the time. If the > >> language implements the same semantics as mathematicians already use, why > >> do you dislike that? > > > > Please provide a citation for this claim. > > Really? You're disputing that chained comparisons are a standard maths > notation? I'm disputing that chained comparisons are used for the particular combinations that I am actually arguing should not be used in python. Such as a < b > c or a != b != c [whereas a may or may not be equal to c] or a in b in c. Your claim seemed to be that these combinations *are* used, since you claimed that python implements the *same* semantics. -- https://mail.python.org/mailman/listinfo/python-list
Re: .bat file trouble.
Am 18.09.15 um 11:06 schrieb bobert...@googlemail.com:
Hi,
I have two files called module_scripts.py and build_q_scripts.bat.
The problem being that when I go to run the bat file it produces a
few errors which neither myself or the original owner of the files
could understand.
Errors:
https://gyazo.com/c680f0d70cefe855c21ab0882d7c17b7
The first error indicates, that you are running Python 3, and the script
was made for Python 2. In Python 3, print is a function so you need
parentheses around that print("Initializing...") - either fix that
or install Python 2.
The second error "TabError" also relates to it, it means that the file
mixes tabs and spaces for indentation. Fix it by expanding all tabs to
spaces in an editor.
We originally thought that it was because it was missing the files:
process_init.py and process_global_variables.py however they are
right there in the same directory.
Concerning that, windows usually runs a .bat file in the directory where
it is situated, so putting the python fies there /should/ work, but you
can also set this using the right-click menu (execute in...), if you
make a link to the desktop.
Christian
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pyarmor, guard your python scripts
On Friday, September 18, 2015 at 9:08:27 PM UTC+8, Lorenzo Sutton wrote: > On 18/09/2015 13:41, Jondy Zhao wrote: > [...] > > In reality, when we leave the house, we lock the door, even the lock could > > not make sure the safe of our property. It's just make it difficult. > > It's same in the software world. Someone need the lock in both of the world. > > I think you meant "in the *proprietary* software world". > Exactly. > This discussion on the topic, and in particular this answer, on > Stackoverflow are quite inspiring: > > http://stackoverflow.com/questions/261638/how-do-i-protect-python-code/261727#261727 > > Lorenzo. -- https://mail.python.org/mailman/listinfo/python-list
Re: Automating build from source (was: Automating Sphinx generated documentation)
On Fri, Sep 18, 2015 at 2:50 AM, Peter Otten <__pete...@web.de> wrote: > 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. > > > > 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". IMO, this is a decision an organization / individual has to make. But nothing stops anybody from using branch (and tags in hg) to differentiate pure source and pure build. On Thu, Sep 17, 2015 at 9:54 PM, Grant Edwards wrote: > 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. if you are okay with cloning a huge repository then I don't see a problem. You could have a separate repository for binary data, after VCS is just a software implements some smart versioning of an object in some format stored on somewhere. I know of no convenient mechanism to reduce size of my .git or my .hg once I committed my binary in my history. What I would do is provide the script a URL where you can get your files. Imagine infrastructure as code, I can't commit my oracle jdk/jre file all the time. I have a huge infrastructure to manage and it would be GBs to clone. It happened to me once and I regret it. Thanks. John -- https://mail.python.org/mailman/listinfo/python-list
Re: Automating build from source (was: Automating Sphinx generated documentation)
On 2015-09-18, John Wong wrote: > if you are okay with cloning a huge repository then I don't see a problem. Ah yes, if the repository got cloned a lot that would be a problem. The repository in question doesn't get cloned (it does get backed up). As I mentioned, it's subversion. Subversion isn't a distributed VCS like git. Subversion uses a single, central repository. -- Grant Edwards grant.b.edwardsYow! Are we laid back yet? at gmail.com -- 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. So a design pattern I use often is to create Python objects to represent objects returned from what ever api I am abstracting. For example I might create named tuples for static data I dont intend to change or for an object I can both query for and create, I might build a class to represent it. The problem now comes from the following: # foo now contains a handle to the remote api. foo = InstanceOfApiWrapper() # queues is a container of Queue classes. queues = foo.get_queues() queue = queues[0] queue.delete() In this case its possible for foo (InstanceOfApiWrapper) to inject a reference to itself so the delete() can actually make the call. # I want to create a queue from scratch... disparate_queue = Queue(x, y, z) # Now what happens? No handle to an api? disparate_queue.delete() An alternative is: foo.delete_queue(disparate_queue) That's not a pattern I prefer, what facilities in Python provide for a workaround here? One option is to put everything in one module and use globals. If the handle is initialized it'll just work. Problem with that is its not thread safe (without work) and I subscribe to one object per file (bloody hard with Python's import/load procedure. This is a design pattern I have struggled with in the past. jlc -- https://mail.python.org/mailman/listinfo/python-list
Elektra 0.8.13 with python plugins
Hello everyone, ## Python Plugins A technical preview of [python3] (http://git.libelektra.org/blob/master/src/plugins/python) and [python2](http://git.libelektra.org/blob/master/src/plugins/python2) plugins has been added. With them its possible to write any plugin, not only applications, with the python language. Note, they are a technical preview. They might have severe bugs and the API might change in the future. Nevertheless, it is already possible to, e.g. develop storage plugins with it. They are not included in `ALL` plugins. To use it, you have to specify it: -PLUGINS="ALL;python;python2" Thanks to Manuel Mausz for to this work on the plugins and the patience in all the last minute fixes! Feedback and Contribution is welcome! Join us on [github](http://libelektra.org). # Rest of release notes for Elektra 0.8.13 follows: For a html site visit: http://doc.libelektra.org/news/3c00a5f1-c017-4555-92b5-a2cf6e0803e3.html For general information about Elektra, see [http://libelektra.org] (http://libelektra.org) ## Elektrify-getenv getenv(3) is one of the most popular ways to retrieve configuration, even though it has many known problems: - no standard way to modify it - relogin (or restart of shell) necessary - names are flat (no hierarchical structure) - cannot be set for individual applications - different in at, cron and similar scripts With elektrify-getenv we wrote a solution which solves most of the problems. We use the LD_PRELOAD technique to *additionally* retrieve values from Elektra, and not only the environment. You simply can do: ```bash kdb set user/env/override/HTTP_PROXY "http://my.proxy:8080"; ``` This will set the `HTTP_PROXY` environment variable to `http://my.proxy:8080`. Configuration can be retrieved with `kdb get`: ```bash kdb get user/env/override/HTTP_PROXY lynx # or start another www-browser with the newly set HTTP_PROXY ``` Or using the man pages: kdb elektrify-getenv man man --elektra:MANWIDTH=40 Will use MANWIDTH 40 for this invocation of man man. This feature is handy, if an option is only available by environment, but not by command-line arguments, because sometimes environment variables are not trivial to set (e.g. in Makefiles). Some more examples: kdb set user/env/override/MANOPT -- "--regex -LC" kdb elektrify-getenv getenv MANOPT # to check if it is set as expected kdb getenv MANOPT # if /etc/ld.so.preload is active So is this the final solution for configuration and manual elektrification of applications is not needed anymore? The answer is: no and yes. It is quite satisfactory for configuration that is inherently sharable (not different from one application to another) *and* needs the environment semantics, i.e. some subprocesses should have different configuration than others, e.g. in a specific terminal. But it might not be a good solution for your own application, because libgetenv(3) implies many architectural decision, that other elektrified applications would decide differently, e.g.: - it uses global variables (getenv(3) has no handle) - it uses mutex for multi-threading safety - the API getenv(3) only returns `char*` and has no support for other data types For more information see [src/libgetenv/README.md] (http://git.libelektra.org/blob/master/src/libgetenv/README.md) ## Compatibility As always, the API and API is fully forward-compatible, i.e. programs compiled against an older 0.8 versions of Elektra will continue to work. Because `keyUnescapedName` and `keyGetUnescapedNameSize` is added in this release, it is not backward-compatible, i.e. programs compiled against 0.8.13, might *not* work with older 0.8 libraries. The function `keyUnescapedName` provides access to an unescaped name, i.e. one where `/` and `\\` are literal symbols and do not have any special meaning. `NULL` characters are used as path separators. This function makes it trivial and efficient to iterate over all path names, as already exploited in all bindings: - [jna (java)] (http://git.libelektra.org/blob/master/src/bindings/jna/HelloElektra.java) - [lua] (http://git.libelektra.org/blob/master/src/bindings/swig/lua/tests/test_key.lua) - [python2] (http://git.libelektra.org/blob/master/src/bindings/swig/python2/tests/testpy2_key.py) - [python3] (http://git.libelektra.org/blob/master/src/bindings/swig/python3/tests/test_key.py) Other small changes/additions in bindings: - fix key constructor, thanks to Manuel Mausz - add copy and deepcopy in python (+examples,+testcases), thanks to Manuel Mausz - dup() in python3 returned wrong type (SWIG wrapper), thanks to Toscano Pino for reporting, thanks to Manuel Mausz for fixing it Doxygen 1.8.8 is preferred and the configfile was updated to this version. The symbols of nickel (for the ni plugin) do not longer leak from the Elektra library. As such, old versions of testmod_ni won't work with Elektra 0.8.13. A version-script is now in use to only export foll
Shutting down a cross-platform multithreaded app
Well, this is fun ... for some definition of the word. ;-( I have a multithreaded app that I want to be able to shut down easily such as by hitting control-c or sending it a signal. What follows is the way I have come up with given the common elements of different environments. Suggestions for improvement would be welcome or you may just find the convolutions and machinations interesting. The first issue is that only the main thread can receive signals, according to https://docs.python.org/2/library/signal.html It says: "the main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads)". That's OK. I can get the main thread to accept suitable signals but then I need some way for it to tell the other threads to shut themselves down too. In most (probably all) cases they will be sitting waiting for network IO. I could have the main thread set a value in a global variable and then have the sub-threads check the global in between accesses of the network in a polling loop (using select() with a timeout). But as has already been pointed out to me in the thread "Signal SIGINT ignored during socket.accept" such polling does not sit well with hosted OSes and it can keep the CPU from remaining at rest in a low-power mode. I can, however, use select() to monitor two file descriptors. One would be the socket the thread is using to communicate with the client. The other would be a control connection from the master thread. Now to make this cross platform According to the opening paragraph in the following link Windows select() won't work on arbitrary file descriptors but only works for sockets. https://docs.python.org/2/library/select.html Well, that can be dealt with. I thought of using AF_UNIX or something else but it seems there is nothing else which could be considered universal and, according to the next link, if socket.AF_UNIX is not defined then even the Unix protocol is not supported. https://docs.python.org/2/library/socket.html Needless to say, on a test Windows machine AF_UNIX is not present. The only cross-platform option, therefore, seems to be to use each subthread's select()s to monitor two AF_INET sockets: the one to the client and a control one from the master thread. I would seem to need IP socket pairs between the master thread and the subthreads. If the master thead receives a shutdown signal it will send a shutdown command to each subthread. The above seems logical but would use quite a few IP sockets. I cannot think of a better way, though. Any comments on the ideas above? James -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a module to abstract a REST api
On 18.09.2015 17:28, Joseph L. Casale wrote: So a design pattern I use often is to create Python objects to represent objects returned from what ever api I am abstracting. For example I might create named tuples for static data I dont intend to change or for an object I can both query for and create, I might build a class to represent it. The problem now comes from the following: # foo now contains a handle to the remote api. foo = InstanceOfApiWrapper() Is it necessary to have an instance of that API? Just curiosity here. # queues is a container of Queue classes. queues = foo.get_queues() queue = queues[0] queue.delete() Alright. I see you want to have concrete classes, so you work with HTTP like you would do with SOAP-bases web services. I actually was referring to the self-expanding capability of REST (please note, REST is not HTTP, HTTP is one protocol that can be use to build an REST-ful API). It's basically like: you query a resource which holds an link to another resource which you then you query by following that link and so on and so forth. So, all what you need for REST is one starting point to explore the resource graph. In this case its possible for foo (InstanceOfApiWrapper) to inject a reference to itself so the delete() can actually make the call. # I want to create a queue from scratch... disparate_queue = Queue(x, y, z) # Now what happens? No handle to an api? disparate_queue.delete() I don't see an issue here. Looks quite readable. An alternative is: foo.delete_queue(disparate_queue) That's not a pattern I prefer, what facilities in Python provide for a workaround here? You always can add attributes to objects. So, add something like an __api__ attribute (which nobody would ever use except you when creating these queue objects in "get_queues"). One option is to put everything in one module and use globals. If the handle is initialized it'll just work. Problem with that is its not thread safe (without work) and I subscribe to one object per file (bloody hard with Python's import/load procedure. It's perfectly fine to add a "secret" API instance to the object. It's called aspect-oriented programming. You remove the aspect of how to correctly manage an API instance and put that knowledge into a separate piece of code. *thumbs up* Best, Sven -- https://mail.python.org/mailman/listinfo/python-list
Re: Shutting down a cross-platform multithreaded app
"James Harris" writes: > I have a multithreaded app that I want to be able to shut down easily > such as by hitting control-c or sending it a signal. Set the daemon flag on the worker threads, so when the main thread exits, the workers also exit. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On 9/18/2015 9:40 AM, Random832 wrote: I'm disputing that chained comparisons are used for the particular combinations that I am actually arguing should not be used in python. You are free to dislike certain combinations, not use them yourself, and even request others not to use them (all in Python code). But claiming that they have never been used in math is quite different. Such asa < b > c If a, b, c are members of a totally ordered set, so that < is transitive, this is equivalent to max(a,c) < b. But the latter makes an irrelevant comparison between a and c. If they are only partially ordered, so that a and c are not necessarily comparable, then the above is the most concise way to way what it says. I believe I have seen such. or a != b != c [whereas a may or may not be equal to c] a != b != c != a says that all three are unequal to any of the other two. I believe I have seen such, with '!=' replaced with the single 'not equal' character. or a in b in c. If b and c are collections, such as sets, this is perfectly sensible. With 'in' replaced with the epsilon 'set membership' character, I may have seen such. If 'a in b in c', then 'a in Union(c)', where Union is the union of all collections in c. One might call this quasi-transitive. In reverse, 'a in Union(c)' implies 'exists b, a in b in c'. Similarly, if 'a in b for all b in c' is equivalent to 'a in Intersection(c)'. Your claim seemed to be that these combinations *are* used, since you claimed that python implements the *same* semantics. The semantics Python copies from math is "a op b op c == a op b and b op c", where 'op' is a binary predicate or comparison operator. I also happen to believe you are wrong in the specific examples. But the semantic copying would apply even if a particular combination had not yet ever been used. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Shutting down a cross-platform multithreaded app
"Paul Rubin" wrote in message news:87zj0jd1ta@jester.gateway.sonic.net... "James Harris" writes: I have a multithreaded app that I want to be able to shut down easily such as by hitting control-c or sending it a signal. Set the daemon flag on the worker threads, so when the main thread exits, the workers also exit. Interesting idea, and I did not know that a *thread* could be a daemon. Unfortunately, I think what you suggest would kill the threads stone dead and not allow them to close connections. That's a particular problem with TCP connections and would require the OS to keep TCP state around for a while. I would rather close the TCP connections or, rather, encourage the other end to close the connection so that the worker threads could then close the sockets in a way that would not hold on to resources. For anyone who is interested see the TCP state diagram such as the one at http://no-shoveling.com/wp-content/uploads/2013/11/TCPfsm.png The key transition is the way the server exits the ESTABLISHED state. If the server closes its end of the connection first the transition goes via the line labelled appl:close, send: FIN. In that case the socket will end up in the TIME_WAIT state wherein it can wait 2MSL or 2 maximum segment lifetimes before becoming free. According to https://en.wikipedia.org/wiki/Maximum_segment_lifetime MSL is arbitrarily defined to be two minutes. That means a TCP endpoint could sit in TIME_WAIT for a horribly long four minutes...! So, I would rather get the other end to send the first FIN, if possible. On the TCP state diagram that is the exit from ESTABLISHED labelled recv:FIN, send ACK. My end can then shutdown the socket, which would send a FIN, and wait for a final ACK. Bottom line: I need to do a controlled cleanup. James -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Fri, Sep 18, 2015, at 14:24, Terry Reedy wrote: > If a, b, c are members of a totally ordered set, so that < is > transitive, this is equivalent to max(a,c) < b. But the latter makes an > irrelevant comparison between a and c. But *who would write that?* It's not a natural form of notation. I'm not saying it doesn't mean anything in Python. Obviously everything that is allowed means something. I'm saying no-one would write that in an ordinary context of human communication and expect to be understood. > > Your claim seemed to be that these combinations *are* > > used, since you claimed that python implements the *same* semantics. > > The semantics Python copies from math is "a op b op c == a op b and b op > c", I don't believe those *are* the semantics in math. I believe that in math this notation is *specifically* meant to support "all of these things are related to all of the others in ways that can be summarized in a single expression" and that mixing operations in a way that does not allow that is a misuse of the notation. In other words, any "a op b op c" that does not allow you to make a statement on how a is related to c is a *mistake*, because it means that you're welding together two things that aren't logically connected to each other at all. If there is no operator op3 where a op1 b op2 c implies a op3 c, then you should not put a and c in the same inequality, full stop. > where 'op' is a binary predicate or comparison operator. I also > happen to believe you are wrong in the specific examples. But the > semantic copying would apply even if a particular combination had not > yet ever been used. -- https://mail.python.org/mailman/listinfo/python-list
Catching exceptions from logging socket handler
I have a socket logging handler and I want to be able to catch exceptions from it. Specifically, I want to know if the remote side has gone away so I can close the socket and reopen it when the remote side come back. What happens now is that I get Broken pipe and BAD_WRITE_RETRY exceptions, but it's not coming from any functions I directly call. is there any way to catch these? Traceback (most recent call last): File "/home/ecovent/python2.7.9/lib/python2.7/logging/handlers.py", line 579, in emit self.send(s) File "/home/ecovent/python2.7.9/lib/python2.7/logging/handlers.py", line 520, in send self.sock.sendall(s) File "/home/ecovent/python2.7.9/lib/python2.7/ssl.py", line 701, in sendall v = self.send(data[count:]) File "/home/ecovent/python2.7.9/lib/python2.7/ssl.py", line 667, in send v = self._sslobj.write(data) SSLError: [SSL: BAD_WRITE_RETRY] bad write retry (_ssl.c:1625) Traceback (most recent call last): File "/home/ecovent/python2.7.9/lib/python2.7/logging/handlers.py", line 579, in emit self.send(s) File "/home/ecovent/python2.7.9/lib/python2.7/logging/handlers.py", line 520, in send self.sock.sendall(s) File "/home/ecovent/python2.7.9/lib/python2.7/ssl.py", line 701, in sendall v = self.send(data[count:]) File "/home/ecovent/python2.7.9/lib/python2.7/ssl.py", line 667, in send v = self._sslobj.write(data) error: [Errno 32] Broken pipe -- https://mail.python.org/mailman/listinfo/python-list
Conda problem/question
I was following along with Lex Hider's PyCon Au talk about Conda: https://www.youtube.com/watch?v=Fqknoni5aX0 Everything was going swimmingly. I installed miniconda, tweaked PATH, installed some of the other stuff he talked about, then did the pip command: pip install theano keras tweepy word2vec This hiccuped during the process because it wanted to install Cython and (I think - it's now scrolled off the terminal window) h5py. It seems it tried to build h5py before Cython, though h5py depends on Cython. Anyway, at the end it told me it had installed everything, so I continued. My next step was (deep breath): conda install anaconda which failed almost immediately with: Error: Unsatisfiable package specifications. Generating hint: [ COMPLETE ]|###| 100% Hint: the following packages conflict with each other: - anaconda - python 3.5* So I presume I can't do the whole ball of wax because of the Python 3.5 install. I guess I should start from scratch... There's not really a question there, but should I have known to leave off the "python=3" arg when creating the environment? Would there have been a way to figure out ahead of time that python=3 wouldn't work? Thx, Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Shutting down a cross-platform multithreaded app
"James Harris" : > I have a multithreaded app that I want to be able to shut down easily > such as by hitting control-c or sending it a signal. The problem with threads is you cannot cause them to exit from the outside. You can do that to asyncio coroutines, however. Maybe you should consider porting your multithreaded app to asyncio. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Shutting down a cross-platform multithreaded app
In a message of Fri, 18 Sep 2015 20:09:19 +0100, "James Harris" writes: >> Set the daemon flag on the worker threads, so when the main thread >> exits, the workers also exit. > >Interesting idea, and I did not know that a *thread* could be a daemon. >Unfortunately, I think what you suggest would kill the threads stone >dead and not allow them to close connections. Can you stick your worker threads into a Queue. When the main thread exits have it tell the queue to clean itself up? see: http://code.activestate.com/recipes/82965-threads-tkinter-and-asynchronous-io/ The main thread doesn't have to be a gui ... (but the author of that recipe and I are now drunkly celebrating a birthday so maybe I ought not to be posting this idea ...) Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Fri, Sep 18, 2015 at 1:12 PM, Random832 wrote: > On Fri, Sep 18, 2015, at 14:24, Terry Reedy wrote: >> The semantics Python copies from math is "a op b op c == a op b and b op >> c", > > I don't believe those *are* the semantics in math. I believe that in > math this notation is *specifically* meant to support "all of these > things are related to all of the others in ways that can be summarized > in a single expression" and that mixing operations in a way that does > not allow that is a misuse of the notation. In other words, any "a op b > op c" that does not allow you to make a statement on how a is related to > c is a *mistake*, because it means that you're welding together two > things that aren't logically connected to each other at all. > > If there is no operator op3 where a op1 b op2 c implies a op3 c, then > you should not put a and c in the same inequality, full stop. Whoever wrote the Wikipedia article disagrees: https://en.wikipedia.org/wiki/Inequality_(mathematics)#Chained_notation Although the reference to Python leads one to suspect that this could be based more on Python's semantics than on actual mathematics. -- https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Fri, Sep 18, 2015, at 17:13, Ian Kelly wrote: > Whoever wrote the Wikipedia article disagrees: > > https://en.wikipedia.org/wiki/Inequality_(mathematics)#Chained_notation > > Although the reference to Python leads one to suspect that this could > be based more on Python's semantics than on actual mathematics. Also, it says "different directions", but the provided example doesn't actually *show* different directions (i.e. mixing less-operators with greater-operators). The provided example "a < b = c <= d" does allow you to infer relationships between all participants: a < b, a < c, a < d, b = c, b <= d, c <= d. -- https://mail.python.org/mailman/listinfo/python-list
Re: Shutting down a cross-platform multithreaded app
On Sat, Sep 19, 2015 at 3:17 AM, James Harris wrote: > Needless to say, on a test Windows machine AF_UNIX is not present. The only > cross-platform option, therefore, seems to be to use each subthread's > select()s to monitor two AF_INET sockets: the one to the client and a > control one from the master thread. I would seem to need IP socket pairs > between the master thread and the subthreads. If the master thead receives a > shutdown signal it will send a shutdown command to each subthread. > > The above seems logical but would use quite a few IP sockets. I cannot think > of a better way, though. Any comments on the ideas above? If you're using select() to monitor the sockets, you don't actually then have to _do_ anything with the shutdown socket. You could have a single socket that sends the shutdown signal to all your workers. Bear in mind, though, that Windows has no protection against other processes shutting you down. You can restrict it to 127.0.0.1 (of course) but any program running on the same computer as the server - regardless of user permissions etc - will be able to connect to your sockets. So it might be best to do something like this (all on the main thread): 1) Open a listening socket 2) Connect to the listening socket 3) Accept a connection 4) Close the original listening socket 5) Spin off all your threads, passing them the socket from step 2 6) To terminate them all, write a byte to the socket from step 3. This will make it difficult for ordinary userspace code to mess with you. It'd still be possible, I think, for something with raw sockets access to feign a termination signal; I have no idea what protections Windows offers you there. Give it a shot, see how it goes! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a module to abstract a REST api
Hi Sven, >> The problem now comes from the following: >> >> # foo now contains a handle to the remote api. >> foo = InstanceOfApiWrapper() > > Is it necessary to have an instance of that API? Just curiosity here. Not always but often as the pattern here might rely on a handle to a c types based api handle for example which might be a pointer or it may hold a session with credentials and state (not for REST of course). >> # queues is a container of Queue classes. >> queues = foo.get_queues() >> >> queue = queues[0] >> queue.delete() > > Alright. I see you want to have concrete classes, so you work with HTTP > like you would do with SOAP-bases web services. Yup. > I actually was referring to the self-expanding capability of REST > (please note, REST is not HTTP, HTTP is one protocol that can be use to > build an REST-ful API). It's basically like: you query a resource which > holds an link to another resource which you then you query by following > that link and so on and so forth. So, all what you need for REST is one > starting point to explore the resource graph. Well that is true, but what of the credential object that gets created with the instance of InstanceOfApiWrapper? You are certainly right in that the instance of Queue being REST based will always have all it needs to perform the functions, it just lacks the credentials. >> In this case its possible for foo (InstanceOfApiWrapper) to inject a >> reference >> to itself so the delete() can actually make the call. >> >> # I want to create a queue from scratch... >> disparate_queue = Queue(x, y, z) >> # Now what happens? No handle to an api? >> disparate_queue.delete() > > I don't see an issue here. Looks quite readable. Well, what credentials does .delete() use? I should have actually stated that, sorry. >> An alternative is: >> foo.delete_queue(disparate_queue) >> >> That's not a pattern I prefer, what facilities in Python provide for a >> workaround >> here? > > You always can add attributes to objects. So, add something like an > __api__ attribute (which nobody would ever use except you when creating > these queue objects in "get_queues"). This is where I am going, but how do you perform dependency injection in Python? > It's perfectly fine to add a "secret" API instance to the object. It's > called aspect-oriented programming. You remove the aspect of how to > correctly manage an API instance and put that knowledge into a separate > piece of code. *thumbs up* Yea, I am glad you agree:) Its a model I certainly subscribe to. I just don't know how to make the disparate case "know" of the foo instance when foo didn't instantiate it (which gives the injection opportunity). That foo instance also serves of a starting point to make the GET type queries. How would you go about making disparate case lookup a handle, especially when I insist on placing all the objects in their files. I know, tough to do in Python, but its what I am used to. Thanks a lot for the knowledge and insight, I greatly appreciate this. jlc -- https://mail.python.org/mailman/listinfo/python-list
Re: Shutting down a cross-platform multithreaded app
On Fri, Sep 18, 2015, at 17:40, Chris Angelico wrote: > Bear in mind, though, that Windows has no protection against other > processes shutting you down. Neither does Unix. Any process that can send you a signal can send you SIGKILL. Of course, what Windows lacks is a generalized way for other processes to send "less destructive" signals that do give you a chance to clean up. (You can sometimes send a ctrl-break event, but that's it.) And most frameworks for "emulating" them (including python's os module) simulate sending other signals by calling TerminateProcess with an exit status related to the signal. -- https://mail.python.org/mailman/listinfo/python-list
Re: Shutting down a cross-platform multithreaded app
On Sat, Sep 19, 2015 at 7:48 AM, Random832 wrote:
> On Fri, Sep 18, 2015, at 17:40, Chris Angelico wrote:
>> Bear in mind, though, that Windows has no protection against other
>> processes shutting you down.
>
> Neither does Unix. Any process that can send you a signal can send you
> SIGKILL.
Incorrect. If your server is running as root, only root can kill it:
rosuav@sikorsky:~$ kill -9 17080
bash: kill: (17080) - Operation not permitted
If it's running as some other user, then that user can kill it (that
includes the simple case where a non-root user starts a process and
also tries to kill it), as can root, of course. So you have protection
against direct signals (and not just 9/KILL, naturally); and you also
have protection against an AF_UNIX socket, which is what I was talking
about here. The control over sockets is a bit more flexible, as I'm
fairly sure group permissions can't be set for process signals, but
they can for named sockets:
rosuav@sikorsky:~$ python3
Python 3.6.0a0 (default:30bc256f2346, Sep 17 2015, 02:01:45)
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
>>> s.bind("/tmp/demo_socket")
>>> import os
>>> os.chmod("/tmp/demo_socket",0o750)
>>> s.listen(1)
>>> s.accept()
# program pauses here
(, b'')
In another terminal, using Python 2 for variety:
rosuav@sikorsky:~$ sudo sudo -u tfr python
Python 2.7.9 (default, Mar 1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_UNIX)
>>> s.connect("/tmp/demo_socket")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 13] Permission denied
Err, nope! What if I don't change users?
rosuav@sikorsky:~$ python
Python 2.7.9 (default, Mar 1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_UNIX)
>>> s.connect("/tmp/demo_socket")
>>>
Looks good. (Feel free to concoct your own scenario that proves that
group permissions work here; I don't have any handy demo cases.)
Unix is designed for this exact sort of thing. Windows isn't, and
privilege escalation attacks are far more common there.
> Of course, what Windows lacks is a generalized way for other processes
> to send "less destructive" signals that do give you a chance to clean
> up. (You can sometimes send a ctrl-break event, but that's it.) And most
> frameworks for "emulating" them (including python's os module) simulate
> sending other signals by calling TerminateProcess with an exit status
> related to the signal.
Yeah, the whole notion of less-destructive (or even completely
non-destructive - look at how a lot of daemons use SIGHUP) signals is
absent on Windows. But that's not really the problem here; the problem
is that there's no way to say "this is a socket for my process ONLY",
which in Unix would be done with a socket.socketpair, but on Windows I
think has to be simulated.
That said, though socket.socketpair() IS supported on Windows...
as of Python 3.5. I haven't tested it to see what it's like. If you
can restrict your support to 3.5+, you might be able to do this
instead of what I was describing above.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Shutting down a cross-platform multithreaded app
"James Harris" writes: ... > Needless to say, on a test Windows machine AF_UNIX is not present. The > only cross-platform option, therefore, seems to be to use each > subthread's select()s to monitor two AF_INET sockets: the one to the > client and a control one from the master thread. I would seem to need > IP socket pairs between the master thread and the subthreads. If the > master thead receives a shutdown signal it will send a shutdown > command to each subthread. There is socket.socketpair() on Windows too (since Python 3.5) https://docs.python.org/3/library/socket.html#socket.socketpair http://bugs.python.org/issue18643 Note: you could use select() to handle signals in the main thread too (even on Windows since Python 3.5) if you use signal.set_wakeup_fd() https://docs.python.org/3/library/signal.html#signal.set_wakeup_fd It is known as a self-pipe trick http://www.sitepoint.com/the-self-pipe-trick-explained/ Look at *asyncio* source code, to see how to get a portable implementation for various issues with signals. Some issues might still be opened e.g., Ctrl+C behavior http://bugs.python.org/issue24080 Here's how to combine SIGCHLD signal handling with tkinter's event loop http://stackoverflow.com/questions/30087506/event-driven-system-call-in-python SIGCHLD, createfilehandler() are not portable but the code demonstrates possible set_wakeup_fd() issues and their solutions (O_NONBLOCK, dummy signal handler, SA_RESTART, signal coalescing). On threads and signals in CPython http://bugs.python.org/issue5315#msg102829 -- https://mail.python.org/mailman/listinfo/python-list
ConnectionError handling problem
I am learning python. I wrote a script using requests module.
The scripts runs fine for sometime, but after a while it hangs. When I press
CTRL+C it shows ConnectionError even though I have included exception handling.
I am not sure as to why it cant handle ConnectionError when the script runs for
a long time.
This is a part(causing issues) of the script I am running:
while(k<46656):
j=res[k]
url="http://172.16.68.6:8090/login.xml";
query_args = {'mode':'191', 'username':str(i),
'password':str(j), 'a':'1442397582010', 'producttype':'0'}
try:
r=requests.post(url, data=query_args)
except:
print "Connection error"
time.sleep(30)
continue
html=r.text
if(len(html) < 10):
continue
if("The system could not log you on" not in html):
print "hello"
filehandle=open("ids", "a")
filehandle.write(str(i)+'\n')
filehandle.write(str(j)+'\n')
filehandle.close()
break
k=k+1
Any help will be highly appreciated.
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
Random832 writes:
> On Fri, Sep 18, 2015, at 14:24, Terry Reedy wrote:
>> If a, b, c are members of a totally ordered set, so that < is
>> transitive, this is equivalent to max(a,c) < b. But the latter makes
>> an irrelevant comparison between a and c.
>
> But *who would write that?* It's not a natural form of notation. I'm
> not saying it doesn't mean anything in Python. Obviously everything
> that is allowed means something. I'm saying no-one would write that in
> an ordinary context of human communication and expect to be
> understood.
It might be natural when discussing partial orders, where (a < b > c) is
compatible with there not being any max(a, c) or even sup(a, c) at all.
Here's a class of strings ordered by inclusion as substrings. The
comparison (u in w != u) in __lt__ came naturally when I wrote this.
class S(object):
def __init__(self, s):
self.s = s
def __lt__(self, other):
return self.s in other.s != self.s
def __eq__(self, other):
return self.s == other.s
def __str__(self):
return 'S({})'.format(repr(self.s))
And here's looking for two distinct elements that have a common proper
upper bound in a given set.
data = ('a', 'oo', 'r', 'foo', 'bar')
print(*( (x.s, y.s)
for x in map(S, data)
for y in map(S, data)
for m in map(S, data)
if y != x < m > y != x ),
sep = '\n')
Output:
('a', 'r')
('r', 'a')
The question is whether some such conditions might, sometimes,
somewhere, in context, look natural. I says yes.
The condition as a whole states a verbalizable relation between x, y, m:
that m is a common upper bound of distinct x, y. It's not stated whether
x < y or x > y or neither.
--
https://mail.python.org/mailman/listinfo/python-list
