Learning Python (at last)
-
In December I bought a bundle of 12 Python courses for the price of probably just one course. I am on my second course now and loving it; I can't believe I've not done this much earlier. What I'm really amazed at is all the power available in easily available packages. So far we've already done some machine learning and basic image recognition, GIS, and graphing: things I would not have ever considered while coding in C# unless asked for a specific deliverable. The libraries, built-in and external, are all so quick and easy to get started on but extremely powerful. I foresee lots of new articles starting as soon as I finish my second course and go back to that and the first one and explore all the libraries we've covered.
"'Do what thou wilt...' is to bid Stars to shine, Vines to bear grapes, Water to seek its level; man is the only being in Nature that has striven to set himself at odds with himself." —Aleister Crowley
last few weekends done some messing with python on raspberry pi the whole programming in terminal, even just short bits, is a whole different thing. as for python clear line error and message is great the white spacing I still dont understand how it is easier for new comers? "inconsistent use of tabs and spaces in indentation" Then you got messing with getting modules before you can run module for everything. But if you keep in mind with C#, most everything written is with .net framework which is a module, and compiling just hides some of that import and referencing header.
-
It was on special with online store Popular Science Shop, this course bundle[^].
"'Do what thou wilt...' is to bid Stars to shine, Vines to bear grapes, Water to seek its level; man is the only being in Nature that has striven to set himself at odds with himself." —Aleister Crowley
-
Quote:
However, that white-space driven scope drives me crazy... It is way to fragile...
That's not the only thing that's fragile; having type errors detected only at runtime is far worse than whitespace scoping. There's nothing like deploying an app and getting type errors the first time the user gives it the one bizarre combination of inputs that isn't in your unit-tests. Static languages catch these types of errors before giving you an executable to run; dynamic languages only figure out the type at runtime.
If you want static type-checking in Python, you can use 'import typing': [typing — Support for type hints — Python 3.8.3 documentation](https://docs.python.org/3/library/typing.html)
-
Both are equally bad. And these two are among my three top ranking reasons for trying to avoid Python. I don't know how to order them, with the third one: The way Python has created its own closed world, essentially not relating to anything non-Python. You can't just write a library function in Python to be called from another language. You can't just write a library function in another language and just link it with the Python code. ... Well, yes, you sort of can, when a number of preconditions are met, and using a few tricks. But you are not really supposed to. Python installation and updating goes by its own mechanisms. Of course Python has its own documentation standards and tools. And 70% (or thereabouts) of all Python programs must indicate in the implementation language in the program name. (Even Visual Basic programmers don't feel a need to give their programs names starting with "vb"!) For decennies, OSes defined a relocatable format used by "all" languages. The format defind a standard stack layout and calling convention for all languages. In those days, types were mostly hardware defined, but it wasn't uncommon to see standards for the layout of structs as well. The result was that you to a large degree could write each module of your system in the language best suited for the task, and link it all together. Today, ARM is promoting a single Application Binary Interface to make mixed-language programming feasible. dotNET is the same way. The just-in-time code generating and linking makes it somewhat different, but the end result is essentially the same. You do program in a selection of languges! E.g. you could set up the data structure for a screen layout as compile-time initialized data in a procedural language, but XAML is somewhat better suited for the task. XAML is a language for creating a compile-time initialized data structure, and leaves the playground for procedural code to take over these structures and use them further. Python just doesn't fit it here. It doesn't want to. Sometimes, you get a feeling that Python hopes to grow so much that it can squeeze out all other alternatives and rule the world; then it has no reason to worry about ABI and CLI and whatever they are called, all the non-Python standards. Python defines its own standards, ignoring everyone else. ARM ABI and dotNet leaves me with a much better gut feeling. They encourage me to use the language that is best suited for the task. Python does not. It more or less demands that I use
Quote:
And 70% (or thereabouts) of all Python programs must indicate in the implementation language in the program name. (Even Visual Basic programmers don't feel a need to give their programs names starting with "vb"!)
That's just petty.
Quote:
ARM ABI and dotNet leaves me with a much better gut feeling. They encourage me to use the language that is best suited for the task. Python does not. It more or less demands that I use Python, whether suitable or not. It takes away my freedom. That is probably on top of the list. The two other points come in second and third.
Using an ABI would make sense if Python was a low-level system language. It's not, and was probably never intended to be one; the language itself is written in C (See CPython). It's meant to be an abstraction-layer language, and if C can use an ABI, it wouldn't take very much work to abstract it in Python. I like Python because it's a simple language that allows me to write up a proof of concept with very little impedance between the idea and the application in itself. If I need OOP, I can use it, but I'm not required to. Type checking is an option, and what's more free than being allowed to choose? Have I made embarrassing messes with Python? More than I'd like to admit, but every time I did, I learned that I wasn't thinking in Python, but thinking in X-Language, and *translating* it into Python. Since I don't work in Python on a daily basis, thinking in Python (TIP) doesn't come as easily for me as it would otherwise. Nonetheless, when I'm in a TIP-state of mind, the code I produce is leagues ahead of what I produced with the thinking-in-X-then-translation method.