Re: Enumerating all 3-tuples
On Tue, 13 Mar 2018 23:56:37 +0100, Denis Kasak wrote: [...] > The triples can be viewed as a pair of a pair and a natural number: > > (1,1),1 (1,1),2 (1,1),3 ... > (2,1),1 (2,1),2 (2,1),3 ... > (1,2),1 (1,2),2 (1,2),3 ... [...] > This leads fairly naturally to the implementation. > > from itertools import accumulate, count > > def c(i): > """ > Inverse of the Cantor pairing function, mapping N → N×N. """ > assert i >= 1 > > # partial sums of the series 1 + 2 + 3 + ... sums = > accumulate(count(1)) > n = 0 > > while True: > m = next(sums) > if m < i: > n += 1 > else: > r = m - i > break > > return r + 1, n - r + 1 > > > def c3(i): > """ > Inverse of the Cantor pairing function generalization to > triples, > mapping N → N×N×N. > """ > n, m = c(i) > return c(n) + (m,) > > Applying c3 to the natural numbers gives the sequence you wanted: Thanks! That looks interesting, I haven't had a chance to play with it in a lot of detail yet, but it looks to me like every time you generate a triple, it starts counting up from 1. So iterating over c3(1), c3(2), c3(4), ... c3(something big) is going to have O(N**2) performance. It's like the old joke about the Polish painter: http://global.joelonsoftware.com/English/Articles/BacktoBasics.html Since that's exactly what I need to do, that might be a problem. On the other hand, I doubt I'll need to generate more than a few thousand of these, so it might be fast enough. I guess I have to run some benchmarks to find out. But however they turn out, I appreciate your time and code. Thanks heaps! -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Multiprocessing on a remote host
On Wed, 21 Mar 2018 02:20:16 +, Larry Martell wrote: > Is there a way to use the multiprocessing lib to run a job on a remote > host? Don't try to re-invent the wheel. This is a solved problem. https://stackoverflow.com/questions/1879971/what-is-the-current-choice-for-doing-rpc-in-python I've used both rpyc and pyro, they work fine and are easy to learn. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Multiprocessing on a remote host
Is there a way to use the multiprocessing lib to run a job on a remote host? -- https://mail.python.org/mailman/listinfo/python-list
Re: Thank you Python community!
John Ladasky wrote: Yeah, it's either Python or that horrifying street drug PHP. I know which one I'm choosing. Python is definitely the best language for getting high on: https://xkcd.com/353/ -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Sig monster agency (was: Thank you Python community!)
Alister via Python-list writes: > maybe [Ben's signatures are not sarcasm] - I use fortune to generate > mine & it can be supprisingly apt at times Yes. They are randomly chosen by my sig monster when I compose a message; I have some option to ask for another, but no direct input in the selection. When my sig monster pulls a particularly apt aphorism from my curated database, I occasionally end the message with praise for my sig monster and offer it a biscuit, as is customary (and whimsical, because the sig monster typically doesn't eat them and shows no sign that it alters its behaviour in response to the offer). But too often when I include such praise for my sig monster, people get confused and think I'm offering *them* a cookie, or calling them a monster, or some such. Explaining what's going on gets strange :-) -- \ “Do unto others twenty-five percent better than you expect them | `\ to do unto you. (The twenty-five percent is [to correct] for | _o__)error.)” —Linus Pauling's Golden Rule | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Style Q: Instance variables defined outside of __init__
Steven D'Aprano writes: > What they came up with is that its really hard to do useful work for > large applications with 100% pure functional programming styles. As you > add functional techniques to your code, you find your code quality > increasing. Things like pure functions with no hidden state and no side > effects can have a massive positive effect on code quality -- up to a > point. > > As you approach closer and closer to 100% pure functional code, you get > fewer improvements and your code gets harder to write and maintain. Right. I hope no-one advocates a *purely* functional approach to any program that needs to do work on anything external. Functional programming is a paradigm that is an essential tool to *minimise* the side-effects of code, with a corresponding increase in the testability and therefore the confidence one can place in that code. Any program which needs to interact with systems outside itself – which is to say, any program which performs useful work, ultimately – must have side effects. So it's absurd to advocate removing *all* side effects. So, those who sneer that Python isn't purely functional are, in my view, paying Python a compliment: that it doesn't get in the way of doing useful work on things people care about getting done. Python supports a highly functional style, while not going IMO too far down the road of purity at the expense of usefulness. -- \“The reason we come up with new versions is not to fix bugs. | `\ It's absolutely not.” —Bill Gates, 1995-10-23 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Celestial Emporium of Benevolent Knowledge (was: Style Q: Instance variables defined outside of __init__)
Neil Cerutti writes: > The Introduction to Computer Science class I'm taking divided program > design into two categories: Top Down Design, and Object Oriented > Design. It's good, because it reminded me of the wisdom of dividing > memory into Random Access and Read Only. > > My automotive course will probaly divide cars into Automatic > Transmission, and Front Wheel Drive. Look to the classics. Jorge Luis Borges, 1942: Let us consider the eighth category [of those proposed by John Wilkins for a universal language], the category of stones. Wilkins divides them into common (silica, gravel, schist), modics (marble, amber, coral), precious (pearl, opal), transparent (amethyst, sapphire) and insolubles (chalk, arsenic). Almost as surprising as the eighth, is the ninth category. This one reveals to us that metals can be imperfect (cinnabar, mercury), artificial (bronze, brass), recremental (filings, rust) and natural (gold, tin, copper). Beauty belongs to the sixteenth category; it is a living brood fish, an oblong one. These ambiguities, redundancies and deficiencies remind us of those which doctor Franz Kuhn attributes to a certain Chinese encyclopaedia entitled 'Celestial Empire of Benevolent Knowledge'. In its remote pages it is written that the animals are divided into: (a) belonging to the emperor, (b) embalmed, (c) tame, (d) sucking pigs, (e) sirens, (f) fabulous, (g) stray dogs, (h) included in the present classification, (i) frenzied, (j) innumerable, (k) drawn with a very fine camelhair brush, (l) et cetera, (m) having just broken the water pitcher, (n) that from a long way off look like flies. http://www.alamut.com/subj/artiface/language/johnWilkins.html> Those who want the source material for the Celestial Emporium of Benevolent Knowledge are recommended to first read the Wikipedia article https://en.wikipedia.org/wiki/Celestial_Emporium_of_Benevolent_Knowledge>. A relevant 2003 work gives an illustration of a similar system http://collection.spencerart.ku.edu/eMuseumPlus?module=collection&objectId=42380>. -- \ “I'm not a bad guy! I work hard, and I love my kids. So why | `\ should I spend half my Sunday hearing about how I'm going to | _o__)Hell?” —Homer Simpson | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
in multiprocessing pool map how to stop one process from executing ahead
I am excecting custom commands like shell on multiple linux hosts. and if in one host one of the commands fail. I want that process not to proceed. If the remote command throws an error i am logging it .. but the process goes to next command . but if i terminate the command, the process will terminate all other processes on other linux machines as well. -- https://mail.python.org/mailman/listinfo/python-list
Re: Style Q: Instance variables defined outside of __init__
On Tuesday, March 20, 2018 at 1:10:19 PM UTC-4, Irv Kalb wrote: > I am aware of all the issues involved. My example code was an attempt to > demonstrate the clearest, simplest case possible. My question is not about > this small case. In classes designed for full games, I often have a "reset" > method that resets many instance variables (and potentially other display > fields and graphics) for a new round of playing a game. Grouping this into a > method called something like "reset" makes logical sense to me. You tell the > game object to reset itself, and it does whatever it needs to do to reset for > a new round. My __init__ method calls reset to initialize the first round of > the game. This ensures that every play of the game goes through the same > initialization. Calling reset() from __init__() and duplicating resetting logic during initialization aren't the only choices. My personal preference in such situations is to put all initialization code in __init__. Then write a separate factory function / method to create the new object for the next round. Optionally, this factory can be parametrized by the previous round object. Regards, Igor. -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Re: Style Q: Instance variables defined outside of __init__
On 2018-03-20, Tom Evans via Python-list wrote: > On Tue, Mar 20, 2018 at 5:25 PM, Grant Edwards > wrote: >> On 2018-03-20, Neil Cerutti wrote: >> >>> My automotive course will probaly divide cars into Automatic >>> Transmission, and Front Wheel Drive. >> >> I get your point: the two characteristics are, in theory, orthogonal. >> But, in the US, the two appear to be correlated. ISTM that cars with >> manual transmissions are much more likely to be RWD than are >> automatics. > > I find that slightly strange, I guess in the US, manual transmission > correlates to the non default option(?), along with RWD. In the US, manual transmissions are only offered on "sport" models/packges which tend to be sold to people who know/care more about cars that the average driver. Those models are also much more likely to be RWD because those people are much more likely to prefer the handling of RWD over that of FWD. > In Europe, RWD and automatic transmission are more expensive options > than FWD and manual transmissions, and most cars are FWD and manual. In the US, cars with manual transmission tend to be high priced because they are higher-performance, sports/enthusiast cars. They're either traditional US V8 muscle cars like Ford Mustangs and Dodge Callengers, or they're models trying to compete with BMW 3 and 5 series. They may be cheaper than similar performing cars with automatics (which are now often high-tech dual-clutch 8-speed mechanical wonders), but more expensive than the _average_ automatic transmission car. -- Grant Edwards grant.b.edwardsYow! I'm having a BIG BANG at THEORY!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Thank you Python community!
On Monday, March 19, 2018 at 9:28:09 AM UTC-7, Etienne Robillard wrote: > I would like to thank you guys sincerely for helping a lot of people to > stay clean, and focus on programming high-level stuff in Python instead > of doing some really nasty drugs. Yeah, it's either Python or that horrifying street drug PHP. I know which one I'm choosing. -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a C extension - borrowed references
On Tue, Mar 20, 2018 at 5:36 PM, Rob Gaddi wrote: > If all you're doing is a thin-wrapper around a C library, have you thought > about just using ctypes? Yep; the C library whose API I'm using uses macros to cast things to the right structure, and (similar to Cython), as I already _have_ the code, I wasn't particularly interested in working out how to convert things like: LASSO_SAMLP2_NAME_ID_POLICY(LASSO_SAMLP2_AUTHN_REQUEST( LASSO_PROFILE(login)->request)->NameIDPolicy )->Format = strdup(LASSO_SAML2_NAME_IDENTIFIER_FORMAT_PERSISTENT); into ctypes compatible syntax, when I can simply adapt the working C code to Python. :) Plus, there is the library static initialisation to manage, the issues of distributing the C libraries if I do a C wrapper to call from ctypes. This way, it can be distributed from our devpi very easily. Cheers Tom -- https://mail.python.org/mailman/listinfo/python-list
[OT] Re: Style Q: Instance variables defined outside of __init__
On Tue, Mar 20, 2018 at 5:25 PM, Grant Edwards wrote: > On 2018-03-20, Neil Cerutti wrote: > >> My automotive course will probaly divide cars into Automatic >> Transmission, and Front Wheel Drive. > > I get your point: the two characteristics are, in theory, orthogonal. > But, in the US, the two appear to be correlated. ISTM that cars with > manual transmissions are much more likely to be RWD than are > automatics. I find that slightly strange, I guess in the US, manual transmission correlates to the non default option(?), along with RWD. In Europe, RWD and automatic transmission are more expensive options than FWD and manual transmissions, and most cars are FWD and manual. At least most cars I can afford.. Cheers Tom -- https://mail.python.org/mailman/listinfo/python-list
Re: Style Q: Instance variables defined outside of __init__
On Wed, Mar 21, 2018 at 4:18 AM, Neil Cerutti wrote: > The Introduction to Computer Science class I'm taking divided > program design into two categories: Top Down Design, and Object > Oriented Design. It's good, because it reminded me of the wisdom > of dividing memory into Random Access and Read Only. > > My automotive course will probaly divide cars into Automatic > Transmission, and Front Wheel Drive. Game reviews on Steam can be rated as Helpful, Unhelpful, or Funny, thus giving a ternary division of similar quality. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a C extension - borrowed references
On 03/20/2018 10:03 AM, Tom Evans wrote: On Tue, Mar 20, 2018 at 4:38 PM, Chris Angelico wrote: BTW, have you looked into Cython? It's smart enough to take care of a lot of this sort of thing for you. I did a bit; this work is to replace our old python 2 SAML client, which used python-lasso and python-libxml2, both packages that are built as part of building the C library and thus an utter PITA to package for different versions of python (something our Infra team were extremely reluctant to do). When the latest (PITA to build) version of python-lasso started interfering with python-xmlsec (validating an invalid signature was causing segfaults), I got fed up of fighting it. I actually also maintain a C version of the same code, using the same libraries, so porting those few segments of code to Python/C seemed more expedient than rewriting in Cython. I'm not writing an API to these libraries, just a few functions. Cheers Tom If all you're doing is a thin-wrapper around a C library, have you thought about just using ctypes? -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: Style Q: Instance variables defined outside of __init__
On 2018-03-20, Neil Cerutti wrote: > My automotive course will probaly divide cars into Automatic > Transmission, and Front Wheel Drive. I get your point: the two characteristics are, in theory, orthogonal. But, in the US, the two appear to be correlated. ISTM that cars with manual transmissions are much more likely to be RWD than are automatics. -- Grant Edwards grant.b.edwardsYow! Inside, I'm already at SOBBING! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Style Q: Instance variables defined outside of __init__
On 2018-03-20, Rick Johnson wrote: > On Tuesday, March 20, 2018 at 6:14:34 AM UTC-5, Alister wrote: >> On Tue, 20 Mar 2018 08:52:29 +, Steven D'Aprano wrote: >> > On Tue, 20 Mar 2018 02:43:13 -0400, Terry Reedy wrote: >> > >> > > I think a claim that in all programs all attributes >> > > should be set *in* __init__, as opposed to *during* >> > > initialization, is wrong. All attribute setting is side- >> > > effect from a functional view (and usually 'bad' to a >> > > functionalist). There is no reason to not delegate some >> > > of it to sub-init functions when it makes sense to do do. >> > > There is good reason to do so when it makes the code >> > > easier to understand *and test*. >> > >> > That is really well said Terry, thank you for articulating >> > what I was thinking but couldn't find the words for. >> >> but why would a functional programmer be programming an OOP >> class? > > The question does indeed beg, but we're not allowed to > question mandates form "on high", we are simply required to > follow them. > > IOWs, "Do as they _say_, not as logic dictates" The Introduction to Computer Science class I'm taking divided program design into two categories: Top Down Design, and Object Oriented Design. It's good, because it reminded me of the wisdom of dividing memory into Random Access and Read Only. My automotive course will probaly divide cars into Automatic Transmission, and Front Wheel Drive. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a C extension - borrowed references
On Tue, Mar 20, 2018 at 04:33:15PM +, Paul Moore wrote: > Or, to put it another way, "if you need to ask, you can't afford to". If you don't know, you need to ask so that you can learn whether or not you can afford to. :( -- https://mail.python.org/mailman/listinfo/python-list
Re: Style Q: Instance variables defined outside of __init__
> On Mar 19, 2018, at 10:27 AM, Ned Batchelder wrote: > > On 3/19/18 1:04 PM, Irv Kalb wrote: >> I am building some classes for use in future curriculum. I am using PyCharm >> for my development. On the right hand edge of the PyCharm editor window, >> you get some little bars indicating warnings or errors in your code. I like >> this feature and try to clean up as many of those as I can. However, there >> is one warning that I am seeing often, and I'm not sure about how to handle >> it. The warning I see is: >> >> "Instance attribute defined outside of __init__ ..." >> >> > > I understand this tension: it's nice to assign only meaningful values, and to > do it in as few places as possible. But it's also nice to have all of your > attributes in one place. This is a by-product of Python having no > declarations, only definitions (assignments). So to mention the attributes > initially, you have to choose a value for them. If I were to add faceUp to > __init__, I would assign False to it. >> Thanks to everyone who responded to my question - good discussion. Special thanks to Ned who accurately described the "tension" that I am trying to resolve. I am aware of all the issues involved. My example code was an attempt to demonstrate the clearest, simplest case possible. My question is not about this small case. In classes designed for full games, I often have a "reset" method that resets many instance variables (and potentially other display fields and graphics) for a new round of playing a game. Grouping this into a method called something like "reset" makes logical sense to me. You tell the game object to reset itself, and it does whatever it needs to do to reset for a new round. My __init__ method calls reset to initialize the first round of the game. This ensures that every play of the game goes through the same initialization. With the approach suggested (initializing instance variables in my __init__ and in method like reset), I would wind up duplicating all such code. I know myself, and I am worried that this has the potential for introducing an error in my coding (specifically, add an initialization of an instance variable in my __init__ but then forget to add the same line in my "reset" method). So the tension that I am feeling is in the trade off of the "Don't Repeat Yourself" (DRY) rule vs the nicety of defining all instance variables in the __init__ method, and with that a resolution to the lint warnings. After further thought (and considering by the discussion here), I think that the DRY rule outweighs the other. I will keep my separate initialization methods, and call them at the end of my __init__ methods. Again, the real reason I'm asking for the "best practices" (even though I hate that term), is because I want to explain this concept to students who will be learning the basics of OOP. Thanks, Irv -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a C extension - borrowed references
On Tue, Mar 20, 2018 at 4:38 PM, Chris Angelico wrote: > BTW, have you looked into Cython? It's smart enough to take care of a > lot of this sort of thing for you. I did a bit; this work is to replace our old python 2 SAML client, which used python-lasso and python-libxml2, both packages that are built as part of building the C library and thus an utter PITA to package for different versions of python (something our Infra team were extremely reluctant to do). When the latest (PITA to build) version of python-lasso started interfering with python-xmlsec (validating an invalid signature was causing segfaults), I got fed up of fighting it. I actually also maintain a C version of the same code, using the same libraries, so porting those few segments of code to Python/C seemed more expedient than rewriting in Cython. I'm not writing an API to these libraries, just a few functions. Cheers Tom -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Re: Thank you Python community!
On 3/20/18 12:08 PM, Rick Johnson wrote: On Tuesday, March 20, 2018 at 7:03:11 AM UTC-5, Adriaan Renting wrote: (on the subject of the opioid epidemic) The [OT] in the subject line is right: let's not get off on a political tangent. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a C extension - borrowed references
On Wed, Mar 21, 2018 at 3:22 AM, Tom Evans via Python-list wrote: > Hi all > > I'm writing my first C extension for Python here, and all is going > well. However, I was reading [1], and the author there is advocating > Py_INCREF 'ing *every* borrowed reference. BTW, have you looked into Cython? It's smart enough to take care of a lot of this sort of thing for you. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a C extension - borrowed references
On Wed, Mar 21, 2018 at 3:22 AM, Tom Evans via Python-list wrote: > Hi all > > I'm writing my first C extension for Python here, and all is going > well. However, I was reading [1], and the author there is advocating > Py_INCREF 'ing *every* borrowed reference. > > Now, I get that if I do something to mutate and perhaps invalidate the > PyObject that was borrowed I can get unpredictable results - eg, by > getting a borrowed reference to a value from a dictionary, clearing > the dictionary and then expecting to use the borrowed reference. > > However, if my code does not do things like that, is there a chance of > a borrowed reference being invalidated that is not related to my use > of the thing I borrowed it from? Is this cargo cult advice (sometimes > the gods need this structure, and so to please the gods it must be > everywhere), sensible belt and braces or needless overkill? Yep, that's cargo cult advice. If it were good advice, the Python API would have been built to never return borrowed references, so you always have to decref everything. You should incref those sorts of borrowed references if you're going to do something that could call arbitrary Python code and then continue using the reference; but most of the time, that borrowed ref is going to be used immediately and then finished with, and in those very common situations, it's pointless to incref and decref. It's also perfectly safe to use borrowed refs with immutable objects that you have refs to; for instance, you can inspect the elements of a tuple that way. The tuple MUST be holding references to all its members, and the tuple itself can't be disposed of while you have a reference to it, so you have a guarantee that those borrowed refs are valid. """The analogy in C is having two pointers to the same memory location: so who is responsible for freeing the memory and what happens if the other pointer tries to access that free’d memory?""" That ignores the entire point of reference counting. By using a borrowed reference, you're clearly declaring that the OTHER guy is responsible for freeing it. From footnote 3: """Of course we never remove items in a list we merely decrement their reference count (and if that hits zero then they are deleted).""" This is conflating two separate concepts. You most assuredly CAN remove items from a list, and the code in the footnote does exactly that. What it won't necessarily do is destroy those objects. """An important takeaway here is that incrementing and decrementing reference counts is a cheap operation but the consequences of getting it wrong can be expensive. A precautionary approach in your code might be to always increment borrowed references when they are instantiated and then always decrement them before they go out of scope. That way you incur two cheap operations but eliminate a vastly more expensive one.""" Actually, managing ref counts isn't always cheap. So instead of just always incrementing and always decrementing, how about this: If you are going to call arbitrary code that could do anything at all, guard around THAT CODE and nothing else, by protecting any borrowed references. People talk a lot about calling functions that could do literally anything, but honestly, how often does that even happen? Not often enough to justify cargo cult advice. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a C extension - borrowed references
On 20 March 2018 at 16:22, Tom Evans via Python-list wrote: > Hi all > > I'm writing my first C extension for Python here, and all is going > well. However, I was reading [1], and the author there is advocating > Py_INCREF 'ing *every* borrowed reference. > > Now, I get that if I do something to mutate and perhaps invalidate the > PyObject that was borrowed I can get unpredictable results - eg, by > getting a borrowed reference to a value from a dictionary, clearing > the dictionary and then expecting to use the borrowed reference. > > However, if my code does not do things like that, is there a chance of > a borrowed reference being invalidated that is not related to my use > of the thing I borrowed it from? Is this cargo cult advice (sometimes > the gods need this structure, and so to please the gods it must be > everywhere), sensible belt and braces or needless overkill? You *can* safely use a borrowed reference, but knowing when it's safe to do so is definitely not easy. For example, in the presence of threads, your borrowed reference could be invalidated on another thread, so you have to be careful how the GIL is managed. It's often very difficult to be sure that code doesn't call back into arbitrary Python code, and you need to take care of that if you want to use the borrowed reference. Conversely, the benefit of not doing an INCREF is generally a pretty tiny performance improvement, which is only worthwhile if you're in an extremely tight loop. So while it's OK to use a borrowed reference, the reality is that if you don't fully understand why you want to, and all the trade-offs, it's probably not worth the risk. Or, to put it another way, "if you need to ask, you can't afford to". Paul -- https://mail.python.org/mailman/listinfo/python-list
Writing a C extension - borrowed references
Hi all I'm writing my first C extension for Python here, and all is going well. However, I was reading [1], and the author there is advocating Py_INCREF 'ing *every* borrowed reference. Now, I get that if I do something to mutate and perhaps invalidate the PyObject that was borrowed I can get unpredictable results - eg, by getting a borrowed reference to a value from a dictionary, clearing the dictionary and then expecting to use the borrowed reference. However, if my code does not do things like that, is there a chance of a borrowed reference being invalidated that is not related to my use of the thing I borrowed it from? Is this cargo cult advice (sometimes the gods need this structure, and so to please the gods it must be everywhere), sensible belt and braces or needless overkill? Cheers Tom [1] http://pythonextensionpatterns.readthedocs.io/en/latest/refcount.html#borrowed-references -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Re: Thank you Python community!
On Tuesday, March 20, 2018 at 7:03:11 AM UTC-5, Adriaan Renting wrote: (on the subject of the opioid epidemic) > That sounds more like a conspiracy theory than a real > analysis of the problem. Looking at it from here in > Europe, most of the analysis I've been able to read and > watch about it, points to a different cause: A lack of > security: People flee to drugs (alcohol, tobacco, coffee > and other (illegal) drugs) to escape st[r]essful > environments. Personally, I drink coffee simply so i can function in the morning. If i'm feeling anything, it's unconsciousness. As far as drugs, alcohol and tobacco are concerned; those days are long behind me. > - A lack of job security > - A lack of proper healthcare > - Broken and single parent families > - Poor and/or expensive education > - Mental illness And don't forget boredom! ;-) > What I learned from visiting the USA many times is: - > Americans value the individual, not the collective. Yes. Individualism is a natural part of rejecting your birth county; packing up your belonging; sailing across an ocean; and starting over from scratch. To the "true americans" (not the fake ones who come here looking for handouts) there is nothing more important than freedom. A true american would never sacrifice freedom for security. A true american spits in the face of so-called security, because they know it's a bald faced lie, as there is no such thing as "security" in such a hostile universe as our. "Security" is simply snake oil sold to ignoramuses. It plays on the emotions of infantile humans. > They have been trained to distrust anything collective, True americans are born in every country of the world. They come from all walks of life and every ethnic and racial background. But of all their differences, they share a common respect for individual liberty. And that's why most outsiders cannot understand how america could possibly become so strong in a paltry few hundered years and survive for as long as she has. > even if it is the only way to solve an issue. - Money has > too much influence at all levels, especially in politics. Money has been ruining politics for thousands of years... where have your been? > The combination of an election system that is 2 centuries > behind the times, with modern compute power, data gathering > and media technology is corrupting the system. The media is to blame for much of the ills of modern society, bathing our subconscious in gratuitous violence, and stoking our emotions over the most frivolous and petty differences between us. > - The USA always depended a lot on immigration and never > had to keep it's own working population well educated and > healthy to run the economy. This is changing and one of the > big cultural wars raging currently. Again, another failure of government who is in bed with greedy corporation. Nationalism is feared and branded as pure evil these days due to one most atrocious usage of it in recent history, but nationalism (the non-religios kind!) may be the _only_ force that has prevented thermo nuclear war up to this point. Even that murderous jerk Stalin would not have wanted to witness his beloved USSR smoulder to ashes. But with the rabid stigmatization of nationalism these days, we are entering a time in which the masses no longer care about their fellow country(wo)men. And in a world of Mutually Assured Destruction, a lack of social comradery leads to national suicide. And in this universe, there is no choice or action that is devoid of consequence. All forces possess varying degrees applicability. > The broken healthcare system is a symptom of these issues. "Broken healthcare" is a buzz word that animates emotional weaklings. The state of health care has absolutely nothing to do with the social turmoil that plagues us. "Healthcare" is only a recent phenomenon. Hardly a few hundred years ago doctors were few and far between. And to believe that "fixing the healthcare system" (whatever that means!) will suddenly usher in an "epoch of Universal Utopianism", is the bone-headed height of naivete. Don't be a fool. Healthcare has nothing to do with our overall happiness, it is merely another divisive tool utilized by the manipulators to animate the selfish and jealous idiots into a mad frenzy. An in such a discombobulated emotional state, humans are more willing to sacrifice freedom for paltry priviledge. Rights cannot be taken away. Whereas priviledge _can_. > There are other reasons people get into drugs*, but from > what I've read, my impression is that these are major > causes to the current problems in the USA. BRAVO! YES! THAT'S RIGHT! Blame all the world's problems on america. At least that way, you won't have to actually _think_! @_@ > Successive US governments have been waging unwinnable > "wars", like the "War on Drugs" for decades, so entire > industries can keep profiting. Until you fix the problems > in society the demand will not go away and the problems >
Re: [OT] Re: Thank you Python community!
On Tue, Mar 20, 2018 at 6:19 AM, Adriaan Renting wrote: > > That sounds more like a conspiracy theory than a real analysis of the > problem. Follow the money. > > > Looking at it from here in Europe, most of the analysis I've been able to > read and watch about it, points to a different cause: > > > A lack of security: People flee to drugs (alcohol, tobacco, coffee and other > (illegal) drugs) to escape stessful environments. > > > - A lack of job security > > - A lack of proper healthcare > > - Broken and single parent families > > - Poor and/or expensive education > > - Mental illness > > > What I learned from visiting the USA many times is: > > - Americans value the individual, not the collective. They have been trained > to distrust anything collective, even if it is the only way to solve an > issue. > > - Money has too much influence at all levels, especially in politics. The > combination of an election system that is 2 centuries behind the times, with > modern compute power, data gathering and media technology is corrupting the > system. > > - The USA always depended a lot on immigration and never had to keep it's > own working population well educated and healthy to run the economy. This is > changing and one of the big cultural wars raging currently. > > > The broken healthcare system is a symptom of these issues. > > > There are other reasons people get into drugs*, but from what I've read, my > impression is that these are major causes to the current problems in the > USA. > > > Successive US governments have been waging unwinnable "wars", like the "War > on Drugs" for decades, so entire industries can keep profiting. Until you > fix the problems in society the demand will not go away and the problems > will stay. > > > Cheers. > > > *) Drug use also correlates with boredom and low amounts of sunlight and an > amount of predisposition. Correlation is not always causation, but can be. > > Larry Martell 19-3-2018 20:21 >>> > On Mon, Mar 19, 2018 at 12:08 PM, Etienne Robillard > wrote: >> You guys just made me realize something very obvious. :-) >> >> I'm in the process right now of watching the excellent documentary named >> "Drugs Inc." on Netflix and I'm basically stunned and deeply concerned >> about >> the major opioid epidemic in the US. > > Have no clue what this has to do with python, but the opioid epidemic > was created by collision between big pharma and the government. -- https://mail.python.org/mailman/listinfo/python-list
Re: Style Q: Instance variables defined outside of __init__
On Wed, Mar 21, 2018 at 2:15 AM, Steven D'Aprano wrote: > On Tue, 20 Mar 2018 11:14:13 +, Alister via Python-list wrote: > >> but why would a functional programmer be programming an OOP class? > > I read a really good blog post a while back, which I sadly can no longer > find (I had it bookmarked until Firefox ate my bookmarks) that discussed > exactly that question. > > What they came up with is that its really hard to do useful work for > large applications with 100% pure functional programming styles. As you > add functional techniques to your code, you find your code quality > increasing. Things like pure functions with no hidden state and no side > effects can have a massive positive effect on code quality -- up to a > point. > > As you approach closer and closer to 100% pure functional code, you get > fewer improvements and your code gets harder to write and maintain. > > He maintains that the sweet spot is about 80% functional, and 20% OOP. Yep, I remember that article. Sadly, I can't find it back now either; maybe someone can craft a regular expression to find it? https://xkcd.com/208/ This week I dived into the source code for an application that's built out of 20 Python files in four package directories plus a top-level "app.py" as its entry point. You'd think that that means I can write my own Python script that imports from those packages and calls on the same code, right? Sadly, no; because this app is 100% OOP and 0% functional. (Not to be confused with a *non-functioning* app; it functions perfectly well. It just doesn't follow *functional programming* idioms.) Deep inside the imported modules, a class's __init__ will check command-line arguments to control its behaviour, and in the event of a problem (eg JSON data lacking vital information), will print a failure message and exit the program. Were this class written in a pure functional style, it would use the construction parameters, and raise an exception if something's wrong. It's entirely possible for a class to follow functional programming style, at least partly. (In theory, it should be possible to use a class in a 100% functional style. A class is just a callable function that then happens to return a thing of a type that has the same name as the thing you called, so there's no reason the two styles can't completely overlap.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: how do I retry a command only for a specific exception / error
On Mon, 19 Mar 2018 22:08:09 +0530, Ganesh Pal wrote: I'm sorry Ganesh, you have appeared to have just quoted my post without writing anything new. (I haven't taken the time to read your post in fine detail.) Apart from "Regards, Ganesh" at the very end, everything is quoted text (starting with a > sign). Please ensure quoted text is quoted, and new text you write is unquoted. That way you are more likely to get useful replies. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Style Q: Instance variables defined outside of __init__
On Tue, 20 Mar 2018 11:14:13 +, Alister via Python-list wrote: > but why would a functional programmer be programming an OOP class? I read a really good blog post a while back, which I sadly can no longer find (I had it bookmarked until Firefox ate my bookmarks) that discussed exactly that question. What they came up with is that its really hard to do useful work for large applications with 100% pure functional programming styles. As you add functional techniques to your code, you find your code quality increasing. Things like pure functions with no hidden state and no side effects can have a massive positive effect on code quality -- up to a point. As you approach closer and closer to 100% pure functional code, you get fewer improvements and your code gets harder to write and maintain. (Think about things like dealing with user preferences, and having to pass them around from function to function. Think about functions that don't need a parameter themselves, but need to call a function that does. Think about data processing without any mutable data structures. Sometimes a modicum of state is exactly what we need.) He maintains that the sweet spot is about 80% functional, and 20% OOP. That seems to be about right to me: write classes with just the bare minimum state you need, and have your methods work using a nearly-pure functional style: they should take arguments, they should return results, they should rarely operate by side-effects, etc. Most of Python's design is like that. Apart from a few mutable data structures, Python's built-ins tend to be immutable. We don't do things like: finder = SubstringFinder(start=1, end=55) finder.set_string(string_to_search) finder.set_target(substring) position = finder.find() rather we use the semi-functional style: position = string_to_search.find(substring, start=1, end=55) Don't be fooled by the dot method call syntax: that's exactly equivalent to the purely functional style find(string_to_search, substring, start=1, end=55) -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Style Q: Instance variables defined outside of __init__
On Tuesday, March 20, 2018 at 1:43:39 AM UTC-5, Terry Reedy wrote:
[...]
> > class Card():
> >
> > BACK_OF_CARD_IMAGE = pygame.image.load('images/backOfCard.png')
> >
> > def __init__(self, window, name, suit, value):
> > self.window = window
> > self.suit = suit
> > self.cardName = name + ' of ' + suit
> > self.value = value
> > fileName = 'images/' + self.cardName + '.png'
> > self.image = pygame.image.load(fileName)
> > self.backOfCardImage = Card.BACK_OF_CARD_IMAGE
> >
> > self.conceal()
> >
> > def conceal(self):
> > self.faceUp = False
> >
> > def reveal(self):
> > self.faceUp = True
>
> If the single line is all these functions do, I *might*
> suggest getting rid of them. But this is really a separate
> issue.
While i normally agree with your advice Terry, in this case,
i must protest as i am a firm believer that callers should
_never_ be fiddling with the internals of an object unless
doing so is the only available option -- and such cases of
last resort indicate a code-smell.
Whether the practice is considered Pythonic or not (i don't
care), i would strongly suggest to the OP and anyone within
ear shot, that clear interfaces must be _strictly_ utilized.
Sure, in this case a named function may be overkill,
however, even in the superfluous cases, not providing an
interface encourage callers to engage in sloppy behavior and
reinforces sloppy behavior in authors. And both parties will
be doomed to maintenance nightmares when `reveal` and/or
`conceal` grow more functional behavior.
Laziness is not always a bad thing -- i mean, let's face it
folks, python is designed to be a lazy language -- but
experience has proven that when an author refuses to provide
clear interfaces to his/her objects, the author and the
caller will both pay a heavy price in the future.
IOWs, laziness should never be allowed to wax into an
orthodoxy.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Style Q: Instance variables defined outside of __init__
On Tuesday, March 20, 2018 at 6:14:34 AM UTC-5, Alister wrote: > On Tue, 20 Mar 2018 08:52:29 +, Steven D'Aprano wrote: > > On Tue, 20 Mar 2018 02:43:13 -0400, Terry Reedy wrote: > > > > > I think a claim that in all programs all attributes > > > should be set *in* __init__, as opposed to *during* > > > initialization, is wrong. All attribute setting is side- > > > effect from a functional view (and usually 'bad' to a > > > functionalist). There is no reason to not delegate some > > > of it to sub-init functions when it makes sense to do do. > > > There is good reason to do so when it makes the code > > > easier to understand *and test*. > > > > That is really well said Terry, thank you for articulating > > what I was thinking but couldn't find the words for. > > but why would a functional programmer be programming an OOP > class? The question does indeed beg, but we're not allowed to question mandates form "on high", we are simply required to follow them. IOWs, "Do as they _say_, not as logic dictates" -- https://mail.python.org/mailman/listinfo/python-list
Re: curious asymmetry in range limiting
On 03/20/2018 03:21 PM, Robin Becker wrote: I don't know how I never came across this before, but there's a curious asymmetry in the way ranges are limited Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> s = '0123456789' >>> print(repr(s[-5:5])) '' >>> print(repr(s[5:15])) '56789' >>> why is the underflow start index treated so differently from the limit index overflow? I suppose there must be some reason, but it eludes me. It's because in the slice [-5:5] the -5 is not trying to access an element at an index < 0, but indicating the fifth-last element in the sequence. -- https://mail.python.org/mailman/listinfo/python-list
Re: curious asymmetry in range limiting
So eventually I tried this C:\code\hg-repos\reportlab>\python36\python -c"s='0123456789';print(repr(s[-5:15]))" '56789' C:\code\hg-repos\reportlab>\python36\python -c"s='0123456789';print(repr(s[-6:15]))" '456789' and the light dawned :) seems the negative indexes rules apply to both On 20/03/2018 14:21, Robin Becker wrote: I don't know how I never came across this before, but there's a curious asymmetry in the way ranges are limited Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> s = '0123456789' >>> print(repr(s[-5:5])) '' >>> print(repr(s[5:15])) '56789' >>> why is the underflow start index treated so differently from the limit index overflow? I suppose there must be some reason, but it eludes me. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
curious asymmetry in range limiting
I don't know how I never came across this before, but there's a curious asymmetry in the way ranges are limited Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> s = '0123456789' >>> print(repr(s[-5:5])) '' >>> print(repr(s[5:15])) '56789' >>> why is the underflow start index treated so differently from the limit index overflow? I suppose there must be some reason, but it eludes me. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: Style Q: Instance variables defined outside of __init__
On 2018-03-20, Alister via Python-list wrote: > but why would a functional programmer be programming an OOP class? Part of a 12-step recovery plan? ;) -- Grant Edwards grant.b.edwardsYow! Hello. I know at the divorce rate among gmail.comunmarried Catholic Alaskan females!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Thank you Python community!
Le 2018-03-19 à 22:21, Rick Johnson a écrit : On Monday, March 19, 2018 at 6:37:21 PM UTC-5, Ben Finney wrote: -- \ "Success is going from one failure to the next without a loss | `\ of enthusiasm." -- Winston Churchill | _o__) | Ben Finney -- \ “Experience is that marvelous thing that enables you to | `\ recognize a mistake when you make it again.” —Franklin P. Jones | _o__) | Ben Finney Okay Ben, i believe it's time to come clean and finally admit to this fine community, that these quotes of yours are not merely chosen at random, but are in fact, delectable morsels of laser-focused sarcasm. Here's another one I have in mind theses days: "The only thing necessary for the triumph of evil is for good men to do nothing." -Edmund Burke Etienne -- Etienne Robillard tkad...@yandex.com https://www.isotoperesearch.ca/ -- https://mail.python.org/mailman/listinfo/python-list
[OT] Re: Thank you Python community!
That sounds more like a conspiracy theory than a real analysis of the problem. Looking at it from here in Europe, most of the analysis I've been able to read and watch about it, points to a different cause: A lack of security: People flee to drugs (alcohol, tobacco, coffee and other (illegal) drugs) to escape stessful environments. - A lack of job security - A lack of proper healthcare - Broken and single parent families - Poor and/or expensive education - Mental illness What I learned from visiting the USA many times is: - Americans value the individual, not the collective. They have been trained to distrust anything collective, even if it is the only way to solve an issue. - Money has too much influence at all levels, especially in politics. The combination of an election system that is 2 centuries behind the times, with modern compute power, data gathering and media technology is corrupting the system. - The USA always depended a lot on immigration and never had to keep it's own working population well educated and healthy to run the economy. This is changing and one of the big cultural wars raging currently. The broken healthcare system is a symptom of these issues. There are other reasons people get into drugs*, but from what I've read, my impression is that these are major causes to the current problems in the USA. Successive US governments have been waging unwinnable "wars", like the "War on Drugs" for decades, so entire industries can keep profiting. Until you fix the problems in society the demand will not go away and the problems will stay. Cheers. *) Drug use also correlates with boredom and low amounts of sunlight and an amount of predisposition. Correlation is not always causation, but can be. >>> Larry Martell 19-3-2018 20:21 >>> On Mon, Mar 19, 2018 at 12:08 PM, Etienne Robillard wrote: > You guys just made me realize something very obvious. :-) > > I'm in the process right now of watching the excellent documentary named > "Drugs Inc." on Netflix and I'm basically stunned and deeply concerned about > the major opioid epidemic in the US. Have no clue what this has to do with python, but the opioid epidemic was created by collision between big pharma and the government. -- https://mail.python.org/mailman/listinfo/python-list Adriaan Renting| Email: rent...@astron.nl Software Engineer Radio Observatory ASTRON | Phone: +31 521 595 100 (797 direct) P.O. Box 2 | GSM: +31 6 24 25 17 28 NL-7990 AA Dwingeloo | FAX: +31 521 595 101 The Netherlands| Web: http://www.astron.nl/~renting/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Thank you Python community!
On Mon, 19 Mar 2018 19:21:04 -0700, Rick Johnson wrote: > On Monday, March 19, 2018 at 6:37:21 PM UTC-5, Ben Finney wrote: > >> -- >> \ "Success is going from one failure to the next without a loss >> | >> `\ of enthusiasm." -- Winston Churchill >> | >> _o__) >> | >> Ben Finney > > >> -- >> \ “Experience is that marvelous thing that enables you to >> | >> `\ recognize a mistake when you make it again.” —Franklin P. Jones >> | >> _o__) >> | >> Ben Finney > > Okay Ben, i believe it's time to come clean and finally admit to this > fine community, that these quotes of yours are not merely chosen at > random, but are in fact, delectable morsels of laser-focused sarcasm. maybe not - I use fortune to generate mine & it can be supprisingly apt at times -- The primary function of the design engineer is to make things difficult for the fabricator and impossible for the serviceman. -- https://mail.python.org/mailman/listinfo/python-list
Re: Style Q: Instance variables defined outside of __init__
On Tue, 20 Mar 2018 08:52:29 +, Steven D'Aprano wrote: > On Tue, 20 Mar 2018 02:43:13 -0400, Terry Reedy wrote: > >> I think a claim that in all programs all attributes should be set *in* >> __init__, as opposed to *during* initialization, is wrong. All >> attribute setting is side-effect from a functional view (and usually >> 'bad' to a functionalist). There is no reason to not delegate some of >> it to sub-init functions when it makes sense to do do. There is good >> reason to do so when it makes the code easier to understand *and test*. > > That is really well said Terry, thank you for articulating what I was > thinking but couldn't find the words for. but why would a functional programmer be programming an OOP class? -- No one becomes depraved in a moment. -- Decimus Junius Juvenalis -- https://mail.python.org/mailman/listinfo/python-list
Re: Style Q: Instance variables defined outside of __init__
On Tue, 20 Mar 2018 02:43:13 -0400, Terry Reedy wrote: > I think a claim that in all programs all attributes should be set *in* > __init__, as opposed to *during* initialization, is wrong. All > attribute setting is side-effect from a functional view (and usually > 'bad' to a functionalist). There is no reason to not delegate some of > it to sub-init functions when it makes sense to do do. There is good > reason to do so when it makes the code easier to understand *and test*. That is really well said Terry, thank you for articulating what I was thinking but couldn't find the words for. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: how to obtain the text for BeautifulSoup object
Nathan Zhu wrote:
> Hi Team,
>
> could anyone help me?
>
> for webpage having source code like this:
> ...
>
> number
> name
>
>
> I only can use below sentence, since there are a lot of tag em and tag a
> in other area.
> output =
> bs4.BeautifulSoup(res.content,'lxml').findAll("span",{"class":"xst
> thread-name"})
>
> how can I get the text in tag em and tag a under tag span?
for thread in output:
print("em:", thread.em.text)
print("a:", thread.a.text)
print()
--
https://mail.python.org/mailman/listinfo/python-list
