On Mon, Mar 4, 2024 at 1:09 AM DL Neil via Edu-sig <edu-sig@python.org> wrote:
On 4/03/24 06:30, kirby urner wrote:
On Sat, Mar 2, 2024 at 3:37 PM Wes Turner <wes.turner@gmail.com <mailto:wes.turner@gmail.com>> wrote:
They're dunder methods; double-underscore
Certainly they are and my intro definitely includes this information.
Check out the following Dog class, endowed with two of Python’s “magic methods” also known as: “dunder methods” (with “dunder” being short for “double underline”) or “special methods”.
In composing that post I dragged and dropped the JPG showing the actual source code for said Dog class, as it appears in Medium, but perhaps embedded pictures are not encouraged by HyperKitty's current settings, I wouldn't know. I was a nominal listowner here for a short time but then lost those credentials somewhere along the way, while still being able to post. Pleased to meet you mice dancer. A prof in New Mexico playing with ChatGPT4 just sent me what it says about me: https://flic.kr/p/2pBi659 (may be magnified) Lets I wasn't prepared for the Mailman 3 slash HyperKitty overhaul, which isn't to say anything against it happening. So what if I was unprepared? That happens a lot. Stuff happens.
Please read "Why naming things is hard" (https://hilton.org.uk/blog/why-naming-things-is-hard) - and yes there is any number of similar articles.
OK, done. The pertinent quotation is "There are only two hard things in Computer
Science: cache invalidation and naming things." (Phil Karlton).
When training, the difficulty of choosing names is magnified by the difficulty of choosing examples. Short, understandable, apparent, illustrative, etc...
So, here's a (Socratic) question: have you ever met a computer scientist or programming professional who has had to write code about a dog's stomach, or even the other popular one: a bowl of fruit?
Next Socratic question: could we, or should we, choose more realistic examples (and names)? Yes, high schoolers have little experience of the world and of commerce. So, talking of products and minimum order quantities might be a stretch. However, there are plenty of examples where we can talk about class Person, and either a wallet which we'd like filled, or a list of skills being learned, for example.
Ah so, it's the fact that I'm doing a Dog in particular that maybe irks ya. Not well-grounded in a professional use case. Sometimes I go straight to a Python class (i.e. snake) and do the same thing with the stomach (append, maybe pop from). Typically I'll do an eat method and then show how __call__ might be substituted for eat( ) or even made a synonym. The idea being these creatures have __ribs__ being vertebrates, and ribs connote a spinal cord, which is the seat of reflex reactions i.e. verb actions, responses to stimuli (being called in various ways). Snakes have lots of ribs. A mnemonic, but one not widespread in the literature (better for me that way? -- I stand out). The idea being: thinking in terms of objects was meant to meet you halfway. Think of the types of objects you know from being alive. Know any dogs? The term "object oriented" is not meant to be mysterious. It shares a lot with English grammar i.e. noun.verb(args). The parens look like a mouth turned sideways and they "eat" arguments (if any are provided). Typically humans have more experience with dogs than with programming languages by their teen years, though not always. Lets help you think about Python in terms you already understand, given you're a Person inheriting design attributes of Mammals (or more generally an Animal) in the process. So, did I learn this Pythonic Andragogy from actual practicing computer programmers who've devoted their whole lives to being good at programming (I was pretty good -- made a decent living)? They're not my principal audience. How about computer scientists? Nope, they already know this stuff. My audience is more "English speakers" although I presume the stuff readily translates. They may not wish to become coders, ever (but since when did life obey mere wishes?). I was a philosophy major myself although at Princeton we looked down on the word "major" for some reason. After we have a Dog, Snake and Cat class, I tend to hoist the eat and even birth methods (__init__) to an Animal superclass, leaving these now subclasses of Animal to __repr__ themselves, and do things specific to their species, such as bark or meow. __repr__ could be written more generally though, making use of type(self).__name__ for like "Dog('rover')" output, even from Animal. See: https://github.com/4dsolutions/DigitalMathematics/blob/master/grok_python.py Wait, am I saying that Dog's have a self? Ah, now we're starting to think more analogically, like English majors. Excellent. I might substitute the word 'me' for self, or a Chinese character for 'ego' (showing off Unicode) -- see Replit for examples. As long as we're consistent; self is a placeholder, not a keyword. But the pros always-only say "self" just so you know.
The industry has a phrase, to do with using our own software creations: "eating our own dog-food". Ghastly! Maybe? That's about the closest most of us will ever come to programming dogs!
My daughter pined for a SONY Aibo when growing up. She downloaded and read the instruction manual at age 13. But dang that thing was expensive. Maybe if I'd got her one she'd be doing more Python and less Matlab today? I also talk about special (magic) names being like where you attach puppet strings, like with marionettes. You know: how we tie strings to: elbows, knees, chin, wrists... Python is like that: a puppet-building kit. Objects are like that: puppets we control not with strings but through "remotes" (i.e. the names themselves, remote.buttons(), GUI widgets etc.). Names are in namespaces. Objectspace (actual objects in memory) don't even know their own names, assigned at runtime, just how many references are out there in case it's time to be garbage collected. Kirby
-- Regards =dn