Re: testing code
On Sunday, 8 July 2018 11:52:39 UTC+5:30, Jim Lee wrote: > On 07/07/18 21:21, Sharan Basappa wrote: > > > > sorry. there was a copy paste error when i posted. I pasted test_2.py for > > both the files: > > > > here are the files again. The issue remains. > > [...] > > > > output: > > %run "D:/Projects/Initiatives/machine learning/programs/test_2_test.py" > > 30 > > [11:24 PM jlee@kerndev ~] $cat test_2.py > x = 10 > y = 20 > > c = x-y > > print c > > def func1(): > return x+y > > [11:24 PM jlee@kerndev ~] $cat test_2_test.py > import test_2 > > x = test_2.func1() > print x > [11:24 PM jlee@kerndev ~] $python test_2_test.py > -10 > 30 > [11:24 PM jlee@kerndev ~] $ > > > As you can see, the code from the import is indeed executed by the > python interpreter. > > I'm not familiar with the "%run" prefix in your command - some sort of > windows-ism? > > -Jim i think I figured out the issue. I am running this in Canopy. When I use Canopy Gui to run this, it appears that it loads the imported file only once. So, when I re-start canopy then everything goes fine the first time. When I use command prompt then it works all well. PS: run is nothing but the front end command that Canopy uses to run Python in the background. -- https://mail.python.org/mailman/listinfo/python-list
Re: testing code
Am 08.07.18 um 06:21 schrieb Sharan Basappa: sorry. there was a copy paste error when i posted. I pasted test_2.py for both the files: here are the files again. The issue remains. output: %run "D:/Projects/Initiatives/machine learning/programs/test_2_test.py" 30 Jim spotted it... '%run' is in IPython, right? "import" statements are executed only once for a given module (that's the purpose) - you have probably modified your imported file, and not restarted the interpreter. The second time you then import it, nothing happens. If you restart your interpreter, you should see both lines printed. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
Chris Angelico : > On Sun, Jul 8, 2018 at 11:04 AM, Steven D'Aprano > wrote: >>> The only thing Python should guarantee is that the data structures stay >>> "coherent" under race conditions. In other words, there cannot be a >>> segmentation fault. For example, if two threads executed this code in >>> parallel: >>> >>> global i >>> i = 1 >>> i += 1 >>> >>> a legal end result could be that i contains the string "impossible". >> >> That wouldn't be coherent. The only coherent results are that i could >> equal either 2 or 3: > > Python threads don't switch only between lines of code, so the actual > interaction is a bit more complicated than you say. [...] > > But you're absolutely right that there are only a small handful of > plausible results, even with threading involved. You are on the right track, Chris, but you are still deducing behavior from a particular implementation. For example Java's definition is approximately the one I give above: Without correct synchronization, very strange, confusing and counterintuitive behaviors are possible. https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.htm l#jls-17.4.5> And we know that Python has been implemented using Java... Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: about main()
i appreciate every suggestions though ^^_ Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ Ahh, yes. The elegant purity of reading every email that goes through > this mailing list, or the practicality of killfiling people who can't > be bothered to use correct grammar in English, and probably are > comparably sloppy in their code. It's a very important decision to > make. > > ChrisA > -- https://mail.python.org/mailman/listinfo/python-list
Re: about main()
non native speakers try to do their best as for ... who can't be bothered to use correct grammar in English, and probably are comparably sloppy in their code. ... maybe but check INADA NAOKI Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ or the practicality of killfiling people who can't > be bothered to use correct grammar in English, and probably are comparably sloppy in their code. It's a very important decision to > make. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
On Sun, 08 Jul 2018 10:52:15 +0300, Marko Rauhamaa wrote: > You are on the right track, Chris, but you are still deducing behavior > from a particular implementation. For example Java's definition is > approximately the one I give above: > >Without correct synchronization, very strange, confusing and >counterintuitive behaviors are possible. Indeed, and that applies to all languages with threading, including Python. But notice that it doesn't say: Without correct synchronization, impossible things are possible. >https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.htm >l#jls-17.4.5> You seem to have read this as "Java threading can do impossible things", but I think the correct reading of the article is "Here are the possible things that Java threading can do to mess with your mind". That's a much smaller subset of things which can go wrong. (But still pretty big.) See, for example Example 17.4-1, which explicitly shows that the Java execution model is permitted to reorder statements: r1 = A; B = 1; may be reordered to B = 1; r1 = A; That's harmless in single-threaded code, but risky in multi-threaded code. The result is that in the example given, r1 could end up being set to 1 instead of the expected values -- but it cannot possibly be set to the string "impossible", since that goes against the Java type system. In Python, there's no possible order of operations of assigning 1 and adding 1 that could result in a string. No Python compiler or interpreter is permitted to evaluate `1 + 1` or `2 + 1` as the string "impossible", even if threads are involved. (That's not to say that threads might not assign a string to the variable we expected to contain 2, but it would have to do so by assignment, not by mucking about with the execution order of integer addition.) In the case of Example 17.4-1, starting with A = B = 0, two threads execute: Thread 1:r2 = A; B = 1; Thread 2:r1 = B; A = 2; Java compilers are permitted to inspect each thread *in isolation*, decide that the order of lines is invisible to the caller, and so re- order them. The result of that is that those four lines can be executed in any permutation, giving a total of 24 separate possibilities. py> from itertools import permutations py> instructions = ["r2 = A;", "B = 1;", "r1 = B;", "A = 2;"] py> len(list(permutations(instructions))) 24 But Python (at least for now) cannot do this. It has a more deterministic execution order which guarantees top-to-bottom execution of Python statements. That implies that there are only *six* possible execution orders of those two threads (which is still enough to add non-determinism to your code!) not twenty-four: r2 = A; B = 1; r1 = B; A = 2; r2 = A; r1 = B; B = 1; A = 2; r2 = A; r1 = B; A = 2; B = 1; r1 = B; A = 2; r2 = A; B = 1; r1 = B; r2 = A; A = 2; B = 1; r1 = B; r2 = A; A = 2; B = 1; and that remains true even if the underlying implementation is written in Java, or Malbolge for that matter. > And we know that Python has been implemented using Java... That's irrelevant. A legal Python does not inherit the quirks of the underlying implementation -- it must still follow the rules of the language, or it isn't Python. Java is statically typed, with machine ints, Python is dynamically typed, with no machine ints. Relevant: http://doc.pypy.org/en/latest/cpython_differences.html http://docs.micropython.org/en/latest/unix/genrst/index.html -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
Steven D'Aprano : > Changing implementations from one which is thread safe to one which is > not can break people's code, and shouldn't be done on a whim. > Especially since such breakage could be subtle, hard to notice, harder > to track down, and even harder still to fix. Java's HotSpot does it all the time, and it did result in code breakage -- although the code was broken to begin with. > So there is no coherent way to get a result of "impossible" from just > adding 1 to 1 in any coherent implementation of Python. Back to Java, there was a real case of 64-bit integer operations not being atomic on 32-bit machines. Mixing up upper and lower halves between threads could result in really weird evaluations. More importantly, this loop may never finish: # Initially quit = False # Thread 1 global quit while not quit: time.sleep(1) # Thread 2 global quit quit = True That's the reality in Java and C. I see no reason why that wouldn't be the reality in Python as well -- unless the language specification said otherwise. Marko PS My example with "impossible" being the result of a racy integer operation is of course unlikely but could be the outcome if the Python runtime reorganized its object cache on the fly (in a hypothetical implementation). -- https://mail.python.org/mailman/listinfo/python-list
Re: Generate a static back-of-a-book style index?
On 2018-07-08 13:34, Cameron Simpson wrote: > On 07Jul2018 21:57, Tim Chase wrote: > >On 2018-07-08 12:12, Cameron Simpson wrote: > >> On 07Jul2018 20:11, Skip Montanaro > >> wrote: > >> >> Have you looked at the ptx command? Might be called "gptx" > > It's associated with the troff stuff generally. Maybe that's not > installed? On my OpenBSD (6.3) boxes, there's no nroff/troff/groff nor any ptx/gptx. On my FreeBSD (11.2) boxes, I have nroff/troff/groff available but no ptx/gptx available in base. One of the machines has coreutils installed which provides /usr/local/bin/gptx (and its man-pages). So I can find it and read about it. Just curious that it's fallen out of base on both Free & OpenBSD (don't have a NetBSD machine at hand to test that). -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: testing code
On Sunday, 8 July 2018 12:42:07 UTC+5:30, Christian Gollwitzer wrote: > Am 08.07.18 um 06:21 schrieb Sharan Basappa: > > sorry. there was a copy paste error when i posted. I pasted test_2.py for > > both the files: > > > > here are the files again. The issue remains. > > > output: > > %run "D:/Projects/Initiatives/machine learning/programs/test_2_test.py" > > 30 > > > > Jim spotted it... '%run' is in IPython, right? "import" statements are > executed only once for a given module (that's the purpose) - you have > probably modified your imported file, and not restarted the interpreter. > The second time you then import it, nothing happens. > > If you restart your interpreter, you should see both lines printed. > > Christian yes, exactly. this is the issue although execution is in Canopy and not in iPython -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: > Steven D'Aprano : >> Changing implementations from one which is thread safe to one which is >> not can break people's code, and shouldn't be done on a whim. >> Especially since such breakage could be subtle, hard to notice, harder >> to track down, and even harder still to fix. > > Java's HotSpot does it all the time, and it did result in code breakage > -- although the code was broken to begin with. I said "shouldn't be done", rather than claiming that was the situation right now with all compilers. But I'm willing to give a little bit of slack to aggressively optimizing compilers, provided they come with a warning. >> So there is no coherent way to get a result of "impossible" from just >> adding 1 to 1 in any coherent implementation of Python. > > Back to Java, there was a real case of 64-bit integer operations not > being atomic on 32-bit machines. Mixing up upper and lower halves > between threads could result in really weird evaluations. Oh don't get me wrong, I agree with you that threading can result in strange, unpredictable errors. That's why I try not to use threading. I have no illusions about my ability to debug those sorts of problems. > More importantly, this loop may never finish: > > # Initially > quit = False > > # Thread 1 > global quit > while not quit: > time.sleep(1) > > # Thread 2 > global quit > quit = True Assuming that thread 2 actually runs *at some point*, I don't see how that can't terminate. Neither thread sets quit to False, so provided thread 2 runs at all, it has to terminate. I suppose if the threading implementation *could* fall back to sequential code (thread 2 doesn't run until thread 1 finishes, which it never does...) that outcome is possible. But it would have to be a pretty poor implementation. Now if you said there were fifty threads (aside from the main thread, which is guaranteed to run) all reading quit, and only thread 50 ever assigns to it, I'd believe that perhaps thread 50 never gets a chance to run. But with just two threads? Explain please. > That's the reality in Java and C. I see no reason why that wouldn't be > the reality in Python as well -- unless the language specification said > otherwise. Because the Python core developers care more about correctness than speed. > Marko > > PS My example with "impossible" being the result of a racy integer > operation is of course unlikely but could be the outcome if the Python > runtime reorganized its object cache on the fly (in a hypothetical > implementation). That would be a cache bug :-) Not every interpreter bug should be considered the caller's fault :-) -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
On 2018-07-08 14:38, Steven D'Aprano wrote: On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: [snip] More importantly, this loop may never finish: # Initially quit = False # Thread 1 global quit while not quit: time.sleep(1) # Thread 2 global quit quit = True Assuming that thread 2 actually runs *at some point*, I don't see how that can't terminate. Neither thread sets quit to False, so provided thread 2 runs at all, it has to terminate. [snip] The compiler could look at the code for thread 1 and see that 'quit' is never assigned to, meaning that it could be "optimised" to: global quit if not quit: while True: time.sleep(1) In C you'd declare 'quit' as 'volatile' to tell the compiler that it could change unexpectedly, so don't make that assumption. -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
MRAB : > On 2018-07-08 14:38, Steven D'Aprano wrote: >> On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >> > [snip] >>> More importantly, this loop may never finish: >>> >>> # Initially >>> quit = False >>> >>> # Thread 1 >>> global quit >>> while not quit: >>> time.sleep(1) >>> >>> # Thread 2 >>> global quit >>> quit = True >> >> Assuming that thread 2 actually runs *at some point*, I don't see how >> that can't terminate. Neither thread sets quit to False, so provided >> thread 2 runs at all, it has to terminate. >> > [snip] > > The compiler could look at the code for thread 1 and see that 'quit' is > never assigned to, meaning that it could be "optimised" to: > > global quit > if not quit: > while True: > time.sleep(1) > > In C you'd declare 'quit' as 'volatile' to tell the compiler that it > could change unexpectedly, so don't make that assumption. C is an even tougher case. Even if the compiler kept on checking a volatile value, the CPU might never propagate the cache content to the other core. You'd need a memory barrier. In Java, "volatile" effectively creates a memory barrier, but in C (and C++) it does not. In C you need something like a mutex to see the effects of other threads running. (BTW, I think that's a terrible thing for the C standards committee to specify.) Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
Steven D'Aprano : > On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >> PS My example with "impossible" being the result of a racy integer >> operation is of course unlikely but could be the outcome if the Python >> runtime reorganized its object cache on the fly (in a hypothetical >> implementation). > > That would be a cache bug :-) > > Not every interpreter bug should be considered the caller's fault :-) Whether it's a bug or not depends on the language specification. Java has a very clear definition for correct synchronization. It's not so clear on what could happen in the event of a data race; it's not entirely unspecified, but the language spec admonishes the application to brace itself for surprising effects. If the Python Language Specification hasn't specified the effects of incorrect synchronization so we can rightly suppose that the results are unspecified. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
On Mon, Jul 9, 2018 at 2:11 AM, Marko Rauhamaa wrote: > MRAB : >> On 2018-07-08 14:38, Steven D'Aprano wrote: >>> On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >>> >> [snip] More importantly, this loop may never finish: # Initially quit = False # Thread 1 global quit while not quit: time.sleep(1) # Thread 2 global quit quit = True >>> >>> Assuming that thread 2 actually runs *at some point*, I don't see how >>> that can't terminate. Neither thread sets quit to False, so provided >>> thread 2 runs at all, it has to terminate. >>> >> [snip] >> >> The compiler could look at the code for thread 1 and see that 'quit' is >> never assigned to, meaning that it could be "optimised" to: >> >> global quit >> if not quit: >> while True: >> time.sleep(1) >> >> In C you'd declare 'quit' as 'volatile' to tell the compiler that it >> could change unexpectedly, so don't make that assumption. > > C is an even tougher case. Even if the compiler kept on checking a > volatile value, the CPU might never propagate the cache content to the > other core. You'd need a memory barrier. In Java, "volatile" effectively > creates a memory barrier, but in C (and C++) it does not. In C you need > something like a mutex to see the effects of other threads running. > > (BTW, I think that's a terrible thing for the C standards committee to > specify.) None of this has any impact on Python whatsoever. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Invalid error in python program
I miss studying in class 11 cbse.College as introduced us python. I installed it in my laptop but when I save and runed in idle mod. The 3.7.0 the 7 is highlighted and syntax error is showen. As showen in the screen shot below. Plz help me resolve this problem Ur faithful user Prafull. Thank you -- https://mail.python.org/mailman/listinfo/python-list
Re: Invalid error in python program
screenshots are not sent in this list, can you please copy paste th error or use paste bin? thanks ! Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ -- https://mail.python.org/mailman/listinfo/python-list
Re: Invalid error in python program
I'm guessing you may need some help in english writing too! Anyways, I don't think anyone here may want to make your homeworks for you... Regards, Etienne Le 2018-07-08 à 12:43, Prafull Ks a écrit : I miss studying in class 11 cbse.College as introduced us python. I installed it in my laptop but when I save and runed in idle mod. The 3.7.0 the 7 is highlighted and syntax error is showen. As showen in the screen shot below. Plz help me resolve this problem Ur faithful user Prafull. Thank you -- Etienne Robillard [email protected] https://www.isotopesoftware.ca/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
On Sun, 08 Jul 2018 19:35:55 +0300, Marko Rauhamaa wrote: > Steven D'Aprano : >> On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >>> PS My example with "impossible" being the result of a racy integer >>> operation is of course unlikely but could be the outcome if the Python >>> runtime reorganized its object cache on the fly (in a hypothetical >>> implementation). >> >> That would be a cache bug :-) >> >> Not every interpreter bug should be considered the caller's fault :-) > > Whether it's a bug or not depends on the language specification. "It is true that if you turn the indicator on at the same time that you turn the windshield wipers on, the car will explode in an enormous fireball releasing sufficient poisonous gases to kill everyone in a fifteen block radius. But we never said that it was safe to turn the indicator and windshield wipers on at the same time, so it's not a bug, its operator error." Compiler writers and language designers need to stop hiding behind specifications. No other industry so routinely tries (and too often succeeds) in playing the "but we never said our product wouldn't set you on fire" card with so little justification. > Java > has a very clear definition for correct synchronization. It's not so > clear on what could happen in the event of a data race; it's not > entirely unspecified, but the language spec admonishes the application > to brace itself for surprising effects. Incorrect synchronisation is irrelevant in this example. If the object cache is *ever* in an invalid state, such that (as per your example) the literal 1 (an int) could be evaluated as "impossible" (a string), that is a bug in the object management. Threads or no threads. The only excuse would be if the caller directly messed with the cache in an unsupported fashion (say, with ctypes). Software needs "fit for purpose" laws and end-user warranties with teeth. If that means that the software industry spends the next thirty years fixing bugs instead of adding features, that's a good thing. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
On Sun, 08 Jul 2018 16:37:11 +0100, MRAB wrote: > On 2018-07-08 14:38, Steven D'Aprano wrote: >> On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >> > [snip] >>> More importantly, this loop may never finish: >>> >>> # Initially >>> quit = False >>> >>> # Thread 1 >>> global quit >>> while not quit: >>> time.sleep(1) >>> >>> # Thread 2 >>> global quit >>> quit = True >> >> Assuming that thread 2 actually runs *at some point*, I don't see how >> that can't terminate. Neither thread sets quit to False, so provided >> thread 2 runs at all, it has to terminate. >> > [snip] > > The compiler could look at the code for thread 1 and see that 'quit' is > never assigned to, meaning that it could be "optimised" to: > > global quit > if not quit: > while True: > time.sleep(1) I'm glad you put "optimized" in scare quotes there, because any optimizer that did that to code that runs in a thread is buggy. The re-write has changed the semantics of the code. Of course a compiler "could" do anything. If it re-wrote the code to instead perform: while True: print(math.sin(random.random()+1) instead, we'd have no trouble recognising that the compiler has changed the semantics of our code to something we didn't write, and in just about every language apart from C, we would rightly call it a compiler bug. If I write "Do X", and the compiler instead executes "Do Y", that's a compiler bug. The compiler has one job: to take my source code and convert it to something which can be executed, and if it cannot do that faithfully, it is buggy. C is the special case: C programmers routinely blame *themselves* when the compiler changes "Do X" to "Do Y", because the standard says it is permitted to do anything it likes in the event of undefined behaviour. Talk about victims coming to rationalise their own abuse and identify with their abuser. W.A. Wulf might have been talking about C compilers when he wrote: "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity." > In C you'd declare 'quit' as 'volatile' to tell the compiler that it > could change unexpectedly, so don't make that assumption. You shouldn't need to tell the compiler to assume that the variable could change. In multi-threaded code, there's no justification for assuming the variable can't change unless you've done a whole-program analysis and can prove that *no* thread ever writes to that variable. Even in single-threaded code, I think that optimizations which change execution order are dubious. There's far too much opportunity for "it's not a bug, because the specification says we can deny it is a bug" faults. It's simply *bad engineering practice*. When engineers design a bridge or a road or a building, the builders have to faithfully follow the engineer's design, unless the design itself explicitly allows them to make substitutions. "The blueprints say these supporting pillars have to be filled with steel- reinforced concrete. How about we just fill them with empty cans instead, what could possibly go wrong?" http://shanghaiist.com/2016/02/08/taiwan_earthquake_building_collapse/ (Disclaimer: there seems to be some controversy over whether the cans were actually in supporting columns or not. But the point still stands.) -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
Chris Angelico : > On Mon, Jul 9, 2018 at 2:11 AM, Marko Rauhamaa wrote: >> MRAB : >>> In C you'd declare 'quit' as 'volatile' to tell the compiler that it >>> could change unexpectedly, so don't make that assumption. >> >> C is an even tougher case. Even if the compiler kept on checking a >> volatile value, the CPU might never propagate the cache content to >> the other core. You'd need a memory barrier. In Java, "volatile" >> effectively creates a memory barrier, but in C (and C++) it does not. >> In C you need something like a mutex to see the effects of other >> threads running. >> >> (BTW, I think that's a terrible thing for the C standards committee to >> specify.) > > None of this has any impact on Python whatsoever. [citation needed] Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
On Mon, Jul 9, 2018 at 4:57 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Mon, Jul 9, 2018 at 2:11 AM, Marko Rauhamaa wrote: >>> MRAB : In C you'd declare 'quit' as 'volatile' to tell the compiler that it could change unexpectedly, so don't make that assumption. >>> >>> C is an even tougher case. Even if the compiler kept on checking a >>> volatile value, the CPU might never propagate the cache content to >>> the other core. You'd need a memory barrier. In Java, "volatile" >>> effectively creates a memory barrier, but in C (and C++) it does not. >>> In C you need something like a mutex to see the effects of other >>> threads running. >>> >>> (BTW, I think that's a terrible thing for the C standards committee to >>> specify.) >> >> None of this has any impact on Python whatsoever. > > [citation needed] > Why? You might as well say "in Blurple, all integers greater than 5 compare equal to each other, and it's possible to implement a Python interpreter in Blurple, therefore we can't trust integer comparisons in Python". It's ridiculous to consider. The languages are completely independent. Are you assuming that Python's semantics are defined by the semantics of one possible implementation language? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
Chris Angelico : > Are you assuming that Python's semantics are defined by the semantics > of one possible implementation language? What are Python's semantics defined by? I've been using these: https://docs.python.org/3/reference/> https://docs.python.org/3/library/> Unfortunately, neither spec says anything about the atomicity of dict.setdefault(). Therefore, the application programmer must assume it is not atomic. In fact, as brought up in this discussion, the consultation of object.__hash__() and object.__eq__() almost guarantee the *non*-atomicity of dict.setdefault(). Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
On Mon, Jul 9, 2018 at 5:18 AM, Marko Rauhamaa wrote: > Chris Angelico : >> Are you assuming that Python's semantics are defined by the semantics >> of one possible implementation language? > > What are Python's semantics defined by? I've been using these: > >https://docs.python.org/3/reference/> > >https://docs.python.org/3/library/> > > Unfortunately, neither spec says anything about the atomicity of > dict.setdefault(). > > Therefore, the application programmer must assume it is not atomic. In > fact, as brought up in this discussion, the consultation of > object.__hash__() and object.__eq__() almost guarantee the > *non*-atomicity of dict.setdefault(). If by "atomic" you mean that absolutely no context switch can occur during setdefault, then it probably isn't. But the point of an atomic query/update operation is that there are exactly two possibilities: 1) The key did not exist in the dictionary. It now does, with the provided default, which was returned. 2) The key did exist in the dictionary. The provided default is ignored, and the previous value is returned. Neither object.__hash__ nor object.__eq__ gives any way for this to be violated (unless you mess with the concept of "the key did exist in the dictionary" by breaking the definition of equality, but that's nothing to do with atomicity). Here's the definition of setdefault: setdefault(key, default=None, /) method of builtins.dict instance Insert key with a value of default if key is not in the dictionary. Return the value for key if key is in the dictionary, else default. Simple semantics. Straight-forward. Now, maybe there's a bug in some implementation whereby threads can violate this; but that would be a bug to be fixed, and nothing more. You should be able to assume that it will behave as stated. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe way to add a key to a dict only if it isn't already there?
Chris Angelico :
> On Mon, Jul 9, 2018 at 5:18 AM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>> Are you assuming that Python's semantics are defined by the semantics
>>> of one possible implementation language?
>>
>> What are Python's semantics defined by? I've been using these:
>>
>>https://docs.python.org/3/reference/>
>>
>>https://docs.python.org/3/library/>
>>
>> Unfortunately, neither spec says anything about the atomicity of
>> dict.setdefault().
>>
>> Therefore, the application programmer must assume it is not atomic. In
>> fact, as brought up in this discussion, the consultation of
>> object.__hash__() and object.__eq__() almost guarantee the
>> *non*-atomicity of dict.setdefault().
>
> If by "atomic" you mean that absolutely no context switch can occur
> during setdefault, then it probably isn't. But the point of an atomic
> query/update operation is that there are exactly two possibilities:
>
> 1) The key did not exist in the dictionary. It now does, with the
> provided default, which was returned.
> 2) The key did exist in the dictionary. The provided default is
> ignored, and the previous value is returned.
This is a classic test-and-set race condition:
# Initially
assert "A" not in d
# Thread 1
d.setdefault("A", 1)
# Thread 2
d["A"] = 2
If dict.setdefault() is atomic, the end result in all timings must be:
d["A"] == 2
However, if dict.setdefault() is not atomic, the end result may also be:
d["A"] == 1
> Neither object.__hash__ nor object.__eq__ gives any way for this to be
> violated (unless you mess with the concept of "the key did exist in
> the dictionary" by breaking the definition of equality, but that's
> nothing to do with atomicity). Here's the definition of setdefault:
>
> setdefault(key, default=None, /) method of builtins.dict instance
> Insert key with a value of default if key is not in the dictionary.
>
> Return the value for key if key is in the dictionary, else default.
>
> Simple semantics. Straight-forward. Now, maybe there's a bug in some
> implementation whereby threads can violate this; but that would be a
> bug to be fixed, and nothing more. You should be able to assume that
> it will behave as stated.
Since atomicity is not guaranteed by the definition of the method, the
application programmer must be prepared for the end result to be 1 (or
even something completely different because the Language Specification
doesn't say anything about the outcome of data races).
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Generate a static back-of-a-book style index?
On 08Jul2018 06:47, Tim Chase wrote: On 2018-07-08 13:34, Cameron Simpson wrote: On 07Jul2018 21:57, Tim Chase wrote: >On 2018-07-08 12:12, Cameron Simpson wrote: >> On 07Jul2018 20:11, Skip Montanaro >> wrote: >> >> Have you looked at the ptx command? Might be called "gptx" It's associated with the troff stuff generally. Maybe that's not installed? On my OpenBSD (6.3) boxes, there's no nroff/troff/groff nor any ptx/gptx. On my FreeBSD (11.2) boxes, I have nroff/troff/groff available but no ptx/gptx available in base. One of the machines has coreutils installed which provides /usr/local/bin/gptx (and its man-pages). So I can find it and read about it. Just curious that it's fallen out of base on both Free & OpenBSD (don't have a NetBSD machine at hand to test that). I'm curious too. I haven't an explaination. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Invalid error in python program
On Sun, 08 Jul 2018 13:02:35 -0400, Etienne Robillard wrote: > I'm guessing you may need some help in english writing too! Now that's not fair. Not everyone is fluent in English and so long as they make a genuine attempt we should be kind enough to ignore minor spelling and grammatical errors. Like writing "make your homeworks" for "do your homework"... *wink* > Anyways, I don't think anyone here may want to make your homeworks for > you... Prafull is not asking for us to do his or her homework, but for help with basic syntax. That's allowed. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Invalid error in python program
On Sun, 08 Jul 2018 22:13:59 +0530, Prafull Ks wrote: > I miss studying in class 11 cbse.College as introduced us python. I > installed it in my laptop but when I save and runed in idle mod. The > 3.7.0 the 7 is highlighted and syntax error is showen. As showen in the > screen shot below. Unless you edit your code with Photoshop, please don't send screenshots. They make it hard for the blind and visually impaired, and make it difficult for us to copy and paste your code if we need to run it. Instead, always copy the relevant code and the FULL error message, and paste it directly in your message. Thank you. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Invalid error in python program
On Mon, Jul 9, 2018 at 10:02 AM, Steven D'Aprano wrote: > On Sun, 08 Jul 2018 22:13:59 +0530, Prafull Ks wrote: > >> I miss studying in class 11 cbse.College as introduced us python. I >> installed it in my laptop but when I save and runed in idle mod. The >> 3.7.0 the 7 is highlighted and syntax error is showen. As showen in the >> screen shot below. > > Unless you edit your code with Photoshop, please don't send screenshots. Obligatory XKCD: https://xkcd.com/1685/ ChrisA -- https://mail.python.org/mailman/listinfo/python-list
