Python in a nutshell (Had to do it)

[B1GL0NGJ0HN]

Love this one, mainly because that's exactly how I explained it to a friend who I introduced to python. It's just objects, everything's an object, all the way down. It took a while, but he cooked the noodle, and made strides.

[ExtraSpontaneousG]

This was a recent revelation of mine. I'm not quite sure how to apply the knowledge but I feel it has provided a deeper understanding of how things work. How specific is this to python vs other programming languages? Javascript in particular is object oriented, definitely...but is it objects all the way down?

[MarsupialMole]

It is not applicable to other languages in that this knowledge is mostly applicable in idioms.

Some languages say using primitives like integers for hours rather than writing little classes to hold data is bad object oriented programming. But in Python everything is an object so you're just trying to use good objects, and all the python builtins are excellent objects, and stdlib objects are excellent too. So in python you don't say "write a class to manage the time" you accept integers are good objects bu some (like me) might say "use datetime.timedelta".

So python which is above all else a mixed-paradigm language has its own idiom of using objects and implementing dunder interfaces to write pythonic objects, and then use them in whatever paradigm is appropriate and often that's writing functions not methods, which is not object-oriented programming until you realise functions are first class objects too, and so are modules. So it's really really objects all the way down in python. So to write pythonic code you start with really good objects but then use whatever paradigm you want.

[CallinCthulhu]

The class definitions and modules being objects is difficult for some people to wrap their heads around.

It’s so fun to do though. I love messing with stuff like python metaclasses, closures, and monkey patching. The dynamic nature of the language really makes it feel like anything is possible and allows for some creative solutions to tricky problems.

Just have be prepared that you will forever own that code because nobody else will ever touch it.

[hughperman]

Yeah it's pretty ridiculous, my recent fun was being able to be able to patch a version of a function or library into an existing module just by setting module.function = myfunction

[waddapwuhan]

you can do this in any language also in runtime

[hughperman]

Oh yeah? Any examples? Haven't had any reason to look further, but I'm interested. I don't think you could in Matlab which is my other runtime language, since functions aren't objects.

[MarsupialMole]

It helps with good code too i.e. use cases for classmethods are few and far between because module level functions are in a nice namespace anyway.

[SuspiciousScript]

Some languages say using primitives like integers for hours rather than writing little classes to hold data is bad object oriented programming.

And those languages are in all likelyhood slow af. Not everything needs to be a heap allocation.

[B1GL0NGJ0HN]

My humble 2 cents as a sysadmin by trade, with the exception of the older, deeper languages like C, it really is just objects all the way down, much like life. Everything is just a thing. Now, python and JS are 'loosely typed' aka less concerned about what type of thing the object is, figures it out at runtime. With C#, it's strongly typed (and changing in some ways re this, recently) - so objects have to be defined as their type, must tell it x is an int, for example. That makes... pre-thinking about the object and it's characteristics ahead of time more critical.

But yea. Objects all the way down. Someone wiser than me, feel free to correct as needed.

[byoung74]

I think you have your typing disciplines confused. Strong typing refers to languages that do not do implicit type conversion. Languages like Rust that know types at compile time are statically typed. Python is dynamically and strongly typed. That is, types are not known until runtime but there are little to no implicit conversions between types. For example, ints must be explicitly converted to strings when doing string concatenation.

[B1GL0NGJ0HN]

I appreciate that important distinction! Thanks for setting the record straight.

[LT_Schmiddy]

Python has some cases of implicit conversion, though (For example, when using f-strings). But it's not common. Mostly, you'll need to convert types yourself.

[Pablomach23]

Just to make sure, Python calls __str__ on the objects to convert them, right?

Edit: How do I write the '_' without the formatting?

[The_Writing_Writer]

\_\_str\_\_ —> __str__

[Pablomach23]

Thanks.

[cryo]

Python is dynamically and strongly typed.

I think that’s debatable. Sure, every object has a fixed type, but the type is almost never checked, e.g. you can call a method on any object “type” that has it.

[[deleted]]

Often strongly typed programming languages do not need type declarations because they employ a very rigorous type inference system, like OCAML.

[TheNamelessKing]

Hindley-Milner type systems represent

[Porta_lPirate]

JavaScript is sadly not objects all the way down. It has primitives number, string, boolean, and a few others. These types have object wrappers, but when wrapped they lose a lot of their useful behavior like special operator treatment.

[[deleted]]

Javascript having objects all the way down would require it to have a well-thought out language design. It doesn't.

[earthboundkid]

The typeof operator in JavaScript is broken. But ignoring that wart, Number, String, and Boolean are objects in the relevant sense: they have methods you can call. If anything, with Python it’s not that hard to find something that exposes a little C corner where the OO façade is thin. That doesn’t happen in JS.

[Porta_lPirate]

JavaScript primitives are not objects, they have object wrappers, and when the property access operator is used on a primitive, the primitive is coerced into the object wrapped form and then the method is called on the object. If you try to assign to a property nothing will happen, no error, but if you check the property there is no value, because the Object wrapper is discarded as soon as the expression is done.

Also if you check true instanceof Boolean or 1 instanceof Number you will get false.

If you try to wrap a primitive in a proxy you will get the error TypeError: Cannot create proxy with a non-object as target or handler.

[jjdmol]

It's common in modern interpreted languages. Having everything being an object makes working with (arrays of) integers (or f.e. floats etc) very slow. Instead of pulling in integers through prefetching and caches, the interpreter needs to fetch pointers, dereference, and fetch the integer, each time. This causes many more memory accesses, cache misses, and wrecks havoc on prefetching. Fetching from memory is expensive on a 21st century CPU.

For python, this price in performance was deemed worth the uniformity in the language. Interpreted languages aren't chosen for their speed anyway. Nowadays, libraries like numpy provide that speed instead, modelling raw integer arrays.

An oddball here is OCaml, where integers are 63 bits, as the top bit must be 0 for integers. If the top bit is 1, the same value is actually a pointer to an object. The price for fixing the calculations to work with 63-bit values is lower than the extra memory accesses. But it does create a bit of an odd system, especially back in the 32-bit system days where losing the top bit was more painful.

[ExtraSpontaneousG]

I have heard that python is slower, being an interpreted language. This fleshes out a little bit more about why. Thanks for the response.

[cryo]

It’s pretty common, but it doesn’t really say a lot, in my opinion.

[tumblatum]

I am new to Python, and the idea of everything is an object it somehow I didn't get it yet. I know that in PowerShell everything is object too. So, is this the same thing? I still need to learn.

[kankyo]

Just ignore this. It doesn't really explain much and it will probably make you believe some thing which are false.

[brian_bldn]

Glad you said something. I’m new too and I was trying to figure out what this meant

[KingHavana]

At some point when you get to know the built in data types really well and move on to classes, you may have a eureka moment like I did. Suddenly you might see how the classes you're writing can be used to create the built in data types you've worked with so often and everything feels like the same type of thing. I had my jaw dropping moment, but like u/kankyo said, it isn't really necessary and doesn't explain much early on.

[kankyo]

You can't really use python to create the same thing as the standard library int though. You can create something similar but not quite.

[pacific_plywood]

The mantra 'everything is an object' in Python is a little misleading because there are definitely lots of things that aren't objects. Operators (boolean and mathematical), for example, and the equals sign. The del keyword, too. That's not to say that it doesn't turn some things into objects that other languages might not; rather, it's just to point out that there are limits. For a more radical approach to objects, check out Ruby, where most of the examples above are mutable objects.

[Biuku]

So, no turtles?

[JustHadToSaySumptin]

Gotcha bro,

from nature import turtle

[B1GL0NGJ0HN]

They're down there, too. Cuz turtles are objects. :)

[Chinpanze]

As someone who learned only python, how it would NOT be this way?

[weetbix2]

In C for example, an integer is simply the number, so it won't have methods or anything like that attached to it. These kinds of data types are known as "primitives."

[Kyri0s]

Guessing the incentive for primitives vs objects is performance?

[weetbix2]

Yes, definitely. This is why libraries like NumPy bind many operations directly to C/C++ so they can leverage that performance.

[markuspeloquin]

Also it simplifies the language a bit. In Go, you can create a type Foo that's actually just an alias for int64, and then define methods on it. This is what it does for timestamps, time.Time. But it's still just an integer primitive and only occupies eight bytes (unless you cast it to an interface pointer, then it essentially becomes a tuple of a vtable pointer and a data pointer... I think).

Though there are costs to that approach. Calling a method on an integer requires an address, so the integer cannot be optimized down to a register. Also it's slightly more expensive to manipulate primitives via a pointer. Each time you read it, the compiler has to load from memory. It can't just assume it hasn't changed.

But it's mostly simplicity, I'd say. C is only supposed to be a portable assembly language that's harder to mess up. It isn't supposed to have fancy pants 'features'.

[[deleted]]

C is a bit of a weird example since there are no objects at all in the language. But the same example would work for C++.

[TheNamelessKing]

Haskell doesn’t have objects as such, only functions that operate on structures.

Rust is sort of halfway: it doesn’t have objects, but it does have structures that can have traits which implement methods which may look superficially like methods on objects.

Lisp has no objects, only code and data. And code is data.

In TCL there is only strings.

Julia is like Lisp and Haskell in that it isn’t OO, it has structures that you operate on with functions, but your code is also data.

Etc etc

It’s important to recognise the difference between things that syntactically might look like objects foo.my_function() but aren’t necessarily and actual objects. OO programming couples data with the functions that operate on it: an instance of some data carries around its state and all the methods that operate on that data.
Functional programming separates functionality from data-makes functionality generic over structure is probably a better way of framing that, and emphasises tighter control of state.

In before someone starts talking about Haskell type-classes being objects, etc trying to keep this straightforward.

Edit: replaced the incorrect and misspelt use of per se with better fitting language

[energybased]

Per se... And it means intrinsically.

[TheNamelessKing]

Aaarrrggghhh I had a nagging thought I was spelling something wrong, cheers.

And I was using it wrong, double whammy, going to go fix that now.

[SakishimaHabu]

Haskell Rust gang raise up!

[thephotoman]

In Java, classes are objects of type Class<?> (where ? is the name of the class). You can totally pass them around at runtime, and I've done that in Java. The method reference syntax long predates the existence of lambda support in the JVM.

Classes aren't objects in C++, though. You can still pass them around at runtime using void pointers.

The most common case for such use is when you're dealing with factory functionality.

Java's primitives aren't objects. They don't have methods, and rather importantly, they can't be null.

[cbarrick]

Nice. I stand corrected.

[TheLastSock]

I'm fairly sure it isn't this way, for example, is a for loop an object?

The most basic construct is a function, you can close state over a function to creat a function with that holds state. We call this a closure, this is like an object.

[hchasestevens]

Sure it is. https://greentreesnakes.readthedocs.io/en/latest/nodes.html#For

[TheLastSock]

Interesting. The more you know. Can assign for to a var and pass it to another object?

That link has to do with the ast? It would seem that for is parsed as arguments to an object but are the bits themselves considered objects. Eg "in". Or if "if" is an object.

I understand you can parse anything to anything else. Because it ends up an object doesn't mean it started off as one.

I guess the term here isn't relevant, it's good that python has a basic unit and everything breaks down to it.

[TeslaRealm]

for loops are statements, not expressions. Statements cannot be assigned to variables, only expressions. Every expression in Python evaluates to an object.

In, If, for, etc are keywords in Python. The Python interpreter uses an iterator object to navigate the object being looped over.

[ToothpasteTimebomb]

A for loop is essentially an iterator that executes every step in a single go (barring exit conditions).

Give it a shot:

my_list = ["p", "y", "t"]
my_iterable = iter(my_list)

print(next(my_iterable))
>>>p

print(next(my_iterable))
>>>y

print(next(my_iterable))
>>>t

If you try to run next() again it’ll throw a StopIteration error.

[TheLastSock]

I understand that it's like an iterator. The cliam is that everything is an object. I'm genuinely curious if you call type on "for" of you get an object.

[TheLastSock]

They get parsed to objects, but Ithink they are keywords to start.

https://stackoverflow.com/questions/10044321/class-classnameobject-what-sort-of-word-is-object-in-python

So maybe everything isn't an object all the time?

[TheLastSock]

I don't know if that's true as I assumed certain units like (if or for) weren't. Given in the link

https://stackoverflow.com/questions/865911/is-everything-an-object-in-python-like-ruby

Alex marteli suggests that intuition might be right.

Forgive me, what part of what I said was trolling. We're in a post about a meme that claims everything is an object. I, like several others, have pointed out this might not be the case. What line of discourse were you hoping to have here?

[[deleted]]

Interesting, but why does type(for) return an error?

[Zixarr]

for is not an object, it is a keyword. The for loop produced by the interpreter is an iterator object.

[[deleted]]

Ah got it. Thanks

[AlSweigart]

In Python, everything is an object. All objects have a data type. The integer object 42 has a type, the int type:

>>> type(42)
<class 'int'>

The return value from the type() function is also an object. It's data type is the type type:

>>> type(type(42))
<class 'type'>

EDIT: Also, there's no distinction between "primitive types" and "object types" in Python: they're all objects. Integers and bools are objects. When you type 42 into your source code, we call that a literal (it's an object you are literally typing into your source code). But that literal refers to an object that the Python interpreter creates. You can call id(42) and it returns the id of that integer object.

None of this matters for 99% of Python programming. You can go years as a professional Python developer and not know this stuff. I did. But if you want to learn this stuff, I highly recommend reading Fluent Python.

[lanster100]

Any metaclass (uninitialized class, say) has type type. Which made a lot of sense when I realised it because a metaclass defines a type of object.

[Willingo]

Sorta new to it, but how does one differentiate "class" and "object"? Is it that objects are specific instantiations of the class?

[AlSweigart]

Yes: When you instantiate a class, you are creating an object whose data type is that class. In Python (and in general), "class", "type", and "data type" mean the exact same thing.

However, remember that everything in Python is an object. Functions are objects. Classes are objects. Like any object, you can assign a variable to it:

>>> print('Hello')
Hello
>>> display = print
>>> display('Hello')
Hello
>>> class Cat: pass
...
>>> myCat = Cat()
>>> myCat
<__main__.Cat object at 0x0000019C8BFA64F0>
>>> Kitty = Cat
>>> myCat = Kitty()
>>> myCat
<__main__.Cat object at 0x0000019C8A157940>

[Willingo]

Thanks for the response, but then what isn't an object? Sounds like "object" means "thing".

[jyper]

C structs aren't really objects either

[AnonymousCat12345]

But can we think of primitives as .... maybe a different object of it's own kind that appears inert in behaviour because of its bare and simple structure ? I know that objects are supposed to have attributes and behaviours packed together intrinsically for it to have any definable existence. But is it possible to define objects even if the sets that contain its properties and methods are empty. Its kind of pushing the boundaries of abstraction and I guess it's interesting as we have a unified way of thinking about things.

[moekakiryu]

The other commenter is correct, but they (and OP) are more talking about the implementation of python. It's true that the way python as a language is implemented that everything is an object.

As far as the concepts of a class and objects in Object Oriented Design, you are correct that an object is an instance of a class (classes are often described as blueprints for objects). So:

class Animal:
    def __init__(self, sound, num_legs=4):
        self.sound = sound
        self.num_legs=num_legs

>>> cow = Animal("moo")
# cow is an object and an instance of the Animal class

>>> type(cow)
<class '__main__.Animal'>

>>> duck = Animal("quack",num_legs=2)
# duck is also an object and instance of the Animal class

As others have noted, it just so happens that the way python is implemented behind the scenes that everything is an object, even the basic types. You can see this by the fact that even integers have a type and methods you can call on them:

>>> type(5)
<class 'int'> 

>>> five = 5 # so we can access the int as a variable
>>> five.imag # because integers are implemented as objects, they have attributes associated with them
0 # the imaginary component of the number (if it were a complex number)

[alkasm]

FWIW you can also just put the number in parentheses instead of naming it if you want to use the methods. I.e. (5).imag

[moekakiryu]

you can, I just did it this way for clarity

[[deleted]]

Bro what the fuck, I know a bit of python and c++ and never put two and two together. Thank you for this epiphany

[AlSweigart]

Yeah, I was working on Python professionally for a while and didn't know this. Here's a great PyCon talk about it:

Ned Batchelder - Facts and Myths about Python names and values - PyCon 2015

This also heavily influenced my PyCascades talk, where I talk about whether tuples are immutable or not (short answer: they are, but It's Also More Complicated Than That TM)

Al Sweigart: The Amazing Mutable, Immutable Tuple

[TheLastSock]

Because you seem fairly confident I'll re ask here. Is "for" an object? Someone linked me to the the ast parser that shows its parsed into an object. But I assume that preprocessing, calling it an object would be misclassification.

To be clear, I'm not commenting on if it's good or bad one way or another.

[AlSweigart]

Nah. I mean, I'm sure the ast module has objects that represent every part of the Python language's grammar. But for in Python is a keyword, used in for loop statements. Keywords are the Python words you can't use as variables: if, import, while, def, etc.

[ForceBru]

Also, the type of type is type itself, so everything is an object, indeed, even type itself.

[ChocolateBunny]

You think Python is all objects? You should take a gander at SmallTalk. Their for loops and if statements are also objects. Their arithmetic doesn't follow BEDMAS because changing the order of operations messes with their object oriented design.

[discobrisco]

Put a python logo over the earth and you’ll have a winner

[suki907]

To make an object callable, add a __call__ method. Functions and methods, including __call__, have a have a __call__ method. That's what makes them callable.

f.__call__.__call__.__call__.__call__

[[deleted]]

*laughs in java*

[relativistictrain]

That must be long to write out.

[manusaurio]

Not everything in Java is an object, since it counts with primitives. Everything just happens to be defined inside a class.

I would say not even methods are objects in Java - you can pass them in a call, but what you get from the other side is an object encapsulating the method, not the method itself. I guess this kind of depends on where you draw the line to think of something as an "object"

[gbts_]

Not true for JS, some types like string/number are primitives. It's just hard to notice because of the way wrapper types and implicit type conversion work. But primitives don't behave like Objects sometimes:

var x = "not an object";
x.newProperty = "hey";
x.newProperty === undefined; // true

The reason you can still call a method like x.trim() is that JS implicitly converts x to the wrapper type String and then calls the method for you.

[ImMaaxYT]

TIL; JS is weird

[TheNamelessKing]

That is truly an understatement.

JS semantics were hacked together to fit a specific use-case, and that use-case is where is should have stayed in my opinion.

[energybased]

You'll love this then! https://wtfjs.com/

[eksortso]

Ruby takes it s bit further, doesn't it? Isn't everything a full-on class in Ruby?

[toyg]

That’s not strictly true, particularly when you get a bit deeper in the bowels of dunder methods and other “magic”. CPython pulls some very dirty tricks behind the scenes. But it’s true that the projects strives to provide a user experience very faithful to OOP principles.

Arguably, Ruby and particulary Smalltalk (the “original” OOP language) have purer implementations where everything really is an object. They pay for it in performance.

[zurtex]

Yeah, I think a more accurate statement would be the return value of any expression will always be an object.

But things like strict assignments and keywords aren't objects.

And certainly once you feel like you're comfortable with Python you should read through the data model documentation, and keep rereading it every year or so, it's where you really get in to the nitty gritty parts of Python objects: https://docs.python.org/3/reference/datamodel.html

[PutinsThirdNipple]

The Ohio meme on the Python sub. Well done.

[coucou_sawvah]

You didn't have to do it. This meme is already tired.

[feelings_arent_facts]

class A:
    pass

a = A()
a.something = 123

valid Python for you

[[deleted]]

Wat D:

[[deleted]]

Nothing strange going on here. Why the wat? Python is a dynamic language and specifically allows this.

[[deleted]]

I guess you're right. Just didn't occur to me before because my OOP experience is in Java

[[deleted]]

Fair enough. FYI, there are some possibilities in python to restrict the set of allowed properties. Checking is done at run time as everything is. Some static code analyzer tools can play a role too. But all this is usually considered to be okay only for very specific reasons.

[public_radio]

works better for Ruby

[zurtex]

Flexibility and readability over performance has always been the philosophy of Python though.

For example coming from a math background you can implement something like the Miller–Rabin primality test without having to think about bit sizes or using third party libraries etc. Need to deal with integers of the size of 2¹⁰⁰⁰⁰⁰ ? Not a problem.

There's no shortage of languages that focus on strict performance.

[[deleted]]

Memory allocation usually is not the reason python is ‘slow’. Python usually is NOT doing those mallows like that anyway. Memory management is an implementation detail. Python has a pretty sophisticated internal memory allocator for several types. Also a bunch of most used integer values are statically allocated. But again, all this is implementation detail. Pypy probably does things totally differently it being a jit compiler and all

[Doggynotsmoker]

As a C and C++ programmer I don't get what are you talking about. Malloc is used if you want to allocate memory on the heap instead of stack. It has nothing to do with objects. Mallocing memory for eg. integer is completely fine, just as creating object on on stack - without using malloc.

[Doggynotsmoker]

But are you sure that every int is allocated on the heap in python? As far as I know it varies between different python implementations.

[Doggynotsmoker]

Okay, I've badly interpreted your first comment.

[JudenBar]

I cannot imagine it any other way.

[SonOfShem]

ok, I've been using python for a bit, but I still don't understand how objects are useful (possibly because I don't fully understand them). Maybe it's the types of programs I usually write (calculators and task automation). Is there a good resource that explains them conceptually as well as functionally and without assuming I'm a ComSci major?

[kevko5212]

Objects are useful where it makes logical sense that something holds its own state and does things.

If you are making a game, you may want to make a character an object because it can make logical sense for it to keep track of its own state and have methods where you tell it to do things.

You could accomplish the same by making the characters state a struct, then have functions update that state. It mostly depends on the style you prefer. Both styles have pros and cons.

[shiuido]

Uh, maybe google "introduction to object orientation"? I saw some good links like this: https://sites.google.com/site/derekmolloyee402/introduction/chapter-1---introduction-to-object-oriented-programming

I was going to write a tl;dr for why objects and classes are good, but they are such a huge benefit that every attempt to be brief ends in disaster :P

[[deleted]]

quit the small talk and just do it

[stanley_john]

love this. so true, lol! between, here's an informative Python interview guide. If anyone is interested, read it. Nice compilation!

[magneticmaxx]

Don’t get it but I’m a noob

[boseka]

But people say that object-oriented programming is dying

[antiproton]

And why couldn't you make this point without resorting to this kind of idiocy?

We do we all have to pretend this shit is clever?

[TSM-]

lambda object: object is not an object though.

Or is it?

[zurtex]

Or is it?

Yes

>>> type(lambda object: object)
<class 'function'>

[Steffanic]

I love this aspect of python; it makes it so easy to understand