OP didn't specify what the variable value they were trying to increase was, because there was no variable arithmetic in their first post.
And what you expect them to be ? Strings ?
People should think a bit before they implement this shitty scripting language into their programs, because it's really tiring to use it.
Yet, due to it's simplicity, and it being largely fool proof, while relatively obvious and easily readable by a human, it's one of the main language taught in universities' computer courses all around the world.
I don't like this language, it goes against all the freedom, and habits, I acquired during decades of use of C and (my beloved) Perl. But this doesn't prevent me to recognize that, despite its rigidity, and the oddity of it's immutability and duck typing approach, it's a language easy to learn and to use.
It's a language as easy as lua, while being more powerful than it. Therefore it's the perfect choice when you need an embedded script language that will possibly be used by total novices ; this even when, in the case of Ren'Py, "embedded" is misused.
So basically all variable names are keys in a dictionary (the store, presumably), [...]
What the fucking fuck is "the store" ?
Hint: you're talking about Python here...
So why does Python pride itself on "There's only one way to do it", [...]
OMFG... There's still peoples stuck with this now 22 years old promotional geek joke ?
Before using it as argument to justify your hate of Python, you should have took few times to search what hide behind those few words. Just to be sure that there's at least a bit of truth behind the meaning you give them.
TL;DR: There isn't a single bit of truth, you totally misunderstood what it was intended for and what it mean.
No, Python do not pride itself with this. As I said, it was a promotional geek joke, that happened during the
You must be registered to see the links
2000.
At this time, Perl was at its top. It was the most used script language, present by default in all Linux distributions and *nix OSes, even being use by the core of the said distribution and OSes. This while Python was still at its prime, and rarely used. Due to its oddity, it was too often seen as marginal, and, worse for geeks, it was heretic ; it was the first language intended to be mainstream that killed the father and abandoned the C syntax (
{
and
}
to marks the blocks,
;
to end a line, and few others idioms).
At the OSCON 2000, the Python team decided to distribute shirts with printed on them a sentence that was the exact opposite of Perl's motto ("
You must be registered to see the links
"). What was their effective thoughts behind this, only them know. But it's difficult to imagine that they weren't aware that, by distributing those shirts to pure computer geeks that would immediately get the reference, they were presenting their language as being "everything that Perl isn't".
And since Perl is a "what the fucking fuck" language (yet it's my favorite ; yes I'm also a cat guy), it presented Python as an "easy to use, easy to understand" language. One sentence, eight words, and the whole philosophy being Python is summarized. But this never was, and will never be, the Python's motto.
At no time the Python team believed that their language was, and even less should be, this rigid. It's not even what they had in mind, and therefore even less what they intended to do.
Yes, they designed Python to be easy to use and as obvious as possible. But they are no fools, they know that, to paraphrase Jurassic Park because it fit perfectly, "coders will not be contained. Coders breaks free, they expands to new territories and crashes through barriers, painfully, maybe even dangerously". Said otherwise, they know that there will always be more than one way to do it.
They know it so well that it's said explicitly in the
You must be registered to see the links
; the text describing the philosophy that should be applied when writing Python code. This is yet another geek reference, and yet another way (with the "killed father" thing) to show the real intent behind the language: putting the past behind and starting a new era.
At this time coders, especially C ones, had
You must be registered to see the links
's
You must be registered to see the links
, generally shortened as "TAOCP" ; what led to a bunch of "The Art Of", and with them to the "TAO" expression. In response to this, Python decided to have it's "Zen".
I'll not start an explanation regarding Chinese philosophies, so in short, "Python take the best of TAOCP, and make it simple and practicable". There was the TAO generation, and it was now time to make place to the Zen generation.
Back to the topic, in the
Zen of Python you found those two lines:
"
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch."
What is far to the rigidity you attribute to Python.
Firstly, there's the "should". Therefore it's not an obligation ("must"), but a recommendation.
Secondly, it's weighted by the following "preferably". Therefore it's "as much as possible".
Thirdly, there's the "obvious". Therefore, this do not exclude the existence of more obscures, when not
You must be registered to see the links
or even purely
You must be registered to see the links
, possibilities.
And finally, there's the second line. This one can be less easy to understand, but in short it's a self-mockery. They recognize themselves that if you don't share their own views regarding how a programming language should be designed, then it will perhaps not be always "this obvious".
All this is also enforced by two other important lines, that appear early in the
Zen of Python:
"Simple is better than complex.
Complex is better than complicated."
By themselves, those three lines recognize that there's at least "three ways to do it" ; the simple way, the complex way, and the complicated one.
but then pretend it has objects and namespaces ("stores") that are really dictionaries under the hood?
I already
debunked this bullshit of yours.
And by the way, once again, what the fucking fuck is this "store" ?
hint: you are still talking about Python.
Why not just use dictionary syntax for everything, rather than this convoluted indirection to try and support features it doesn't actually support?
Why ? Well... Since I lost my patience I'll say it bluntly, and whatever if I'm harsh: Because you are an ignorant idiot who don't have the starts of a clue regarding what he is talking about.
You decided that you hate Ren'Py and Python, and that you should preach against them as often as you can, good for you. But the more you talk, the more it is obvious, at least for people knowing a bit the subject, that you hate them for no reasons. Or, said more precisely, that you hate them for purely personal reasons that are, in no way, linked to the reality. All your arguments against Ren'Py and Python as pure nonsense and are based on nothing more than your own wrong assumptions.
Take your two references to "store" by example. You're applying this to Python, pretending that it represent the way Python manage its namespaces. But the truth is that it's a Ren'Py thing. There no "store" in Python, Python do not manage its namespaces in that way.
And in Ren'Py they aren't namespaces. They are a mimic of namespaces, intended to mark a separation between the different variables, accordingly to their intent. This in order to limit the user confusion, the risk of name conflict, and therefore to hardened the language.
Anyone with a bit of experience in the field would quickly understand that it's the easiest approach when you have to design your own language. It's not necessarily the best approach, and depending of the language it can be an approach to avoid for many reasons. But in the case of Ren'Py, those reasons don't make much sense. The language isn't intended to run code allowing a remote access, nor to proceed third party code wrote in the same language and operated at the same level. Therefore there's no need for an enforced security layer. In the same time, code wrote with this language are intended to have frequent pauses (the time past reading the dialog), therefore speed efficiency is not a mandatory requirement.
Then, once you starts to think about it a bit more, this approach make even more sense, due to Ren'Py rollback feature. By storing the variables relative to the game (and to the game only) on an object, you then have the simplest possible design to manage the rollback feature. It suffice to make a (shallow) copy of the "store" objects, to have a full copy of the game context at a given time. And since this copy is made after each interaction, here speed efficiency matter. This while space efficiency is also a main criteria, since there will be a copy of dozen contexts.
No need to browse all the defined namespaces. No need to manage a list of variables then address them one by one. No need to maintain, and also keep a copy of, the name/type/value couple. You copy a bunch of objects, and it's done. This whatever how many variables the game have, and whatever how complex or deep they can be, and whatever at what moment the variables are created or deleted.
You also don't need to design extra code, just relying on the behavior of Python object is enough for all this to be automatically performed for you.
Finally, no, unlike what you claim, Ren'Py "stores" aren't dictionaries, like I said they are pure custom objects.
And, of course, also no, the "__dict__" dictionary is not how Python handle the attributes of an object. It's one, and only one, of the abstract used as interface between the core of the interpreter and the user.
Accordingly to the simplicity and obviousness approach behind the language design, Python team created this interface to offer an easy access to the attributes. One that permit to build the attribute name in real time ; something that would be way more
complicated to do without this abstract.
That you hate Python, well, it's your problem, good for you if you want, who care. But when you spread your bullshit beliefs through stupid preaches full of nonsense, then it become everyone problem.