It's an absolutely terrible idea and I'm thankful that there's so little chance it'll ever happen. I don't want random objects to become mappings, nor do I want mapping entries and their attributes to conflict. Javascript is a bad language and this is one of its worst features.
> Something even crazier would be to have an equivalent of `console.log` in python. It would be an amazing feature but I think I'm the only one wanting it. I know I can use `print` or different logger. But it's a lot more complicated to use and the output is a lot less navigable than in javascript.
You... can just call `logging.whatever()`, after having called `logging.basicConfig()` to set up your basic config?
I fail to see how that would change anything to navigability. `console.log` is not inherently navigable, it's the browser's console UI which provides some navigability.
There's not one perfect format to rule them all but the "=" "self-documenting" debug format such as `f"{some_obj=}"` probably gives you a good starting point for what you are looking for most of the time. Sometimes you still want the `str()` or `repr()` representation specifically and would want something like `f"{some_obj=!s}"` or `f"{some_obj=!r}"` respectively. In some cases objects you want pretty-printed to a console might have custom `__format__()` representations as well and it might be something like `f"{some_obj=:some-custom-format}"`.
It's obviously all still differently useful than JS having a full object browser embedded in most common consoles today, but there is interesting power to explore in f-string formats if you need quick and dirty logs of object states.
https://docs.python.org/3/whatsnew/3.8.html#bpo-36817-whatsn...
Maybe pprint is for you:
from pprint import pprint
# usage, but can do more as well and has more config stuff if needed
pprint({'a':'b'})
https://docs.python.org/3/library/pprint.htmlAlthough it'd be nice if it worked with slotted classes instead of just blowing up.
Dataclasses have asdict which work on both, but it's annoying there's nothing for regular classes.
* For new languages: It's not generic enough since there is no equivalent of `x[t]` if t is of a non-string type. E.g. there is no way to express `x[(1,2,3)]` or `x[3]` or `x[frozenset({1, 2, "foo"})]` this way.
* For existing languages like Python: this would be a breaking change since things that can do `x.y` and `x[t]` are structurally different in Python so they're typed differently. One are called "mappings" and the other are "objects", they're completely different things. Hence, you'll get cases where `x["foo"] == 5` but `x.foo == 4` so this will for sure break some programs. Too much pain for no gain.
Don't you think it should not be possible to have such a thing ? To me it's so prone to error and there is absolutely too much gain to fix this.
No, having used lots of OO languages before JS and its “objects are dictionaries are arrays and member access and string indexing and integer indexing are all equivalent and can be used interchangeably, except you can't use member access where the key isn't a valid identifier” approach, which I find more confusing and error prone (though I’ve since had to use JS enough to be proficient in that, too.)
Indexing an object as an indexable collection and accessing a member (field, property, or method) of the object are fundamentally different things, and having a collection item with a particular string index isn’t the same thing as an object member with a similar identifier name.
This use of objects as also quasi-associative-arrays is so broken that JS’s actual associative-array type (Map) can’t use indexing notation because of it, and has to use .get() and .set() instead, unlike the associative array types of most other dynamic languages (and several statically-typed OO languages).
The JS way is less bad as a type-specific behavior (e.g., Ruby ActiveSupport’s HashWithIndifferentAccess), though.
No. They're different notations; one means `x.__getitem__('foo')` and the other means `x.__getattribute__('foo')`. Why should they be the same? If we assume that the dict class was enhanced with your proposed equivalence, would you want `d['items']` to be the function `d.items`? Would that not make 'items' a forbidden key?
By the way, there is a vulnerability (Prototype Pollution) that is only possible due to this behaviour in JS: https://portswigger.net/web-security/prototype-pollution
x = {"users": [12,21,54], "items": [1,2,3]} # group owned items
>>> x["items"]
[1,2,3]
>>> x.items
<built-in method items of dict object at 0x00>Most languages that have both objects and associative arrays (so not Lua or JavaScript) make this distinction.
It's not particularly error prone. You're simply refusing ("don't care why") to learn how to use the tool you're given.
user instance from a django model => user.email
It is error prone. You're simply refusing to see an aberration.
That's how the language works, but it doesn't mean it's intuitive and easy to understand especially for a language known for being easy to use and understand.
When all you have is a hash table, or when all you have is an object, you get to refer to keys and properties uniformly - because they are the same thing. When you have both, you refer to them differently - because they're different. That's it. There are some languages where objects and hash tables use the same syntax for access even though they're different things, but... you probably never used any of them, and certainly none of them is in the Top 20 on TIOBE.
I'll kick the venerable HN guidelines aside for a second and mention this: you're being heavily downvoted, all your comments in this thread are in various shades of gray, and many people offer many different arguments as to why you're wrong. Yet, you're undaunted and continue posting - I don't want to break the guidelines that much, but honestly, it reads like trolling. You don't engage with the arguments, you're just repeating the same thesis over and over again, without citing evidence. Why?
1. Write a class with custom __getitem__ and __getattr__ methods
2. Use a template system like Django or Jinja that implements this in certain situations
3. Use a library like https://pypi.org/project/python-box/
"There should be one-- and preferably only one --obvious way to do it." (zen of python)
I do agree that python logging is a weak point. It is too easy to do it wrong -- particularly when you are a few modules deep.
> "There should be one-- and preferably only one --obvious way to do it." (zen of python)
Look at all the other possibilities to do `f"hello {name}`. That are more than one obvious way to do it.
Something even crazier would be to have an equivalent of `console.log` in python. It would be an amazing feature but I think I'm the only one wanting it. I know I can use `print` or different logger. But it's a lot more complicated to use and the output is a lot less navigable than in javascript. PHP also has `var_dump`. But we don't have any equivalent in python.