<p>After playing around Python a little bit, I feel like Python does not encourage us to read objects's content. Take JavaScript for example: just a simple act of calling an object will list all the content of it, while in Python if an attribute is also an object, it doesn't write down that sub-object. I have to call that attribute explicitly for it to show up. If the attribute is an array of objects, it will only display the first attribute of each object in the array, not list them all.</p>
<p>Example:</p>
<pre class="lang-python prettyprint-override"><code>vars(allnotes.notes[0])
{'path': WindowsPath('D:/Programming/test zone/example-vault/README.md'),
 'content': 'blabla',
 'metadata': &lt;pyomd.metadata.NoteMetadata at 0x1b559874350&gt;}

vars(allnotes.notes[0].metadata)
{'frontmatter': &lt;class 'pyomd.metadata.Frontmatter'&gt;:
 - dg_publish: True,
 'inline': &lt;class 'pyomd.metadata.InlineMetadata'&gt;:}

vars(allnotes.notes[0].metadata.inline)
{'metadata': {}}
</code></pre>
<p>I was advised to not use <code>vars()</code> or <code>__dict__</code>, just use the actual API of the classes. If an object isn't printing well without that introspection, then that's the devs fault for not writing proper string and print methods (usually via <code>__repr__</code>). Or in other words, Python defers the responsibility to display the objects to the dev, while JS takes that responsibility.</p>
<p>Are those claims correct? How do the philosophies of Python take the authors to those decisions? Why do the two languages apply different levels of encapsulation for reading data?</p>

<object-oriented><python><javascript>
Is it correct that Python does not encourage us to read objects's content?
CC BY-SA 4.0
2023-09-27T11:43:05.620Z
Hi! It's actually pretty hard to understand what you're asking. *Variables* in python are conceptually different from variables in most other programming languages, but I don't know if I would say that *objects* are different. One of the core concepts of object-oriented programming is encapsulation, so it makes sense not to list every attribute of every object all the time - that's not specific to python. As for "javascript objects are more like python dictionaries", I don't know what to answer, because python objects actually do contain a python dictionary of their own attributes.
Stef
CC BY-SA 4.0
2023-09-27T11:53:17.040Z
After reading more about dictionary vs object, I finally understand the difference. I agree with you that it's not completely correct. I also see that it's not really necessary to the question so I remove that part. As for encapsulation, the question then can be framed as "why do the two languages apply different levels of encapsulation for reading data?" Is it clearer?
Ooker
CC BY-SA 4.0
2023-09-27T11:55:57.270Z
Whomever you talked to doesn't seem to have the first clue about Javascript. Javascript is arguably *more* object oriented than Python: Python for instance has no concept of object literals. Javascript also has getters, setters, private properties, non-enumerable properties, readonly properties, etc for encapsulating object state. All the stuff that person said about Python though seems to be dead on: if you have to use vars or \_\_dict\_\_ the class wasn't very well-designed. I'm not sure how this all ties into the actual programming language design though?
Jared Smith
CC BY-SA 4.0
2023-09-27T12:01:28.877Z
@Ooker okay post edit and reading your comment: my earlier comment still stands: Javascript has the ability to do basically all the same stuff, and the person you talked to clearly didn't know what they were talking about. So I'm having a hard time understanding what remains of the question? To be totally fair, Javascript got most of that stuff 10-20 years into its lifespan, where Python had it much earlier in its respective lifecycle.
Jared Smith
CC BY-SA 4.0
2023-09-27T13:39:15.497Z
‘just a simple act of calling an object will list all the content of it’ — what do you mean? `(new Object)()` throws a `TypeError`.
user3840170
CC BY-SA 4.0
2023-09-27T14:04:22.070Z
@user3840170 I mean `console.log(object)`
Ooker
CC BY-SA 4.0
2023-09-27T17:30:43.537Z
JS doesn't "take that responsibility", rather the implementation does. There is nothing in the language spec which says a JS REPL must show an object's contents. There is also nothing in the Python language spec which says that `repr` (or an object's `__repr__` method) *must* be called by a Python REPL, and indeed there are Python REPLs such as [Jupyter](https://jupyter.org/) which even render some objects as interactive applets, not just the text result of `repr`. So this is really a question about tooling and it has very little to do with the language design or philosophy.
kaya3
CC BY-SA 4.0
2023-09-27T17:53:35.990Z
I think this question remains quite unclear about what it is asking. All JavaScript objects stringify to “[object Object]” by default, and even post-edit both languages have essentially *the same* levels of encapsulation, but it’s not clear just what “calling an object” is standing in for, and it’s hard to tell which parts of language design in these cases are relevant. I think there is a good on-topic question inside here that dials in on just one element of all of this (perhaps multiple!), but this one is still a bit scattershot and rests on the unconnected bloviations of some guy in Discord
Michael Homer
CC BY-SA 4.0
2023-09-27T23:58:02.107Z
@MichaelHomer I think they're talking about the difference between `print(someObject)` in Python and `console.log(someObject)` in JS. Python just prints something like `<className address>` by default, while JS shows the full object contents. The problem is that their analogy is wrong. "Plain" JS objects are more like Python dictionaries, which do display all the contents.
Barmar
CC BY-SA 4.0
2023-09-28T21:06:39.570Z
@Barmar probably also worth noting (as I did in the last edit to my answer) that unlike the behavior of `print` in the reference implementation of Python which is pretty clearly specified, the behavior of `console.log` is implementation dependent. It can do anything at all, including showing properties you can't actually access in Javascript.
Jared Smith
CC BY-SA 4.0
2023-09-28T21:10:46.150Z
@JaredSmith True. The console in browsers is part of the debugger. Python IDEs have allow you to view details of objects in the debuggers.
Barmar
<h2>TL;DR</h2>
<p>Javascript was not at first intended to be a general purpose programming language, Python was.</p>
<h2>Longer Answer</h2>
<p>Javascript was developed in 1995 to add small amounts of behavior to web pages that at the time were almost entirely static documents. Pages with no JS were common, pages with a couple of inline scripts &lt; 20 lines were about it. As Eric Lippert, a user here who worked on the Microsoft implementation has said it was just there to <a href="https://security.stackexchange.com/questions/181580/why-is-math-random-not-designed-to-be-cryptographically-secure/181623#181623">&quot;make the monkey dance when you move the mouse&quot;</a>.</p>
<p>So until about 15-20 years ago Javascript worked pretty much the way your conversation partner said: what's that? You want encapsulation of object internals in your &lt; 100 LoC JS? Why?</p>
<p>But then a funny thing happened, people started using it more and more, and for ever more ambitious purposes. Then Microsoft invented the XmlHttpRequest object (2001) that allowed pages to communicate with the server in the background, and the world was never the same. By about 2005 it was available in most major browsers, and we had apps like gmail to show just what was possible with it.</p>
<p>Well, once people started writing real programs with Javascript, it became clear pretty quickly oh wait, we <em>do</em> actually need proper language features like private properties, encapsulation of internals, etc.</p>
<p>So people added them. Either in an ad hoc fashion (e.g. using closures for encapsulation), or increasingly to the language itself. Javascript has arguably had feature parity with the things that your conversation partner mentioned about Python since about 2015 (note that's almost 10 years now). So that person's information about JS is quite a bit out of date.</p>
<p>But in terms of language design, the designer(s) of Javascript didn't include those features earlier on because why bother, but once it was clear those features were necessary they added them for the same reasons Python has them.</p>
<h2>But I see stuff when I console.log!!!</h2>
<p>Yeah, about that. You see, the behavior of the console here is explicitly <a href="https://console.spec.whatwg.org/#logger" rel="nofollow noreferrer">implementation-defined in the standard</a>. So <code>console.log</code> is pure magic: it need not be bound by the semantics of Javascript and can and does sometimes expose internals like <a href="https://262.ecma-international.org/13.0/#sec-object-internal-methods-and-internal-slots" rel="nofollow noreferrer"><code>[[Call]]</code> or <code>[[Construct]]</code></a> that are not actually exposed to the Javascript programmer <em>at all</em>. So don't be surprised if you <em>see</em> private properties or the entire prototype chain or even inaccessible internals when you <code>console.log</code> an object.</p>
<p>Contrast this with the <a href="https://docs.python.org/3/library/functions.html#print" rel="nofollow noreferrer">behavior of <code>print</code></a> in the reference implementation of Python: it very clearly spells out that objects get run through the <code>str</code> function which <a href="https://docs.python.org/3/library/stdtypes.html#str" rel="nofollow noreferrer">calls the object's <code>__str__</code> magic method if present</a> and <a href="https://docs.python.org/3/library/functions.html#repr" rel="nofollow noreferrer">delegates to <code>repr</code></a> if one is not found.</p>
<p>However it's worth noting here that Python (as far as I know) does not actually have a formal standard, and the behavior of the CPython reference implementation is not binding on alternative implementations, although I've never used it I would not be at all surprised if e.g. Jython did something quite different.</p>

CC BY-SA 4.0
2023-09-27T12:12:58.613Z
2023-09-27T19:48:17.570Z
2023-09-27T19:48:17.570Z
Jared Smith
CC BY-SA 4.0
2023-09-27T12:27:25.810Z
so is it correct to say that it's not Python who does not encourage us to read objects' content, but it's JS who didn't bother to apply the standard of encapsulation at the first place? If so, then why does that standard become standard? It's likely that I'm wrong, but in my understanding as long as I can get the data of the sub-objects they are not really hidden to me. The language only discourages me to read it, but doesn't actually hide them. Also, if JS has caught up the standard, then why I can still read the data easily?
Ooker
CC BY-SA 4.0
2023-09-27T12:33:41.883Z
@Ooker "as long as I can get the data of the sub-objects they are not really hidden to me" modern JS is better at this than Python: JS has true private properties prefixed with `#` whereas `obj._ClassName__property` will still let you get at `obj`'s "private" `__property` in Python. So the correct formulation is "Python *discourages* reading private data, Javascript *disallows* it". "If JS has caught up the standard, then why I can still read the data easily" because you wrote it that way? If you use a private property with `#` then you can't read it at all, full-stop.
Jared Smith
CC BY-SA 4.0
2023-09-27T12:37:52.317Z
See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields
Jared Smith
CC BY-SA 4.0
2023-09-27T12:42:06.687Z
And just to be clear, I'm not trying to bash Python here, it's a solid language and IMO a *better* one over all than JS (which doesn't even have a standard library in Year of Our Lord 2023 because reasons). But whoever you were talking to was clearly just parroting some nonsense JS hate likely out of overzealous techno-religiosity.
Jared Smith
CC BY-SA 4.0
2023-09-27T14:33:22.783Z
hmm I mean in the case of using only public methods, then it's still not convenient to read the whole object content via `vars(object)`. You can get only 1st-level data. For sub-objects you have to specify them. Where as with `console.log()` you see all of them at once. Why is that? Since we are concerning only with public methods, I assume encapsulation doesn't play a role here. Is that correct?
Ooker
CC BY-SA 4.0
2023-09-27T14:55:32.440Z
@Ooker the behavior of `console.log` is actually [implementation dependent](https://console.spec.whatwg.org/#logger). So console.log can actually show you private properties (even though you can't access them) and even attributes defined by the spec but not accessible in JS at all. It's not constrained by the language at all. So it's *fundamentally* different from `vars` in Python. We've kinda wandered a bit from questions of language design at this point.
Jared Smith
CC BY-SA 4.0
2023-10-17T23:32:08.073Z
@JaredSmith: You say "However it's worth noting here that Python (as far as I know) does not actually have a formal standard". It has a formal standard, it's what you get on [the language docs](https://docs.python.org/3/index.html) (specifically the Language Reference and Library Reference). It does *mix* with the CPython reference interpreter's documentation, with things specific to CPython called out as implementation notes, but PyPy, Jython, IronPython, etc. are all following those reference documents as an implementation guide.
ShadowRanger
# Is it correct that Python does not encourage us to read objects's content?
Posted by: username_0 on 2023-09-27
After playing around Python a little bit, I feel like Python does not encourage us to read objects's content. Take JavaScript for example: just a simple act of calling an object will list all the content of it, while in Python if an attribute is also an object, it doesn't write down that sub-object. I have to call that attribute explicitly for it to show up. If the attribute is an array of objects, it will only display the first attribute of each object in the array, not list them all.
Example:
vars(allnotes.notes[0])
{'path': WindowsPath('D:/Programming/test zone/example-vault/README.md'),
 'content': 'blabla',
 'metadata': }

vars(allnotes.notes[0].metadata)
{'frontmatter': :
 - dg_publish: True,
 'inline': :}

vars(allnotes.notes[0].metadata.inline)
{'metadata': {}}

I was advised to not use vars() or __dict__, just use the actual API of the classes. If an object isn't printing well without that introspection, then that's the devs fault for not writing proper string and print methods (usually via __repr__). Or in other words, Python defers the responsibility to display the objects to the dev, while JS takes that responsibility.
Are those claims correct? How do the philosophies of Python take the authors to those decisions? Why do the two languages apply different levels of encapsulation for reading data?
**Tags:** object-oriented python javascript
> **Comments:**
> **username_1**: Hi! It's actually pretty hard to understand what you're asking. *Variables* in python are conceptually different from variables in most other programming languages, but I don't know if I would say that *objects* are different. One of the core concepts of object-oriented programming is encapsulation, so it makes sense not to list every attribute of every object all the time - that's not specific to python. As for "javascript objects are more like python dictionaries", I don't know what to answer, because python objects actually do contain a python dictionary of their own attributes.  
> **username_0**: After reading more about dictionary vs object, I finally understand the difference. I agree with you that it's not completely correct. I also see that it's not really necessary to the question so I remove that part. As for encapsulation, the question then can be framed as "why do the two languages apply different levels of encapsulation for reading data?" Is it clearer?  
> **username_2**: Whomever you talked to doesn't seem to have the first clue about Javascript. Javascript is arguably *more* object oriented than Python: Python for instance has no concept of object literals. Javascript also has getters, setters, private properties, non-enumerable properties, readonly properties, etc for encapsulating object state. All the stuff that person said about Python though seems to be dead on: if you have to use vars or \_\_dict\_\_ the class wasn't very well-designed. I'm not sure how this all ties into the actual programming language design though?  
> **username_2**: @Ooker okay post edit and reading your comment: my earlier comment still stands: Javascript has the ability to do basically all the same stuff, and the person you talked to clearly didn't know what they were talking about. So I'm having a hard time understanding what remains of the question? To be totally fair, Javascript got most of that stuff 10-20 years into its lifespan, where Python had it much earlier in its respective lifecycle.  
> **username_3**: ‘just a simple act of calling an object will list all the content of it’ — what do you mean? `(new Object)()` throws a `TypeError`.  
> **username_0**: @user3840170 I mean `console.log(object)`  
> **username_4**: JS doesn't "take that responsibility", rather the implementation does. There is nothing in the language spec which says a JS REPL must show an object's contents. There is also nothing in the Python language spec which says that `repr` (or an object's `__repr__` method) *must* be called by a Python REPL, and indeed there are Python REPLs such as [Jupyter](https://jupyter.org/) which even render some objects as interactive applets, not just the text result of `repr`. So this is really a question about tooling and it has very little to do with the language design or philosophy.  
> **username_5**: I think this question remains quite unclear about what it is asking. All JavaScript objects stringify to “[object Object]” by default, and even post-edit both languages have essentially *the same* levels of encapsulation, but it’s not clear just what “calling an object” is standing in for, and it’s hard to tell which parts of language design in these cases are relevant. I think there is a good on-topic question inside here that dials in on just one element of all of this (perhaps multiple!), but this one is still a bit scattershot and rests on the unconnected bloviations of some guy in Discord  
> **username_6**: @MichaelHomer I think they're talking about the difference between `print(someObject)` in Python and `console.log(someObject)` in JS. Python just prints something like `<className address>` by default, while JS shows the full object contents. The problem is that their analogy is wrong. "Plain" JS objects are more like Python dictionaries, which do display all the contents.  
> **username_2**: @Barmar probably also worth noting (as I did in the last edit to my answer) that unlike the behavior of `print` in the reference implementation of Python which is pretty clearly specified, the behavior of `console.log` is implementation dependent. It can do anything at all, including showing properties you can't actually access in Javascript.  
> **username_6**: @JaredSmith True. The console in browsers is part of the debugger. Python IDEs have allow you to view details of objects in the debuggers.  
---
## 1 answers
### Answer by username_2 on 2023-09-27. Score: 5 | Accepted answer
## TL;DR

Javascript was not at first intended to be a general purpose programming language, Python was.

## Longer Answer

Javascript was developed in 1995 to add small amounts of behavior to web pages that at the time were almost entirely static documents. Pages with no JS were common, pages with a couple of inline scripts < 20 lines were about it. As Eric Lippert, a user here who worked on the Microsoft implementation has said it was just there to ["make the monkey dance when you move the mouse"](https://security.stackexchange.com/questions/181580/why-is-math-random-not-designed-to-be-cryptographically-secure/181623#181623).

So until about 15-20 years ago Javascript worked pretty much the way your conversation partner said: what's that? You want encapsulation of object internals in your < 100 LoC JS? Why?

But then a funny thing happened, people started using it more and more, and for ever more ambitious purposes. Then Microsoft invented the XmlHttpRequest object (2001) that allowed pages to communicate with the server in the background, and the world was never the same. By about 2005 it was available in most major browsers, and we had apps like gmail to show just what was possible with it.

Well, once people started writing real programs with Javascript, it became clear pretty quickly oh wait, we *do* actually need proper language features like private properties, encapsulation of internals, etc.

So people added them. Either in an ad hoc fashion (e.g. using closures for encapsulation), or increasingly to the language itself. Javascript has arguably had feature parity with the things that your conversation partner mentioned about Python since about 2015 (note that's almost 10 years now). So that person's information about JS is quite a bit out of date.

But in terms of language design, the designer(s) of Javascript didn't include those features earlier on because why bother, but once it was clear those features were necessary they added them for the same reasons Python has them.

## But I see stuff when I console.log!!!

Yeah, about that. You see, the behavior of the console here is explicitly [implementation-defined in the standard](https://console.spec.whatwg.org/#logger). So `console.log` is pure magic: it need not be bound by the semantics of Javascript and can and does sometimes expose internals like [`[[Call]]` or `[[Construct]]`](https://262.ecma-international.org/13.0/#sec-object-internal-methods-and-internal-slots) that are not actually exposed to the Javascript programmer *at all*. So don't be surprised if you *see* private properties or the entire prototype chain or even inaccessible internals when you `console.log` an object.

Contrast this with the [behavior of `print`](https://docs.python.org/3/library/functions.html#print) in the reference implementation of Python: it very clearly spells out that objects get run through the `str` function which [calls the object's `__str__` magic method if present](https://docs.python.org/3/library/stdtypes.html#str) and [delegates to `repr`](https://docs.python.org/3/library/functions.html#repr) if one is not found.

However it's worth noting here that Python (as far as I know) does not actually have a formal standard, and the behavior of the CPython reference implementation is not binding on alternative implementations, although I've never used it I would not be at all surprised if e.g. Jython did something quite different.
> **Comments:**
> **username_0** (2023-09-27): so is it correct to say that it's not Python who does not encourage us to read objects' content, but it's JS who didn't bother to apply the standard of encapsulation at the first place? If so, then why does that standard become standard? It's likely that I'm wrong, but in my understanding as long as I can get the data of the sub-objects they are not really hidden to me. The language only discourages me to read it, but doesn't actually hide them. Also, if JS has caught up the standard, then why I can still read the data easily?  
> **username_2** (2023-09-27): @Ooker "as long as I can get the data of the sub-objects they are not really hidden to me" modern JS is better at this than Python: JS has true private properties prefixed with `#` whereas `obj._ClassName__property` will still let you get at `obj`'s "private" `__property` in Python. So the correct formulation is "Python *discourages* reading private data, Javascript *disallows* it". "If JS has caught up the standard, then why I can still read the data easily" because you wrote it that way? If you use a private property with `#` then you can't read it at all, full-stop.  
> **username_2** (2023-09-27): See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields  
> **username_2** (2023-09-27): And just to be clear, I'm not trying to bash Python here, it's a solid language and IMO a *better* one over all than JS (which doesn't even have a standard library in Year of Our Lord 2023 because reasons). But whoever you were talking to was clearly just parroting some nonsense JS hate likely out of overzealous techno-religiosity.  
> **username_0** (2023-09-27): hmm I mean in the case of using only public methods, then it's still not convenient to read the whole object content via `vars(object)`. You can get only 1st-level data. For sub-objects you have to specify them. Where as with `console.log()` you see all of them at once. Why is that? Since we are concerning only with public methods, I assume encapsulation doesn't play a role here. Is that correct?  
> **username_2** (2023-09-27): @Ooker the behavior of `console.log` is actually [implementation dependent](https://console.spec.whatwg.org/#logger). So console.log can actually show you private properties (even though you can't access them) and even attributes defined by the spec but not accessible in JS at all. It's not constrained by the language at all. So it's *fundamentally* different from `vars` in Python. We've kinda wandered a bit from questions of language design at this point.  
> **username_7** (2023-10-17): @JaredSmith: You say "However it's worth noting here that Python (as far as I know) does not actually have a formal standard". It has a formal standard, it's what you get on [the language docs](https://docs.python.org/3/index.html) (specifically the Language Reference and Library Reference). It does *mix* with the CPython reference interpreter's documentation, with things specific to CPython called out as implementation notes, but PyPy, Jython, IronPython, etc. are all following those reference documents as an implementation guide.  
---
