Project Aon has all the Lone Wolf books in a variety of formats, including a machine readable format, which they have used to produce similar diagrams of the books' structures. Joe Dever have them permission to distribute the books for free some years ago (you can also now buy them as ebooks, I think). They're all at https://www.projectaon.org/
TBH, I think the main difficulty is caused by people claiming there's some huge difference between prototype based and class based OO. There isn't, really (at least, not if you're comparing JavaScript and other widely used dynamic OO languages; prototype-based languages which emphasise copying, rather than delegation, are a bit more different).
In both cases, you can share behaviour between objects by putting that behaviour in another object and attaching it in a special way to the objects that should have similar behaviour - in JavaScript it's called __proto__, in Python it's called __class__, etc. Python (and Ruby, Smalltalk, and others) introduce an additional "meta" level of shared behaviour between all these class objects, whereas JavaScript (and Self) don't, but that's a comparatively technical implementation detail. Most languages other than JavaScript are include slightly more language-level support for one particular pattern of using this shared behaviour, which gives users of these languages a strong hint as to how to use these capabilities.
The addition of a class keyword to JavaScript is good because it emphasises what JavaScript shares with other dynamic OO languages.
Exactly. I don't get what secret superpowers I'm supposed to be gaining by using prototype OO over classes. One of them is just more familiar to the vast majority of programmers.
"The second blank ""is the empty space where the field value goes."
I'm not sure I understand what you're saying here, but I don't think this is right. cleaned_data is a dictionary, and so the second argument to get is a default value to use if there is no value corresponding to the key. So, in your example, if there's no value for "formfield1" in cleaned_data, it would return a string with a space in.
This is probably not what you want to do. cleaned_data will always contain values for declared form fields, so the only way the default would be used is if you've made a mistake in specifying the key (for instance, if there's a typo and you've written 'formfeild1' instead of 'formfield1'). If you've made that kind of mistake, you don't want the program to continue using a single space instead of the valid data (you'll lose data) - you want the program to report that there's something wrong.
So I think you should probably use
form.cleaned_data['formfield1']
which will do the same thing if formfield1 is a real field name specified in the form, but will raise an exception if it isn't.
Sorry typo, it should be the second blank is the empty space where the user input goes.
I just tried your solution with cleaned_data["formfield1"] instead of cleaned_data("formfield1","") and it didn't work for me, it came back with the following error message when I submitted the form:
>'builtin_function_or_method' object is not subscriptable
I think you have to have the empty quotes after the form field and I think that's what's capturing the user input
so here "form.cleaned_data("formfield1","") seems to be telling django the form name and then the second field is where the associated user input goes which is then passed to the model.
"You know, I studied 3 separate modules on formal logic.... I learnt more about logic from a single 1 hour high school electronics lesson than I ever did from all that."
Can you say more about that? I can't make any sense of it. In a 1 hour electronics lesson, you'ld presumably cover the gates, i.e., propositional calculus. In a first logic module, you'ld learn that and another, richer, form of logic, the predicate calculus. You'ld also learn about the proof procedures for both, which ought to lead on to learning the (to my mind, interesting and important) fact that there's a mechanical procedure that's guaranteed to prove or disprove any argument in propositional calculus, but there's no such procedure for predicate calculus. Later logic courses would probably include some formal semantics, so you'ld learn about the (again, to my mind significant) distinction between what makes something true, and how we prove that something is true. Did you learn all these things in your one hour high school electronics lesson? Or are they somehow not "meaningful" or "complicated"?
"Python has an "invisible close brace" character, the newline, which closes a varying number of braces"
The idea that the end of a block is invisible isn't really right, though. The newline doesn't end the block. The block ends at the next line containing non-whitespace text at a lower indentation level. In other words, it only ends when it becomes visible that it has ended.
RSS 2.0 does actually allow HTTPS URLs[1]. The author of the blog post appears to be misreading a StackOverflow comment which is specifically about <enclosure> elements, which are the only URLs that the RSS spec restricts to HTTP.
Protocol-less URLs are usually a bad idea. They mean "use http or https depending on whatever the current page is", but there are very few situations where that is a useful way of making that decision. What you should do is specify https in the link, unless you know that the target site doesn't support https, in which case of course you have to specify http.
If the model is being updated based on results as they come in, and the results coming in are not randomly distributed, then the updates will be of questionable value. In particular, this update came when a large number of predicted pro-leave results had come in, and no results from predicted strong pro-remain results had come in, so I'm not sure it has much value as a prediction.
Interesting he's since increased the certainty of a Leave vote even after a couple of unexpectedly strong pro-Remain votes swung the betting markets back in favour of Remain
Whether that's because he's better than the markets at modelling differential turnout or the markets know things his confirmed results data doesn't about predicted results in places like Birmingham remains to be seen...
As I understand it, the model is based on the difference between expected and actual results in each area. So the order that results come in should not affect the prediction.
> So the order that results come in should not affect the prediction.
This model uses a frequentist prediction interval, which assumes independently drawn samples, meaning reporting order must be random for the assumptions to be valid. If reporting is non-random, e.g. how early or late a district reports is correlated with things like region, demographics, population density, etc., then the prediction interval is probably narrower than it should be, especially early on in the reporting (meaning the model is overconfident in its prediction).
The headline prediction is more robust if you just want to know which outcome is more likely given current results, but the probabilities being badly calibrated due to these kinds of model assumptions is a common issue in quantitative polisci models.
Pointer arithmetic isn't "something that I will surely never want to do"; it's something you want to do all the time in C (and therefore in C++ written in a more C-like style). Illegitimate uses of pointer arithmetic, such as your example, are only easy to detect in trivial cases like yours. I assume this is why no one has bothered implementing a warning for this special case.
In C++, directly using pointers to access arrays is often discouraged, in favour of using the standard collection types and their associated iterator types. So in code that follows this style, it is possible to warn about uses of pointer arithmetic, and the core C++ guidelines do suggest such a warning. But the guidelines also point out that "this rule would generate a huge number of false positives if applied to an older code base": https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
I used pyjs (pyjamas) for some personal projects and I liked it a lot. Unfortunately it got stuck in time, and in 2012 the current maintainers did a bad political move, and left the project in even worse shape than it was.
Nowadays, I wouldn't consider pyjs to build anything relevant..
