5 ms·
Who is out here mixing types in a list anyway?
by bpshaver 2y ago
Who is out here mixing types in a list anyway?
- orf 2y agoIt’s common to have a list of objects with different types, but which implement the same interface. Duck typing of this kind is core to Python.
- bpshaver 2y agoGood point.
- CaptainNegative 2y agoI often find myself mixing Nones into lists containing built-in types when the former would indicate some kind of error. I could wrap them all into a nullable-style type, but why shouldn't the interpreter implicitly handle that for me?
- bpshaver 2y agoYeah, that seems fair.
- nicce 2y agoEveryone who chooses the Python in the first hand.
- bpshaver 2y agoWell, I'm one of those people, and I feel that I rarely do this. Except if I have a list of different objects that implement the same interface, as another commenter mentioned.
- itishappy 2y agoThe json module returns heterogenous dicts. https://docs.python.org/3/library/json.html https://docs.python.org/3/library/json.html
- bpshaver 2y agoYeah, just because it can do that doesn't mean that it is good design.
- gpderetta 2y agohow would you represent an arbitrary JSON array in python then? A potentially heterogeneous list seems the obvious solution.
- bpshaver 2y agoWhy would I want to do that? I'm rarely ingesting arbitrary JSON. Rather I'm designing my data structures in a sensible way and then maybe serializing them to JSON. Just because JSON can represent heterogenous lists doesn't mean it is a good idea to use heterogenous lists in my programs.
- gpderetta 2y agoThe JSON spec does not require a schema. If you want to write a library that can support any valid JSON you have little options. That's useful if you are implementing something like jq just to give an example.
- gwking 2y agoIt is the design of JSON! Which is a reflection of the same dynamic typing choice made in the original design of Javascript.
- mrguyorama 2y agoThey, uh, still aren't wrong hah. Tell me again why we somehow standardized on sending the equivalent of JSObject.toString() for everything? Especially when "standardized" isn't
- dathinab 2y agoparsing json is roughly of the type: type Json = None | bool | float | str | dict[str, Json] | list[Json] you might have similar situations for configs e.g. float | str for time in seconds or a human readable time string like "30s" etc. given how fundamental such things are I'm not sure if there will be any larger projects (especially wrt. web servers and similar) which are compatible with this also many commonly used features for libraries/classes etc. are not very likely to work (but idk. for sure, they just are very dynamic in nature) so IMHO this seems to be more like a python-like language you can use for idk. some since computations and similar then a general purpose faster python
- bpshaver 2y agoAgreed, I was just joking. I understand heterogenous lists are possible with Python, but with the use of static type checking I feel like its pretty rare for me to have heterogenous lists unless its duck typing.
- JonChesterfield 2y agoIf your language obstructs heterogeneous lists your programs will tend to lack them. Look for classes containing multiple hashtables from the same strings to different object types as a hint that they're missed. Whether that's a feature is hard to say. Your language stopped you thinking in those terms, and stopped your colleagues from doing so. Did it force clarity of thought or awkward contortions in the implementation? Tends to depend on the domain.
- bobbylarrybobby 2y agoHeterogeneity is easily achieved in statically typed languages via sum types.
- RogerL 2y agoreturn [key, value]
- ghxst 2y agoWhy would you do this over `return key, value` which produces a tuple? Just curious.
- dgan 2y agoNot the parent, but i return heterogeneous lists of the same length to the excel to be used by xlwings. The first row being the headers, but every row below is obviously heterogeneous
- 0xDEADFED5 2y agojavascript refugee?
- slightwinder 2y agoTo quote the Zen of Python: Explicit is better than implicit. Readability counts.
- ErikBjare 2y agoHow does that apply in this case?
- slightwinder 2y ago"return key, value" is implicit. While "return [key, value]" is explicitly telling the full return-value. And it's (for me) more readable than "return (key, value)".
- Nab443 2y agoI don't see how "return (key, value)" is less readable than it's list counterpart. Now, why using a list that can grow, and so takes more space and maybe less efficient, for something that should not?
- __mharrison__ 2y agoSomeone who is using Python the wrong way.
- dekhn 2y agoI've been mixing types in Python lists for several decades now. Why wouldn't you? it's a list of PyObjects.
- gwking 2y agoAn example related to JSON content is HTML content. I have a Python library that represents all of the standard HTML tags as a family of classes. It is like a lightweight DOM on the server side, and has resulted in a web server that does not use string based templating at all. It lets me construct trees of HTML completely in Python and then render them out with everything correctly escaped. I can also parse HTML into trees and manipulate them as I please (for e.g. scraping tasks and document transforms). It is all strongly typed using mypy and I adhere to the strictest generic typing I can manage. Each node has a list of children, and the element type is `str|HtmlNode`. I find this vastly easier to use than the LXML ETree api, where nodes have `text` and `tail` attributes to represent interleaved text. Interestingly, the LXML docs promote their design as follows: > he two properties .text and .tail are enough to represent any text content in an XML document. This way, the ElementTree API does not require any special text nodes in addition to the Element class, that tend to get in the way fairly often (as you might know from classic DOM APIs). https://lxml.de/tutorial.html#elements-contain-text https://lxml.de/tutorial.html#elements-contain-text It could be a simple matter of taste! But I suspect that the difference between what they are describing as "classic DOM" vs what I am doing is that they are referring to experience with C/C++/Java libraries circa 2009 that had much less convenient dynamic type introspection. The "get in the way fairly often" reminds me of how verbose it is to deal with heterogenous data in C/C++/ObjC. In ObjC for example, you could have an array mixing NSString with other NSObject subclasses, but you had to do work to type it correctly. If you wanted numbers in there you had to use NSNumber which is an annoying box type that you never otherwise use. And ObjC was considered very dynamic in its day! I have long felt that the root of much evil was the overbearing distinction between primitive and object types in C++/Java/Objective-C. All of this is a long way of saying, I think "how to deal with heterogenous lists of stuff" is a huge question in language design, library design, and the daily work of programming. Modern languages have by no means converged on a single way to represent varying types of elements. If you want to create trees of stuff, at some level that is "mixing types in a list" no matter how you might try to encode it. Just food for thought!