Re: Weighted choices
Op 09-09-13 02:21, Dennis Lee Bieber schreef: > On Sun, 08 Sep 2013 19:48:55 +0200, Antoon Pardon > declaimed the following: > >> Op 08-09-13 04:12, Jason Friedman schreef: >>> choices = dict() >>> choices["apple"] = 10 >>> choices["pear"] = 20 >>> choices["banana"] = 15 >>> choices["orange"] = 25 >>> choices["kiwi"] = 30 >>> >>> I want to pick sets of fruit, three in a set, where the chance of >>> selecting a given fruit is proportional to its weight. In the example >>> above, pears should appear twice as often as apples and kiwis should >>> appear twice as often as bananas. >> >> Just a small question. Is a set of three bananas an acceptable outcome? > > If we are talking probabilities, regardless of what the weighting is, > it should be probable (if unlikely) to get three-of-a-kind. Why should that be? I'm unfamiliar with any kind of imperative that discourages people from wanting sets with three different kinds of fruit. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Building tkinter on Windows
On 9/9/2013 1:14 AM, Westley Martínez wrote: Hello. Can anyone tell me how to build tkinter on Windows? I've downloaded the source, ran Tools/buildbot/external.bat to build the external dependencies. I copied tcl85g.dll and tk85g.dll to PCBuild. I built the Visual Studio solution. Everything built fine without errors. Everything seems to work except tkinter. It says: Traceback (most recent call last): File "", line 1, in File "...\cpython-idle\lib\tkinter\__init__.py", line 36, in from tkinter import _fix File "...\cpython-idle\lib\tkinter\_fix.py", line 65, in import _tkinter ImportError: DLL load failed: The specified module could not be found. I'm thinking I didn't put the DLLs in the right place, but I don't have any idea where to put them and Google isn't helping. Some combination of the README instructions, external.bat, and the project files are not correct. There may be an issue on the tracker. I believe I copied tcl85g.dll and tk85g.dll into .../py3x/pcbuild from .../tcltk/bin and that resolved the problem for me. But you say you did that. Did _tkinter_d.pyd get built (in pcbuild)? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Weighted choices
On Mon, 09 Sep 2013 09:12:05 +0200, Antoon Pardon wrote: > Op 09-09-13 02:21, Dennis Lee Bieber schreef: >> On Sun, 08 Sep 2013 19:48:55 +0200, Antoon Pardon >> declaimed the following: >> >>> Op 08-09-13 04:12, Jason Friedman schreef: choices = dict() choices["apple"] = 10 choices["pear"] = 20 choices["banana"] = 15 choices["orange"] = 25 choices["kiwi"] = 30 I want to pick sets of fruit, three in a set, where the chance of selecting a given fruit is proportional to its weight. In the example above, pears should appear twice as often as apples and kiwis should appear twice as often as bananas. >>> >>> Just a small question. Is a set of three bananas an acceptable >>> outcome? >> >> If we are talking probabilities, regardless of what the weighting is, >> it should be probable (if unlikely) to get three-of-a-kind. > > Why should that be? I'm unfamiliar with any kind of imperative that > discourages people from wanting sets with three different kinds of > fruit. Then that's hardly *random*, is it? Or at least, it is a non-uniform distribution, with much less randomness that a free choice. The OP specifies that the chance of selecting a given fruit is proportional to its weight. That is not the case if you insist each piece of fruit must be different. E.g. consider the case where there are five different kinds of fruit (apple, pear, etc.) and you choose five pieces. You *must* get one each of apple, pear etc., no matter how small the weights are, and so the probability of getting set(apple, pear, banana, orange, kiwi) is exactly 1, even if there are ten million apples to choose from and only one orange. A more important question is, should the selection be done with or without replacement? That is, after selecting by chance an apple, does that mean there is one fewer apple to select next time, and hence the weight need to be slightly reduced? Or is the apple returned to the pool, and the weights remain unchanged? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Weighted choices
Jason Friedman wrote: [You may have sent this in private mail by accident, so I take the freedom to bring this back to the mailing list] > I'm realizing with your question which was roughly: Do picks from a pool influence probability of subsequent picks, i. e. weather the pool is finite or infinite. > about which I want, though, leads me > to state the actual problem, which takes longer to explain. Giving the actual problem is always a good idea as it allows answers that aren't limited by your grasp of the problem. > I coach a flag football team of 11-year-olds. A stated goal of the > league is that every player should get nearly equal playing time and > that winning is of secondary importance. That said, some players just > can't throw the ball at all, and having a quarterback who cannot throw > is no fun for anyone. The other coach and I will pick two players who > will be the quarterback for any given snap. The other players can play > any position (center, receiver, runner) other than quarterback. > > The game is 5-on-5 and our roster contains ten players, and we can > expect a random player or two missing on any given week. I'm trying > to come up with a system that causes at least one of those > quarterbacks to be on the offensive field on every play. Further, to > compensate for the fact that the quarterback gets to touch the ball on > every play, we want the quarterbacks to appear at the non-quarterback > positions somewhat less than the other players. > > This is all quite challenging. 11-year-olds are exquisitely tuned to > unfairness and most have a keen idea of the play that will surely > score a touchdown if only the clueless coach would let them run it. > Oh, and the originator of this play will be the key > quarterback/runner/receiver for the play. Oh, and in case the coach > forgets, they will remind him. OK, you're well inside the "finite" domain. Also, you probably want less than the "natural" randomness. I'd probably shuffle the potential quarterbacks and the others in independent lists, and then pick one half of each to form a team. The other half would play in the next game. Additionally you can keep track of every player's total number of games and games not played in a row, and apply a correction if either exceeds a limit acceptable for a kid. As for the actual position in the team, that a least should be left for the coach to decide. Personally I would prefer to have some discussion between the kids with the coach having an eye on the shy or not-so-popular ones -- and if that leads to more lost games than necessary, so be it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Can I trust downloading Python?
On Mon, 09 Sep 2013 02:39:09 +1000, Chris Angelico wrote: > On Mon, Sep 9, 2013 at 2:08 AM, Charles Hottel > wrote: >> I think this article is relevant althought the code examples are not >> Python but C: >> >> http://cm.bell-labs.com/who/ken/trust.html > > That is quite true, and yet not truly helpful here :) It's like pointing > out that we could be being fed false information, and then suggesting > that The Matrix is technically possible. Once you start distrusting to > that level, you become paranoid to a point that's inappropriate to all > but the most critical situations. I'd accept and maybe even recommend > that sort of paranoia if you're running a nuclear power station, or an > automated weapon system capable of firing missiles that destroy the > planet, or a bank that holds everyone's money. For the average Joe, > there's no point panicking. > > Also: That hack works beautifully when there's precisely one C compiler. > In today's world, there are many (well known ones like gcc, clang, MS > Visual Studio (whatever the compiler from that is called), and a bunch > of lesser-known ones as well), and it's pretty easy to just grab a > different compiler and build. The chances that your code will be falsely > compiled by TWO compilers would have to be infinitesimal, and you > needn't stop at two. That logic is dubious. Compilers aren't compromised by chance, and we don't know the a priori probability of any specific compiler being compromised. That depends on the attacker, surely? We know, for example, that the NSA has compromised multiple brands of router, smart phone and similar. If they, or some other similar organisation with equivalent capabilities, were going to attack compilers in the same manner, they surely wouldn't stop at one. Would people notice? How often do people compare the machine code output of two different compilers, looking for back-doors in the generated code? Would you know where to look? If you found some differences, wouldn't you likely just chalk it up to different compilers producing different code? I think the best argument against this suggestion is that it would be an order of magnitude harder to compromise open source compilers, as you discuss below, and therefore gcc is *probably* (but not certainly) safe. But closed source? If Microsoft inserted a backdoor into Windows 8 on behalf of the NSA, as seems to be the case, then surely they'd also do the same to Visual Studio if asked. Organisations like the NSA don't operate under the rule "if there is one single uncompromised machine on the planet, we've lost". It's a numbers game. If (hypothetically speaking) they had inserted backdoors into Visual Studio, gcc and clang, but not Larry's Cool C Compiler, I don't think they're going to lose sleep over that. > Since many people build (to take one example) gcc > from source, using an old version of gcc, the hack would have to be > propagated to all current gcc builds in some way - you can't simply > build once and install the binary as the official C compiler, not in > today's distributed society. (If you're truly paranoid, you might > believe that gcc has had the hack in it since its inception. But some > people build gcc using other compilers, too.) Yep, I agree -- although probably no individual has inspected the entire tool chain involved in building gcc, enough people have inspected each individual component that we can be reasonably confident that it is okay. > If you can't trust any code you didn't write yourself, You trust yourself? You sheeple! The truly cautious man doesn't even trust himself. You might be an unconscious sleeper agent. Haven't you watched The Running Man? (Ha ha only serious.) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Weighted choices
Op 09-09-13 11:11, Steven D'Aprano schreef: > On Mon, 09 Sep 2013 09:12:05 +0200, Antoon Pardon wrote: > >> Op 09-09-13 02:21, Dennis Lee Bieber schreef: >>> On Sun, 08 Sep 2013 19:48:55 +0200, Antoon Pardon >>> declaimed the following: >>> Op 08-09-13 04:12, Jason Friedman schreef: > choices = dict() > choices["apple"] = 10 > choices["pear"] = 20 > choices["banana"] = 15 > choices["orange"] = 25 > choices["kiwi"] = 30 > > I want to pick sets of fruit, three in a set, where the chance of > selecting a given fruit is proportional to its weight. In the > example above, pears should appear twice as often as apples and kiwis > should appear twice as often as bananas. Just a small question. Is a set of three bananas an acceptable outcome? >>> >>> If we are talking probabilities, regardless of what the weighting > is, >>> it should be probable (if unlikely) to get three-of-a-kind. >> >> Why should that be? I'm unfamiliar with any kind of imperative that >> discourages people from wanting sets with three different kinds of >> fruit. > > Then that's hardly *random*, is it? Or at least, it is a non-uniform > distribution, with much less randomness that a free choice. I don't see how a problem where one can pick a number of items from a collection, without refilling that collection after each choice makes it that much less random. > The OP specifies that the chance of selecting a given fruit is > proportional to its weight. That is not the case if you insist each piece > of fruit must be different. So? It wouldn't be the first time, a specification wasn't complete or not eniterly what the OP really wanted. As far as I can see, it happens often enough that someone answers the question he thinks the OP wants to ask, instead of the question that was really asked. Noone seems to have a problem with that. So what is the big problem now if I explicitly ask whether that is the case here or not? If the OP had answerd "no", that wouldn't have been a problem, but I'm surprised to get these kind of reactions just for inquiring. > E.g. consider the case where there are five > different kinds of fruit (apple, pear, etc.) and you choose five pieces. > You *must* get one each of apple, pear etc., no matter how small the > weights are, and so the probability of getting set(apple, pear, banana, > orange, kiwi) is exactly 1, even if there are ten million apples to > choose from and only one orange. So? You think it never happened some wanted to solve a problem without a solution? > A more important question is, should the selection be done with or > without replacement? Is it? Because my question and your question are very similar. You see when you just start with one piece of fruit of each at the beginning and you don't replace, the outcome is that you can't get three bananas as outcome. > That is, after selecting by chance an apple, does > that mean there is one fewer apple to select next time, and hence the > weight need to be slightly reduced? Or is the apple returned to the pool, > and the weights remain unchanged? So you don't have any problem with adjusting the weight, ... unless there is only one apple available which would mean the weight would be adjusted to 0. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Can I trust downloading Python?
On 09/09/2013 04:41 AM, Steven D'Aprano wrote: > On Mon, 09 Sep 2013 02:39:09 +1000, Chris Angelico wrote: > >> On Mon, Sep 9, 2013 at 2:08 AM, Charles Hottel >> wrote: >>> I think this article is relevant althought the code examples are not >>> Python but C: >>> >>> http://cm.bell-labs.com/who/ken/trust.html >> >> That is quite true, and yet not truly helpful here :) It's like pointing >> out that we could be being fed false information, and then suggesting >> that The Matrix is technically possible. Once you start distrusting to >> that level, you become paranoid to a point that's inappropriate to all >> but the most critical situations. I'd accept and maybe even recommend >> that sort of paranoia if you're running a nuclear power station, or an >> automated weapon system capable of firing missiles that destroy the >> planet, or a bank that holds everyone's money. For the average Joe, >> there's no point panicking. >> >> Also: That hack works beautifully when there's precisely one C compiler. >> In today's world, there are many (well known ones like gcc, clang, MS >> Visual Studio (whatever the compiler from that is called), and a bunch >> of lesser-known ones as well), and it's pretty easy to just grab a >> different compiler and build. The chances that your code will be falsely >> compiled by TWO compilers would have to be infinitesimal, and you >> needn't stop at two. > > That logic is dubious. Compilers aren't compromised by chance, and we > don't know the a priori probability of any specific compiler being > compromised. That depends on the attacker, surely? We know, for example, > that the NSA has compromised multiple brands of router, smart phone and > similar. If they, or some other similar organisation with equivalent > capabilities, were going to attack compilers in the same manner, they > surely wouldn't stop at one. But (and this is stepping into *really* paranoid territory here. But maybe not beyond the realm of possibility) it would not be so hard to compromise compilers at the chip level. If the NSA were to strike an agreement with, say, Intel so that every time a compiler ran on the system, secret code was discreetly inserted into the binary, it would be nearly impossible to detect and a very elegant solution to a tough problem. -- https://mail.python.org/mailman/listinfo/python-list
Re: Logical error in filling QTableWidget and filling all of nodes
On 09/09/2013 06:15, Mohsen Pahlevanzadeh wrote: Dear All, I have the following code (PyQt): / searchFrameObject.tableWidget.setRowCount(rowCounter) searchFrameObject.tableWidget.setColumnCount(5) for row in range(rowCounter): for column in range(5): for result in query: item = QtGui.QTableWidgetItem(_fromUtf8(result.name)) item.setFlags(item.flags() ^ QtCore.Qt.ItemIsEnabled) searchFrameObject.tableWidget.setItem(row,column,item) #item = QtGui.QTableWidgetItem(String(result.bought_price)) #item.setFlags(item.flags() ^ QtCore.Qt.ItemIsEnabled) #searchFrameObject.tableWidget.setItem(row,column+1,item) #item = QtGui.QTableWidgetItem(result.bought_date) #item.setFlags(item.flags() ^ QtCore.Qt.ItemIsEnabled) #searchFrameObject.tableWidget.setItem(row,column+2,item) item = QtGui.QTableWidgetItem(result.stock) item.setFlags(item.flags() ^ QtCore.Qt.ItemIsEnabled) searchFrameObject.tableWidget.setItem(row,column+3,item) item = QtGui.QTableWidgetItem(result.minimum_bound) item.setFlags(item.flags() ^ QtCore.Qt.ItemIsEnabled) searchFrameObject.tableWidget.setItem(row,column+4,item) When i search in DB, i print result.name or print result.stock , everything is OK. But when i import them into QtableWidget i see just node result.name addeed to widgets. (all of nodes filled from result.name) My Question is , How i fill rows and columns with my fields? I don't understand why you're iterating across the columns: for column in range(5): and also setting multiple columns on each iteration: searchFrameObject.tableWidget.setItem(row,column,item) ... searchFrameObject.tableWidget.setItem(row,column+3,item) ... searchFrameObject.tableWidget.setItem(row,column+4,item) That means that: when 'column' is 0 you're setting column 0 to result.name, column 3 to result.stock, and column 4 to result.minimum_bound; when 'column' is 1 you're setting column 1 to result.name, column 4 to result.stock, and column 5 to result.minimum_bound; etc. -- https://mail.python.org/mailman/listinfo/python-list
Re: Can I trust downloading Python?
On Sun, 08 Sep 2013 03:37:15 +, Dave Angel wrote: > 1) what OS are you running? Actually, we can be pretty sure you're > running Windows, since any other common operating system would have > already included Python. Plus I don't often run into Linux users who worry about viruses, unless the braces-and-pimples crowd has expanded its horizons recently and started creating malware that does anything in Linux. -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0a2
On behalf of the Python development team, I'm chuffed to announce the second alpha release of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series so far include: * PEP 435, a standardized "enum" module * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 447, a new magic method for metaclasses (``__typelookup__``) * PEP 448, making automatic sequence unpacking more general To download Python 3.4.0a2 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0a2 with your code and reporting any issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) -- https://mail.python.org/mailman/listinfo/python-list
Re: [python-committers] [RELEASED] Python 3.4.0a2
On Mon, Sep 9, 2013 at 8:02 AM, Larry Hastings wrote: > > On behalf of the Python development team, I'm chuffed to announce the > second alpha release of Python 3.4. > > This is a preview release, and its use is not recommended for > production settings. > > Python 3.4 includes a range of improvements of the 3.x series, including > hundreds of small improvements and bug fixes. Major new features and > changes in the 3.4 release series so far include: > > * PEP 435, a standardized "enum" module > * PEP 442, improved semantics for object finalization > * PEP 443, adding single-dispatch generic functions to the standard library > * PEP 445, a new C API for implementing custom memory allocators > * PEP 446, changing file descriptors to not be inherited by default >in subprocesses > * PEP 447, a new magic method for metaclasses (``__typelookup__``) > * PEP 448, making automatic sequence unpacking more general > Those last two PEPs are still in draft form and not accepted nor have any committed code yet. -- https://mail.python.org/mailman/listinfo/python-list
anyone trying out the alpha?
I just read that Python 3.4.0a is out in alpha. Any of you going to try it out? I don't have any bright ideas for testing it, myself. -- https://mail.python.org/mailman/listinfo/python-list
Re: [python-committers] [RELEASED] Python 3.4.0a2
2013/9/9 Larry Hastings : > Python 3.4 includes a range of improvements of the 3.x series, including > hundreds of small improvements and bug fixes. Major new features and > changes in the 3.4 release series so far include: > > * PEP 446, changing file descriptors to not be inherited by default >in subprocesses The title of the PEP is "Make newly created file descriptors non-inheritable". It has an impact on all functions creating files and sockets not only the subprocess module. You can also add a link to the nice What’s New In Python 3.4 document: http://docs.python.org/dev/whatsnew/3.4.html Victor -- https://mail.python.org/mailman/listinfo/python-list
Re: [RELEASED] Python 3.4.0a2
Le Mon, 9 Sep 2013 08:16:06 -0400, Brett Cannon a écrit : > On Mon, Sep 9, 2013 at 8:02 AM, Larry Hastings > wrote: > > > > > On behalf of the Python development team, I'm chuffed to announce > > the second alpha release of Python 3.4. > > > > This is a preview release, and its use is not recommended for > > production settings. > > > > Python 3.4 includes a range of improvements of the 3.x series, > > including hundreds of small improvements and bug fixes. Major new > > features and changes in the 3.4 release series so far include: > > > > * PEP 435, a standardized "enum" module > > * PEP 442, improved semantics for object finalization > > * PEP 443, adding single-dispatch generic functions to the standard > > library > > * PEP 445, a new C API for implementing custom memory allocators > > * PEP 446, changing file descriptors to not be inherited by default > >in subprocesses > > * PEP 447, a new magic method for metaclasses (``__typelookup__``) > > * PEP 448, making automatic sequence unpacking more general > > > > Those last two PEPs are still in draft form and not accepted nor have > any committed code yet. Unless Larry enthusiastically sneaked them into the release. Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Re: [python-committers] [RELEASED] Python 3.4.0a2
Le Mon, 9 Sep 2013 14:30:50 +0200, Victor Stinner a écrit : > 2013/9/9 Larry Hastings : > > Python 3.4 includes a range of improvements of the 3.x series, > > including hundreds of small improvements and bug fixes. Major new > > features and changes in the 3.4 release series so far include: > > > > * PEP 446, changing file descriptors to not be inherited by default > >in subprocesses > > The title of the PEP is "Make newly created file descriptors > non-inheritable". It has an impact on all functions creating files and > sockets not only the subprocess module. I don't think Larry's description is wrong. "Non-inheritable" is a shorthand for "non-inheritable in subprocesses" with "subprocesses" taken in the general sense (i.e. not only created with the subprocess module). Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Re: [RELEASED] Python 3.4.0a2
Am 09.09.2013 13:02, schrieb Larry Hastings: To download Python 3.4.0a2 visit: http://www.python.org/download/releases/3.4.0/ [quote] Python 3.4.0 alpha 2 was released on September 10th, 2013... [/quote] Import from __future__ ?? ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: [RELEASED] Python 3.4.0a2
On 09/09/2013 09:30 PM, Antoine Pitrou wrote: Le Mon, 9 Sep 2013 08:16:06 -0400, Brett Cannon a écrit : Those last two PEPs are still in draft form and not accepted nor have any committed code yet. Unless Larry enthusiastically sneaked them into the release. Whoops. Nope, I'm not that enthusiastic. I'll remove it from the web site, but obviously I can't do anything about the announcement. //arry/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Chardet, file, ... and the Flexible String Representation
Le vendredi 6 septembre 2013 17:46:14 UTC+2, Piet van Oostrum a écrit : > [email protected] writes: > > > > > The Flexible String Representation has conceptually to > > > face the same problem. It splits "unicode" in chunks and > > > it has to solve two problems at the same time, the coding > > > and the handling of multiple "char sets". The problem? > > > It fails. > > > "This poor Flexible String Representation does not succeed > > > to solve the problem it create itsself." > > > > The FSR does not split unicode in chuncks. It does not create problems and > therefore it doesn't have to solve this. > > > > The FSR simply stores a Unicode string as an array[*] of ints (the Unicode > code points of the characters of the string. That's it. Then it uses a > memory-efficient way to store this array of ints. But that has nothing to do > with character sets. The same principle could be used for any array of ints. > > > > So you are seeking problems where there are none. And you would have a lot > more peace of mind if you stopped doing this. > > > > [*] array in the C sense. > > -- > > Piet van Oostrum > > WWW: http://pietvanoostrum.com/ > > PGP key: [8DAE142BE17999C4] -- Due to its nature, a character cann't be handled in the same way a one another type. That's the purpose of the UTF. - Chunk latin-1, perfomance ref: >>> timeit.timeit("a = 'hundred'; 'x' in a") 0.13144639994075646 >>> timeit.timeit("a = 'hundrez'; 'x' in a") 0.13780295544393084 Chunk ucs2, perfomance >>> timeit.timeit("a = 'hundre€'; 'x' in a") 0.23505392241617074 Chunk ucs4, perfomance >>> timeit.timeit("a = 'hundre\U0001d11e'; 'x' in a") 0.26266673650735584 Comment: Such differences never happen with utf. - Chunk latin-1, memory >>> sys.getsizeof('a') 26 Chunk ucs2, memory >>> sys.getsizeof('€') 40 Comment: 14 bytes more than latin-1 Chunk ucs4, memory >>> sys.getsizeof('\U0001d11e') 44 Comment: 18 bytes more than latin-1 Comment: With utf, a char (in string or not) never exceed 4 bytes. - 'a' + '€' in utf, conceptually Concatenate the *unicode tranformation units*. Some kind of a real direct 'a' + '€'. 'a' + '€' in FSR, conceptually 1) Check the "internal coding" of 'a' 2) Check the "internal coding" of '€' 3) Compare these codings 4a) If they match, concatenate the bytes 4b) If they do not match 5) Reencode the string which has to 6) Concatenate 7) Set the "internal coding" status for further processing - Complicate and full of side effects, eg : >>> sys.getsizeof('a') 26 >>> sys.getsizeof('aé') 39 Is not a latin-1 "é" supposed to count as a latin-1 "a" ? I picked up random methods, there may be variations, basically this general behaviour is always expected. jmf -- https://mail.python.org/mailman/listinfo/python-list
Re: anyone trying out the alpha?
On 9/9/2013 8:22 AM, Fattburger wrote: I just read that Python 3.4.0a is out in alpha. Any of you going to try it out? 3.4.0whatever is essentially 3.3.2 with additional bug fixes that will also appear in 3.3.3 plus a few additional bugfixes that were not backported plus new features. The only things 'unstable', compared to previous releases, are the new features. For one thing, the APIs may still be changed. > I don't have any bright ideas for testing it, myself. If you have any code with automated tests, it is good idea to run them now with the alpha. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Can I trust downloading Python?
On 09/09/2013 05:02 AM, Anthony Papillion wrote: > But (and this is stepping into *really* paranoid territory here. But > maybe not beyond the realm of possibility) it would not be so hard to > compromise compilers at the chip level. If the NSA were to strike an > agreement with, say, Intel so that every time a compiler ran on the > system, secret code was discreetly inserted into the binary, it would be > nearly impossible to detect and a very elegant solution to a tough problem. Indeed it is really paranoid territory, but now doesn't seem quite as far fetched as one originally thought a few years ago! We'll still trust (we have to; we have no other choice), but the level of trust in computers in general has certainly gone down a notch and will never quite be the same. -- https://mail.python.org/mailman/listinfo/python-list
Re: Chardet, file, ... and the Flexible String Representation
On 09/09/2013 08:28 AM, [email protected] wrote: > Comment: Such differences never happen with utf. But with utf, slicing strings is O(n) (well that's a simplification as someone showed an algorithm that is log n), whereas a fixed-width encoding (Latin-1, UCS-2, UCS-4) is O(1). Do you understand what this means? > Complicate and full of side effects, eg : > sys.getsizeof('a') > 26 sys.getsizeof('aé') > 39 Why on earth are you doing getsizeof? What are you expecting to prove? Why are you even trying to concern yourself with implementation details? As a programmer you should deal with unicode. Period. All you should care about is that you can properly index or slice a unicode string and that unicode strings can be operated on at a reasonable speed. IE string[4] should give you the character at position 4. len(string) should return the length of the string in *characters*. The byte encoding used behind the scenes is of no consequence other than speed (and you have not shown any problem with speed). > > Is not a latin-1 "é" supposed to count as a latin-1 "a" ? Of course it does. 'aé'[0] == 'a' and 'aé'[1] == 'é'. len('aé') returns 2. > I picked up random methods, there may be variations, basically > this general behaviour is always expected. Eh? Can you point to something in the unicode spec that doesn't work? I don't even know that much about unicode yet it's clear you're either deliberately muddying the waters with your stupid and pointless arguments against FCS or you don't really understand the difference between unicode and byte encoding. Which is it? -- https://mail.python.org/mailman/listinfo/python-list
python REST API access fails after adding date to URL
Hi,
So the REST API calls work great with out the URL appended to the URL.However
as soon as I do add the URL, because I want to retrieve the data on a daily
basis, the calls fail and the server will return a 401 and say signature
invalid.The code is below:
import oauth2 as oauth
import time
from random import getrandbits
from base64 import b64encode
import hashlib
import urllib
import hmac
import base64
import urllib2
import httplib
import requests
CONSUMER_KEY=''
CONSUMER_SECRET=''
TOKEN_KEY=''
TOKEN_SECRET=''
def getURL(baseURL,params):
sortedParams = sorted(params.items())
for head in sortedParams:
print head[0]
print head[1]
baseURL += '&' + head[0] + '="' + head[1] + '"'
print baseURL
return baseURL
#set header parameters
http_headers = {}
http_headers['oauth_version'] = '1.0'
http_headers['oauth_nonce'] = oauth.generate_nonce()
http_headers['oauth_consumer_key'] = CONSUMER_KEY
http_headers['oauth_signature_method'] = 'HMAC-SHA1'
http_headers['oauth_token'] = TOKEN_KEY
http_headers['oauth_timestamp'] = str(int(time.time()))
#base url
base_url =
'https://dacv.liveperson.net/dataAccess/account/accountNumber/visitorSession'
#sort headers in lexicographical order and encode url
params = urllib.urlencode(sorted(http_headers.items()))
encoded_url = urllib.quote_plus(base_url)
#generate base string with all headers,encoded and ready to generate signature
signature_base_string = 'GET&' + encoded_url + '&' + urllib.quote_plus(params)
#generate signiture
key = CONSUMER_SECRET + '&' + TOKEN_SECRET
hashed = hmac.new(key, signature_base_string, hashlib.sha1)
http_headers['oauth_signature'] =
urllib.quote_plus(base64.b64encode(hashed.digest()))
#set up header
oauth_header = 'OAuth oauth_consumer_key="' +
http_headers['oauth_consumer_key'] + '",' +'oauth_nonce="' +
http_headers['oauth_nonce'] + '",' +'oauth_signature_method="' +
http_headers['oauth_signature_method'] + '",' +'oauth_token="' +
http_headers['oauth_token'] + '",' +'oauth_timestamp="' +
http_headers['oauth_timestamp'] + '",' +'oauth_version="' +
http_headers['oauth_version'] + '",' +'oauth_signature="' +
http_headers['oauth_signature'] + '"'
req = urllib2.Request(base_url)
req.add_header('Authorization',oauth_header)
response = urllib2.urlopen(req)
print response
--
https://mail.python.org/mailman/listinfo/python-list
Re: Chardet, file, ... and the Flexible String Representation
On 9/9/13 10:28 AM, [email protected] wrote: Le vendredi 6 septembre 2013 17:46:14 UTC+2, Piet van Oostrum a écrit : [email protected] writes: The Flexible String Representation has conceptually to face the same problem. It splits "unicode" in chunks and it has to solve two problems at the same time, the coding and the handling of multiple "char sets". The problem? It fails. "This poor Flexible String Representation does not succeed to solve the problem it create itsself." The FSR does not split unicode in chuncks. It does not create problems and therefore it doesn't have to solve this. The FSR simply stores a Unicode string as an array[*] of ints (the Unicode code points of the characters of the string. That's it. Then it uses a memory-efficient way to store this array of ints. But that has nothing to do with character sets. The same principle could be used for any array of ints. So you are seeking problems where there are none. And you would have a lot more peace of mind if you stopped doing this. [*] array in the C sense. -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- Due to its nature, a character cann't be handled in the same way a one another type. That's the purpose of the UTF. - Chunk latin-1, perfomance ref: timeit.timeit("a = 'hundred'; 'x' in a") 0.13144639994075646 timeit.timeit("a = 'hundrez'; 'x' in a") 0.13780295544393084 Chunk ucs2, perfomance timeit.timeit("a = 'hundre€'; 'x' in a") 0.23505392241617074 Chunk ucs4, perfomance timeit.timeit("a = 'hundre\U0001d11e'; 'x' in a") 0.26266673650735584 Comment: Such differences never happen with utf. - Chunk latin-1, memory sys.getsizeof('a') 26 Chunk ucs2, memory sys.getsizeof('€') 40 Comment: 14 bytes more than latin-1 Chunk ucs4, memory sys.getsizeof('\U0001d11e') 44 Comment: 18 bytes more than latin-1 Comment: With utf, a char (in string or not) never exceed 4 bytes. - 'a' + '€' in utf, conceptually Concatenate the *unicode tranformation units*. Some kind of a real direct 'a' + '€'. 'a' + '€' in FSR, conceptually 1) Check the "internal coding" of 'a' 2) Check the "internal coding" of '€' 3) Compare these codings 4a) If they match, concatenate the bytes 4b) If they do not match 5) Reencode the string which has to 6) Concatenate 7) Set the "internal coding" status for further processing - Complicate and full of side effects, eg : sys.getsizeof('a') 26 sys.getsizeof('aé') 39 Is not a latin-1 "é" supposed to count as a latin-1 "a" ? I picked up random methods, there may be variations, basically this general behaviour is always expected. jmf jmf, thanks for your reply. You've calmed my fears that there is something wrong with the Flexible String Representation. None of the examples you show demonstrate any behavior contrary to the Unicode spec. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Can I trust downloading Python?
On 09/09/2013 10:40 AM, William Ray Wing wrote: > I think that is pretty far fetched. It requires recognition that a > compiler is being compiled. I'd be REALLY surprised if there were a > unique sequence of hardware instructions that was common across every > possible compiler (current and future) and which wouldn't (couldn't) > exist in arbitrary non-compiller execution, which could be used to > trigger insertion of a backdoor. Agreed. Most of the damage done by the NSA is in the realm of social engineering more than technical. IE they compromise companies more than the algorithms themselves. The end points always are the weak things. And yes, Free software that is open source is more resistant to such tampering. -- https://mail.python.org/mailman/listinfo/python-list
Re: Can I trust downloading Python?
On Sep 9, 2013, at 12:23 PM, Michael Torrie wrote: > On 09/09/2013 05:02 AM, Anthony Papillion wrote: >> But (and this is stepping into *really* paranoid territory here. But >> maybe not beyond the realm of possibility) it would not be so hard to >> compromise compilers at the chip level. If the NSA were to strike an >> agreement with, say, Intel so that every time a compiler ran on the >> system, secret code was discreetly inserted into the binary, it would be >> nearly impossible to detect and a very elegant solution to a tough problem. > > Indeed it is really paranoid territory, but now doesn't seem quite as > far fetched as one originally thought a few years ago! We'll still > trust (we have to; we have no other choice), but the level of trust in > computers in general has certainly gone down a notch and will never > quite be the same. > > > -- > https://mail.python.org/mailman/listinfo/python-list I think that is pretty far fetched. It requires recognition that a compiler is being compiled. I'd be REALLY surprised if there were a unique sequence of hardware instructions that was common across every possible compiler (current and future) and which wouldn't (couldn't) exist in arbitrary non-compiller execution, which could be used to trigger insertion of a backdoor. -Bill -- https://mail.python.org/mailman/listinfo/python-list
Monitor key presses in Python?
Is there a way to detect if the user presses a key in Python that works on most OS's? I've only seen 1 method, and that only works in Python 2.6 and less. If you get the key, can you store it in a variable? Also, is there a way to create a callback in Python? -- https://mail.python.org/mailman/listinfo/python-list
Re: Monitor key presses in Python?
On 9/9/2013 13:39, [email protected] wrote: > Is there a way to detect if the user presses a key in Python that works on > most OS's? I've only seen 1 method, and that only works in Python 2.6 and > less. If you get the key, can you store it in a variable? > > Also, is there a way to create a callback in Python? What is usually meant by "a callback" is a function object. In Python, functions are first class objects. You just use the function name without the parentheses. def my_function(): print "Executing my_function" b = my_function # b is now a function object b() Likewise, instead of storing it in a global, you might pass it to a method which stores it as an object attribute, or whatever. Also of interest is that you can easily create partial functions, where some of the parameters are already decided. See the docs for functools.partial And if you're trying to use a method as a callback, you can store the bound-method, which is effectively a partial including the self parameter. Finally, don't forget lambda functions, which can be useful if you're trying to create a simple function and don't need a name for it. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Chardet, file, ... and the Flexible String Representation
On Sep 9, 2013 12:36 PM, wrote: > > On Fri, Sep 6, 2013, at 13:04, Chris Angelico wrote: > > On Sat, Sep 7, 2013 at 2:59 AM, wrote: > > > Incidentally, how does all this interact with ctypes unicode_buffers, > > > which slice as strings and must be UTF-16 on windows? This was fine > > > pre-FSR when unicode objects were UTF-16, but I'm not sure how it would > > > work now. > > > > That would be pre-FSR *with a Narrow build*, which was the default on > > Windows but not everywhere. But I don't know or use ctypes, so an > > answer to your actual question will have to come from someone else. > > I did a couple tests - it works as well as can be expected for reading, > but completely breaks for writing (due to sequence size checks not > matching) Do you mean that it breaks when overwriting Python string object buffers, or when overwriting arbitrary C strings either received from C code or created with create_unicode_buffer? If the former, I think that is to be expected since ctypes ultimately can't know what is the actual type of the pointer it was handed -- much as in C, that's up to the programmer to get right. I also think it's very bad practice to be overwriting those anyway, since Python strings are supposed to be immutable. If the latter, that sounds like a bug in ctypes to me. -- https://mail.python.org/mailman/listinfo/python-list
Re: Chardet, file, ... and the Flexible String Representation
On Fri, Sep 6, 2013, at 13:04, Chris Angelico wrote: > On Sat, Sep 7, 2013 at 2:59 AM, wrote: > > Incidentally, how does all this interact with ctypes unicode_buffers, > > which slice as strings and must be UTF-16 on windows? This was fine > > pre-FSR when unicode objects were UTF-16, but I'm not sure how it would > > work now. > > That would be pre-FSR *with a Narrow build*, which was the default on > Windows but not everywhere. But I don't know or use ctypes, so an > answer to your actual question will have to come from someone else. I did a couple tests - it works as well as can be expected for reading, but completely breaks for writing (due to sequence size checks not matching) -- https://mail.python.org/mailman/listinfo/python-list
Re: Monitor key presses in Python?
In <[email protected]> [email protected] writes: > Is there a way to detect if the user presses a key in Python that works on > most OS's? That depends on what you're really asking; your question is somewhat vague. Are you asking for a function that waits for the user to press a key and then returns the key that was pressed? Or are you asking for a function that detects whether a key has been pressed at all? -- John Gordon A is for Amy, who fell down the stairs [email protected] B is for Basil, assaulted by bears -- Edward Gorey, "The Gashlycrumb Tinies" -- https://mail.python.org/mailman/listinfo/python-list
Re: Chardet, file, ... and the Flexible String Representation
On Mon, Sep 9, 2013, at 15:03, Ian Kelly wrote: > Do you mean that it breaks when overwriting Python string object buffers, > or when overwriting arbitrary C strings either received from C code or > created with create_unicode_buffer? > > If the former, I think that is to be expected since ctypes ultimately > can't > know what is the actual type of the pointer it was handed -- much as in > C, > that's up to the programmer to get right. I also think it's very bad > practice to be overwriting those anyway, since Python strings are > supposed > to be immutable. > > If the latter, that sounds like a bug in ctypes to me. I was talking about writing to the buffer object from python, i.e. with slice assignment. >>> s = 'Test \U0001' >>> len(s) 6 >>> buf = create_unicode_buffer(32) >>> buf[:6] = s TypeError: one character unicode string expected >>> buf[:7] = s ValueError: Can only assign sequence of same size >>> buf[:7] = 'Test \ud800\udc00' >>> buf[:7] 'Test \U0001' # len = 6 Assigning with .value works, however, which may be a viable workaround for most situations. The "one character unicode string expected" message is a bit cryptic. -- https://mail.python.org/mailman/listinfo/python-list
Re: [python-committers] [RELEASED] Python 3.4.0a2
2013/9/9 Antoine Pitrou : > Le Mon, 9 Sep 2013 14:30:50 +0200, > Victor Stinner a écrit : >> 2013/9/9 Larry Hastings : >> > Python 3.4 includes a range of improvements of the 3.x series, >> > including hundreds of small improvements and bug fixes. Major new >> > features and changes in the 3.4 release series so far include: >> > >> > * PEP 446, changing file descriptors to not be inherited by default >> >in subprocesses >> >> The title of the PEP is "Make newly created file descriptors >> non-inheritable". It has an impact on all functions creating files and >> sockets not only the subprocess module. > > I don't think Larry's description is wrong. "Non-inheritable" is a > shorthand for "non-inheritable in subprocesses" with "subprocesses" > taken in the general sense (i.e. not only created with the subprocess > module). Oh, I misunderstood "in subprocesses", I read "in the subprocess module". The definition of FD inheritance is tricky. For example, on UNIX "non-inheritable" file descriptors are still inherited at fork :-) I hope that the documentation is explicit enough: http://docs.python.org/dev/library/os.html#inheritance-of-file-descriptors Victor -- https://mail.python.org/mailman/listinfo/python-list
a gift function and a question
Dear all, I have a gift for mailing list: def integerToPersian(number): listedPersian = ['۰','۱','۲','۳','۴','۵','۶','۷','۸','۹'] listedEnglish = ['0','1','2','3','4','5','6','7','8','9'] returnList = list() listedTmpString = list(str(number)) for i in listedTmpString: returnList.append(listedPersian[listedEnglish.index(i)]) return ''.join(returnList) When you call it such as : "integerToPersian(3455)" , it return ۳۴۵۵, ۳۴۵۵ is equivalent to 3455 in Persian and Arabic language.When you read a number such as reading from databae, and want to show in widget, this function is very useful. My question is , do you have reverse of this function? persianToInteger? Yours, Mohsen -- https://mail.python.org/mailman/listinfo/python-list
Re: Chardet, file, ... and the Flexible String Representation
On 9/9/2013 12:38 PM, Ned Batchelder wrote: jmf, thanks for your reply. You've calmed my fears that there is something wrong with the Flexible String Representation. None of the examples you show demonstrate any behavior contrary to the Unicode spec. The goals of the new unicode implementation: 1. one implementation on all platforms, working the same on all platforms. 2. works correctly 3. O(1) indexing 4. save as much space as sensibly possible 5. not too much time penalty for the space saving. The new implementation succeeded on all points. It exceeded the goal for 5. With much optimization work, there essentially is no overall time penalty left. Jmf's size examples show success with respect to goal 4. He apparently disagrees with that goal and would replace it with something else. At least some of his time examples show that saving space can save time, as was predicted when the FSR was being developed. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Monitor key presses in Python?
On Mon, 09 Sep 2013 10:39:43 -0700, eamonnrea wrote:
> Is there a way to detect if the user presses a key in Python that works
> on most OS's? I've only seen 1 method, and that only works in Python 2.6
> and less.
http://code.activestate.com/recipes/577977
I have just tried the above under Linux in Python 3.3, and it works fine.
I have no way of testing it under Windows.
> If you get the key, can you store it in a variable?
You're new to programming, aren't you? :-)
Yes you can store it in a variable. Anything that is returned can be
stored in a variable. Here is an example:
py> def example():
... print("Press any character key... ")
... c = getch()
... print("You typed: '%c'" % c)
...
py> example()
Press any character key...
You typed: 'y'
The above is running under Python 3.3.
> Also, is there a way to create a callback in Python?
The answer to your question as you ask it is "Yes, naturally." Callback
is short for *callback function* and describes the *purpose* of the
function, not how you write it or what it does.
But a better answer is, "A callback to what? It depends on what is doing
the calling back."
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: a gift function and a question
On Mon, Sep 9, 2013, at 16:10, Mohsen Pahlevanzadeh wrote:
> My question is , do you have reverse of this function? persianToInteger?
The int constructor is able to handle different forms of decimal
numerals directly:
>>> int('\u06f3\u06f4\u06f5\u06f5')
3455
--
https://mail.python.org/mailman/listinfo/python-list
Re: sqlite issue in 2.7.5
On Tuesday, September 3, 2013 8:22:42 AM UTC-4, Alister wrote: > On Mon, 02 Sep 2013 22:13:27 +, Joseph L. Casale wrote: > > > > > I have been battling an issue hopefully someone here has insight with. > > > > > > I have a database with a few tables I perform a query against with some > > > joins against columns collated with NOCASE that leverage = comparisons. > > > > > > Running the query on the database opened in sqlitestudio returns the > > > results in under a minute. Running the query in Python with sqlite3 > > > doesn't return results for several hours. I haven't figured out what > > > pragmas or other shortcuts sqlitestudio uses to provide the results so > > > fast. > > > > > > Using apsw returns the dataset nearly instantaneously but the > > > connection/cursor/commit differences are too drastic and would force far > > > too large a rewrite for the module change. > > > > > > Anyone by chance know the underlying changes required in the sqlite3 > > > module to replicate what sqlitestudio is doing behind the scenes? > > > > > > Thanks, > > > jlc > > > > you are almost certainly doing something drastically wrong > > can you provides examples of your code & the data structure otherwise I > > doubt that anyone will be able to assist. > > > -- > > To err is human, to forgive, beyond the scope of the Operating System. This pragma speeds up most processes 10-20 times (yes 10-20): pragma synchronous=OFF See the SQLITE documentation for an explanation. I've found no problems with this setting. -- https://mail.python.org/mailman/listinfo/python-list
Re: Can I trust downloading Python?
On Mon, 09 Sep 2013 12:19:11 +, Fattburger wrote:
> On Sun, 08 Sep 2013 03:37:15 +, Dave Angel wrote:
>
>> 1) what OS are you running? Actually, we can be pretty sure you're
>> running Windows, since any other common operating system would have
>> already included Python.
>
> Plus I don't often run into Linux users who worry about viruses, unless
> the braces-and-pimples crowd has expanded its horizons recently and
> started creating malware that does anything in Linux.
Hello, the 1990s called and want their stereotypes back.
Malware in 2013 is not about loser nerds erasing your hard drive for the
lulz. It's a multi-million dollar a year business, mostly driven by
spammers, but with small yet profitable niche markets for industrial
espionage and blackmail ("we've encrypted your files -- pay us $100 and
we'll send you the key"). Plus so-called law enforcement[1] uses it to
break into people's computers, for keylogging, etc., and you better
believe they have cracks targeted at Linux. Of course, Linux is a much
harder target than the average unpatched Windows box, and there are
probably easier ways to get access to your files if they really need to.
But really, we've learned *nothing* from the viruses of the 1990s.
Remember when we used to talk about how crazy it was to download code
from untrusted sites on the Internet and execute it? We're still doing
it, a hundred times a day. Every time you go on the Internet, you
download other people's code and execute it. Javascript, Flash, HTML5,
PDF are all either executable, or they include executable components. Now
they're *supposed* to be sandboxed, but we've gone from "don't execute
untrusted code" to "let's hope my browser doesn't have any bugs that the
untrusted code might exploit".
The people driving malware these days are not script-kiddies, but
professionals, up to and including some of the smartest and most highly
funded professionals in the world. Stuxnet anyone?
[1] I say "so-called", because far too often the people who are supposed
to be upholding the law are actually breaking the law with impunity.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
RE: sqlite issue in 2.7.5
> This pragma speeds up most processes 10-20 times (yes 10-20): > pragma synchronous=OFF > > See the SQLITE documentation for an explanation. > I've found no problems with this setting. Aside from database integrity and consistency? :) I have that one set to OFF as my case mandates data processing and the database is secondary and not re-used, nor required if the process halts. The issue I actually had was after several large bulk inserts, statistics for indices were no longer valid and the statements performing several joins that would leverage them were not performing well. Not knowing this and accessing the data from different methods would cause the symptoms to manifest to varying degrees. Ultimately, after all the inserts I run an ANALYZE command that takes ~30 seconds and a query that normally takes ~2 hours was done in less than 2 seconds. jlc -- https://mail.python.org/mailman/listinfo/python-list
Re: Can I trust downloading Python?
On Sun, 08 Sep 2013 03:37:15 +, Dave Angel wrote: > You can run a 32bit Python on 64bit OS, but not the oter way > around. And most people just match the bitness of Python against the > bitness of the OS. AFAICT, most people run 32-bit Python on any version of Windows. [And this isn't limited to Python; most of the software on my Win64 system is 32-bit. And most of the 64-bit software is accounted for by software which has to be 64-bit due to containing device drivers, shell extensions or similar.] Any add-on package which provides pre-compiled binaries will provide 32-bit binaries. Some of them will also provide 64-bit binaries, some of them won't. So unless you think that you might need to use more than 3-4 GiB of RAM for a single Python process, or you need to use certain libraries which are only available as 64-bit, getting the 32-bit version is typically the safest option. -- https://mail.python.org/mailman/listinfo/python-list
Re: Monitor key presses in Python?
On Mon, 09 Sep 2013 10:39:43 -0700, eamonnrea wrote: > Is there a way to detect if the user presses a key in Python that works on > most OS's? I've only seen 1 method, and that only works in Python 2.6 and > less. There's no "generic" solution to this. At a minimum, there's getting "key presses" from a windowing system and getting character input from a terminal or console. The two cases are themselves quite different, and each case has differences between operating systems. -- https://mail.python.org/mailman/listinfo/python-list
Re: Weighted choices
>> I coach a flag football team of 11-year-olds. A stated goal of the >> league is that every player should get nearly equal playing time and >> that winning is of secondary importance. That said, some players just >> can't throw the ball at all, and having a quarterback who cannot throw >> is no fun for anyone. The other coach and I will pick two players who >> will be the quarterback for any given snap. The other players can play >> any position (center, receiver, runner) other than quarterback. >> >> The game is 5-on-5 and our roster contains ten players, and we can >> expect a random player or two missing on any given week. I'm trying >> to come up with a system that causes at least one of those >> quarterbacks to be on the offensive field on every play. Further, to >> compensate for the fact that the quarterback gets to touch the ball on >> every play, we want the quarterbacks to appear at the non-quarterback >> positions somewhat less than the other players. >> >> This is all quite challenging. 11-year-olds are exquisitely tuned to >> unfairness and most have a keen idea of the play that will surely >> score a touchdown if only the clueless coach would let them run it. >> Oh, and the originator of this play will be the key >> quarterback/runner/receiver for the play. Oh, and in case the coach >> forgets, they will remind him. > > OK, you're well inside the "finite" domain. Also, you probably want less > than the "natural" randomness. I'd probably shuffle the potential > quarterbacks and the others in independent lists, and then pick one half of > each to form a team. The other half would play in the next game. > Additionally you can keep track of every player's total number of games and > games not played in a row, and apply a correction if either exceeds a limit > acceptable for a kid. PIcking half to play one game and half to play the other is not an option. For one, there really isn't a concept of half when a variable number of players are available on a given Saturday. For two, we could have an unexpected absence, or during the game an injury. For three, the parents paid to have their child play in the league, and the league runs until the end of October, not long enough for that strategy to work out. -- https://mail.python.org/mailman/listinfo/python-list
Re: Monitor key presses in Python?
On 09/09/2013 11:39 AM, [email protected] wrote: > Is there a way to detect if the user presses a key in Python that > works on most OS's? I've only seen 1 method, and that only works in > Python 2.6 and less. If you get the key, can you store it in a > variable? > > Also, is there a way to create a callback in Python? Some python programs display a graphical user interface. Others run in a text-mode console (dos prompt, unix shell, etc). And yet others don't have any display at all. If you're talking about a graphical user interface app (windows, dialogs, buttons, etc), then you'll have to rely on the particular user interface library you are using to provide that sort of access. If you're just running in a dos box, or a unix terminal, then there are other ways of doing what you want, but I'm not sure any one way is portable across all operating systems. I did find this code segment that claims to work on windows and unix: http://code.activestate.com/recipes/134892/ Anyway tell us more about what environment and kind of program you are dealing with. As for callbacks, of course. functions are objects in python. You can pass them as arguments, assign them to variables, and then call them. All graphical user interface libraries rely on them to handle events. -- https://mail.python.org/mailman/listinfo/python-list
Re: Chardet, file, ... and the Flexible String Representation
On Mon, 09 Sep 2013 11:05:44 -0600, Michael Torrie wrote: > On 09/09/2013 08:28 AM, [email protected] wrote: >> Comment: Such differences never happen with utf. > > But with utf, slicing strings is O(n) (well that's a simplification as > someone showed an algorithm that is log n), whereas a fixed-width > encoding (Latin-1, UCS-2, UCS-4) is O(1). UTF-32 is fixed-width. UTF-16 is not, but if you limit yourself to only characters in the Basic Multilingual Plane, it is functionally equivalent to UCS-2 and therefore fixed-width. > Do you understand what this means? Talking about "utf" in general as JMF does is a good sign that he doesn't. Which UTF? I know of at least eight: UTF-1 UTF-7 UTF-8 UTF-9 # this one is a joke, but it does work UTF-16 # in two varieties, big-endian and little-endian UTF-18 # another joke UTF-32 # likewise two varieties UTF-EBCDIC although only 3 (perhaps 4, if you include UTF-7) are in common use. [...] > I don't even know that much about unicode yet it's clear you're either > deliberately muddying the waters with your stupid and pointless > arguments against FCS or you don't really understand the difference > between unicode and byte encoding. Which is it? I have been watching JMF get a mad-on about the flexible string representation since he first noticed it, and in my opinion, his complaints are based entirely on resentment that ASCII users save more memory than non-ASCII users. Even if it means everyone is worse off, he is utterly opposed to giving ASCII users any benefit. Of course, he neglects to consider that *every single Python user* is an ASCII user, since most strings in Python are pure ASCII. Names of builtins, standard library modules, variables, attributes, most of them are ASCII. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Building tkinter on Windows
On Monday, September 9, 2013 12:43:16 AM UTC-7, Terry Reedy wrote: > Some combination of the README instructions, external.bat, and the > > project files are not correct. There may be an issue on the tracker. I > > believe I copied tcl85g.dll and tk85g.dll into .../py3x/pcbuild from > > .../tcltk/bin and that resolved the problem for me. But you say you did > > that. Did _tkinter_d.pyd get built (in pcbuild)? Well, after doing a clean clone and rebuilding everything it worked. I'm not sure what the issue was, but something must've went wrong the first time. I see you've opened an issue about this. I think the README definitely needs to be updated. It's not very user friendly and is somewhat ambiguous. Also, I think the dev guide could be improved as well. I think Windows users (actually, I'm more of Linux user, but whatever) tend to get the short end of the stick in a lot of open-source projects. I think that's a trend that needs to change. -- https://mail.python.org/mailman/listinfo/python-list
Language design
Some time ago, Tom Christiansen wrote about the "Seven Deadly Sins of Perl": http://www.perl.com/doc/FMTEYEWTK/versus/perl.html What design mistakes, traps or gotchas do you think Python has? Gotchas are not necessarily a bad thing, there may be good reasons for it, but they're surprising. To get started, here are a couple of mine: - Python is so dynamic, that there is hardly anything at all that can be optimized at compile time. - The behaviour of mutable default variables is a gotcha. - Operators that call dunder methods like __add__ don't use the same method resolution rules as regular methods, they bypass the instance and go straight to the type, at least for new-style classes. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: python REST API access fails after adding date to URL
[email protected] writes: > So the REST API calls work great with out the URL appended to the URL.However > as soon as I do add the URL, because I want to retrieve the data on a daily > basis, the calls fail and the server will return a 401 and say signature > invalid. Apparently, you do something wrong with the signing. It is highly likely that you must append any request parameters (as a query string) to the url before you determine the signature. Alternatively, the web service you contact might not expect a query string and might therefore not consider it when it recreates the signature. Then, the signature check would fail as you and the service compute it in a different way. Check the available documentation for your web service. Does it support request parameters (query strings). What does it (or the "oauth" spec) about signature requirements for those parameters. -- https://mail.python.org/mailman/listinfo/python-list
Re: a gift function and a question
I completed my two functions, i say may be poeple can use them:
##33
def integerToPersian(number):
listedPersian = ['۰','۱','۲','۳','۴','۵','۶','۷','۸','۹']
listedEnglish = ['0','1','2','3','4','5','6','7','8','9']
returnList = list()
for i in list(str(number)):
returnList.append(listedPersian[listedEnglish.index(i)])
return ''.join(returnList)
def persianToInterger(persianNumber):
listedTmpString = list(persianNumber.decode("utf-8"))
returnList = list()
for i in listedTmpString:
returnList.append(unicodedata.digit(i))
return int (''.join(str(x) for x in returnList))
###33
On Mon, 2013-09-09 at 16:20 -0400, [email protected] wrote:
> On Mon, Sep 9, 2013, at 16:10, Mohsen Pahlevanzadeh wrote:
> > My question is , do you have reverse of this function? persianToInteger?
>
> The int constructor is able to handle different forms of decimal
> numerals directly:
>
> >>> int('\u06f3\u06f4\u06f5\u06f5')
> 3455
--
https://mail.python.org/mailman/listinfo/python-list
