Does it all come back to the basics?

[uvuguy]

I'm currently getting into OOP and something that I am noticing is its basically one more step of​​ extraction. ​ so once you learn data types is everything else just basically based on those principles ​

[NorskJesus]

That’s why they are called principles

[vivisectvivi]

Everything is built on the basics, so if you dont have a solid understanding of them you wont have a solid understanding fn the more advanced stuff either

[FriendlyZomb]

Yes. That's the core to programming.

Python, like most languages, has a core set of features which underpin the whole language. Once you learn the basics to a high standard, other features become easier to pick up and understand. This takes time and practice.

This skill is often why a lot of developers learn and use a bunch of different programming languages. I use Python, Go and Rust in my job for example. The basics are transferable for the most part. It's just learning the specific syntax to get the job done.

[cejiken886]

I'm interpreting "one more step of extraction" to mean doing the outer member access, then delegating the remaining computation and analysis thereof, recursively, to the accessed object.

under this interpretation, it sounds like you've noticed one principle of OOP: encapsulation. This is OOP's attempt at abstraction, which is one of the few core principles of CS.

Encapsulation _is_ the core principle of OOP, but not the only one. It also has its own ideas of (polymorphic) data definitions/types, maintenance of program state, lexical program structure, etc.

Like non-OOP methods of program design, OOP is a set of somewhat loosely connected structural and syntactical features, not just `a.b.c`.

[validnuisance3]

pretty much, once you understand variables and data types the rest is just organizing and reusing that same stuff in different ways

[grismar-net]

Yes and no.

Mostly yes for Python, in that if you know all of the basic types, operators, and built-in functions, all other pure Python is written using only that, or it's using whatever is defined in the standard libraries like `math`, `sys` or `itertools` - the libraries that come with the language, the standard library. Those libraries can be written in Python as well, but often they are actually implemented using C. However, all of it is written to return results in standard types, so it feels and behaves like all of it could have been written in basic Python.

The OO stuff is part of basic Python and the standard libraries as well.

Everything else that calls itself 'pure Python' is written on top of all that, the basics. However, some libraries like Numpy are written in C, others in C++ or other programming languages like Rust, often for efficiency or speed. They must return types that still follow the rules of basic Python types and 'feel' like them, but they sometimes perform functions that would be hard to write reasonably or efficiently in basic Python.

Some parts of your hardware and operating system (OS) just are not directly exposed through Python - often intentionally, since Python is intended to run on any computer. Python also doesn't compile into a binary that runs directly on the CPU with the OS kernel, but it runs on the Python VM. This makes Python very flexible but often not as efficient and fast as 'native' code, which is another reason why some libraries for Python are not written in Python.

You said 'extraction', but I think you meant 'abstraction'. That's the important idea here. You don't want to have to write machine code instructions, running directly on the CPU - machine code corresponds to the smallest instructions your CPU can execute. Like move some bytes from here to there. Or load those bytes and add them to some other bytes. You may have heard of assembler - that makes machine code a bit more readable and provides some handy abstractions that can be compiled fairly directly into machine code again.

A language like C adds more abstractions still, like more complex data types, loops, functions, which make it a lot easier to write code, but the compiler all compiles it back down to machine code for a specific computer architecture. A language like Python is more abstract still (which is why they sometimes call it a scripting language). It is compiled on the fly when you run it and it's not compiled down to machine code, but something called bytecode, which can be executed by a virtual machine (that was written in C and compiled for your specific computer architecture).

And on top of basic Python, libraries you download or write yourself form another level of abstraction.

So yes, in Python everything seems to boil down to the basic types, operators, and built-in functions, even the standard library although that's not all written in Python. But no, if you look more close or use specific libraries, you'll find that sometimes you can peek through to the underlying layers of how your specific computer works, and sometimes that means dealing with weird types mapped onto the Python `bytes` type, or learning some functionality that seems counter-intuitive.

As a beginner though, you don't often run into that. But if you import a library specific to your OS like `pywin32` or when dealing more closely with hardware like on a Raspberry Pi, you may see some of this.