python for dummies

e.g. for me. [tl;dw / ignorant's rant, "Whatever it is, I'm against it"]

    I don't like Python. I don't know it, I fear it, I tried it, I seriously can't stand the amount of hype and naive fanboyism it produces (or gets for free). I'm totally lost in the number of solutions it provides to problems, trivial or otherwise. Recently I made myself watch a video on Python classes (or OOP in Python) and got stuck with the __init__  part, that I would tend to identify with "constructor" but perhaps it's not the pythonic way to call it. The example was an academic one: you have your good old Dog class that keeps the dog's name, age and a void speak() function ("method" is what they call it nowadays, it's a function for me, it does something, may return something, it's not a component or field. Or property, which I don't distinguish from a field, I'm just too ignorant) that prints "Woof!" on the console. Great.

    By the way: it's funny that overriding the virtual speak() implemented in the parent Animal class is done without any extra keywords in the child class. I don't know if it leads to problems and/or ambiguities. I suspect that if I were to code that thing, that would be the case, by Murphy's law. Or perhaps there is automatic overriding and if you want the parent function you use the __super__ thing? Or just define nothing in the child class. I don't know. And I don't need to know. For I decided to avoid classes in Python whenever I use it. (It happens only if the combo of bash, sed and grep results in such utterly unreadable and unmanagable trash, that it's impossible for me to follow, say, after an hour, what was going to happen when the script's supposed job had been done. And after two hours I even forget what the job was; it's more important that it's done and I can proceed further.)

    Anyway, looking at the definition

class Dog:

    def __init__(self, name, age):

        self.name = name

        self.age = age

I asked myself, how the hell The Python Almighty knows the author's intention that name should be a str and age an int. It f....n' doesn't. The author or the user of that class has to take care of this, so it seems. There is some solution for it (or a hundred). This behavior allows of course for great amount of "flexibility", like

dog = Dog("Bernese", 5)

and

otherDog = Dog("Beagle", "four")

which looks weird for someone like me. I'm too simple minded and totally don't get the idea why anyone would actually need different instances of the same class with actually other types of fields/components that have the same names... Division into instance and class variables is something different and I can see some sense here. Like implicit inheriting some global (or external, or static) properties for all the instances. Somewhat similar to what COMMON did for Fortran subroutines.

    The above example may be ok if your only job is printing out the dogs' data, once "Hello world!" is too easy and boring. But what if you want to know the average age of as many dogs as your memory can hold? Well, if you're an OOP maniac, you're perhaps going to wrap an array or list of Dog objects in yet another class and write a function that does the summing (if your average is of arithmetic kind, in the case of geometric or harmonic one, you go to multiplications, divisions, weights turn to powers/exponents etc.) of elements' .ages, casting the result to the float (double?) type, dividing by the list's count (or len), rounding etc. (or calculating roots in the geometric case). And for our Bernese and Beagle, 5 + "four", you're left with an error. Already. Something that in normal C-like languages would not even allow you to compile the damn thing... Of course, if it's user input, you have to check its validity, e.g. if one of your argv[] elements can be turned into an int that the programmer had in mind.

    One of my conclusions is: I don't think that's the way you should teach about objects. I think classes are there to make my life easier. They do, but in Python it's just a retreat to something more difficult. With no

    I read one post (and answers) on SO related to the above problem. It was fun to read, especially people quoting their Language Gurus Who Once Said Something Very Significant About Zen, Simplicity, being Explicit etc. There were some sane and critical posts, pointing out mistakes and misunderstandings which were rather obvious afterwards. But the context of hype and all the fanboys being so eager and enthusiastic... it only added to the fun of it all. It's a bitter kind of fun. I'm happy to read C++/C# or Java related stuff (I don't know Java, but I can more or less follow what's happening), it's just so much more mature.

    Almost everyone and their dog is excited by Python. Just as everyone can be fascinated by the number pi, and some of the weaker minds will burn out trying to "prove" it's rational. Just as some weaker minds in physics (especially retired engineers, turned crackpots) tend to work on cosmology of their own, relativity (or fight and "abolish" relativity fiercely, in favor of "neo-Newtonian" approach or name calling Einstein based on, say, national and/or religious "arguments"...) Others are in neverending search for some new realization of a perpetuum mobile etc. Ok, what can I do about it? Nothing...

    I don't think of Python as giving me freedom in the example above. Lack of type constraints built in in the object's contstructor seems to me like allowing someone to drive their train without the need to set the tracks before. Which is ok if you like to run into cars, cattle, people, buildings etc., and the cars, cattle, people and buildings don't mind being hit by your train. Perhaps you're so fast they don't have time to complain? (The fact that I don't think everyone deserves and is able to acknowledge freedom has nothing to do with that.) In my stiff- and narrow-minded view, Python is too much anarchy in the place where I expect order and rules. Not just for the sake of imposing these on others, but to actually make things easier... It reminds me of an old Soviet joke about their political youth organization, the Komsomol (Kom = Kommunisticheskiy, So  = Soyuz, Mol = Molodezhi, The Communist Youth League, approx.). So, it's Soviet Union, a very hot summer, and some guy is mowing a lawn in a gas mask, using scissors. A girl passing by stops and says, "Why do you work in a mask, why don't you use some machine?" "Well, I'm a member of Komsomol, I can't work without extra difficulty!" "Well, when you're finished, how about us two have some sex?" "Ok, but only in my hammock!". [Round of applause for Fozzie Bear...]

    Well, in normal circumstances, I'd probably either inherit from Dog and create separate DogWithNumericAge and DogWithStringAge or so; or use object as a more universal type, and then cast the constructor's input to specific types later; or make a template, Dog<T> and have the age component be of type T. If I need that, I'd have to create that distinction, and in no way would the "wrong" Dog instance get into my (numerical) averaging function... It seems to me that in Python someone chose the object variant for me and requires me to workaround its dangers or ambiguities somehow, back to the state that I treat as the most basic.

    Can you master Python? If you're young, of course. Especially if you're ok with the hype and following the herd. Warning: "we have to eat crap, billions of flies can't be wrong". Can I master Python? No, probably not. I don't think I ever need it. I hope not to need it. For I see no reason to make it so hard, in such a weird way, at such low a level. And I can't imagine (yet) anything I need done that I can't do using C#. I can't say this about C++, but I will do my best to learn the newer version than the stuff I was "taught" at the university in 1998/9.

    Summing up, long story boring... To me Python is a painful joke, full of strange and unexpected traps, totally weird syntax etc., larger scripts are very hard to debug since you see the syntax errors one per run, if you don't use an IDE. My first approach was to write the Snake game, I made it and then stopped at the problem of listening to keyboard events which just didn't work, for some reason. So, the effect was more like poor man's Snake ("Snake in your pocket", that's how being stingy, not poor, is described in Polish), that would have moved only when the player actually pressed one of the arrow keys.

    It will always be my guilty pleasure to code this or that in Python, just to take a beating. And if I don't get that, I'll redefine the term just to find some, and complain afterwards. And getting beat up is a very important part of life. Take climbing, running or cycling: you get extremely tired. Especially when cycling in Italy, when you're tired not only because the road is steep (cycling in the Alps is my hobby anyway), but because its pavement is so f****g shattered, full of cracks, potholes etc. If you don't believe me and you're into cycling, go to Valle Varaita and have some fun up Colle d'Agnello. Especially from Chianale; it's only about 900 m, but it's super tough if you do it in one push; and the scenery is just breathtaking... Similarly on the French side, but the ascent there is a bit longer (1300+ m) and easier, but it's still very difficult. (Yes, Stelvio is so overrated...) Then go down the road to Piasco (it's where the Alps are just hills and you can see some flat terrain) and perhaps take the most straight route to... Iseo. No, actually don't do that, it's dangerous, especially at night. Hitting a really nasty pothole and having to change two tires that got four punctures each, and it's 2:00am and plenty of mosquitos... it was sick. "What does not kill you, makes you stronger". So, perhaps I won't get suffocated by that bad reptile. But I hope to remain as hateful about it as possible. And write as C-looking code as possible, so as to be able to understand it myself afterwards and annoy others. On the other hand, I doubt they will ever look at it.