On Mon, 7 Feb 2022 at 17:35, Christopher Barker <python...@gmail.com> wrote:
> After I posted, I realized that dataclasses are probably not the simplest
> solution -- but SimpleNamespace could be:
>
> In [9]: stream_info = {'codec_type': 'video',
> ...: 'width': 1024,
> ...: 'height': 768,
> ...: }
>
> In [10]: stream = types.SimpleNamespace(**stream_info)
>
> In [11]: stream.codec_type
> Out[11]: 'video'
>
> In [12]: stream.height
> Out[12]: 768
>
> In [13]: stream.width
> Out[13]: 1024
>
> In any case, if you don't like how dataclasses or SimpleNamespace does it,
> then write you own custom class / converter -- I don't see the need for it to
> be a language feature.
This doesn't really buy much. (You say in your footnote that
stream.width is nicer than stream["width"], and you're absolutely
right, but it's still not as convenient as unpacking.) This is
particularly notable when you're unpacking something deep in the
structure, and you might have something like:
{width, height} = info["streams"][0]["panel"][1] # hypothetical example
which means you either have to create a variable and then still repeat
that everywhere, or repeat the long part.
Honestly, neither dataclasses nor SimpleNamespace buy enough over
direct dict access (with some strategic variable assignments) to be
worth the hassle. Which basically means we're back at status quo: it's
easy to unpack rigid, inflexible structures, and hard to unpack named
ones that have room for augmentation. Which seems a little backwards.
>> I'm not sure what you mean here about code vs data. What is the
>> difference that you're drawing? Ultimately, I need to read a
>> particular data structure and find the interesting parts of it. It's
>> not about code. The only code is "iterate over info->streams, look at
>> the codec_type, width, height, perform arithmetic on videos".
>
>
> The distinction I'm trying to draw (and I did say it was a fuzzy one in
> Python) is that data are things you can store in variables -- e.g. the keys
> of a dict can be hard coded (known at code-writing time) or stored in a
> variable.
>
> Code is things like variable and attribute names that have to known at
> code-writing time (baring metaprogramming techniques, get/setattr, etc).
>
I think I see what you mean, but yeah, it's a very very fuzzy
distinction. For instance, let's say it's not a JSON file, but
something in some other format (a Europa Universalis IV savefile,
perhaps). I could write a parser that steps byte-by-byte through the
file and builds a dict out of it; or I could reach for yacc and define
a full grammar, just like a programming language does. (Case in point:
I actually did design a recursive grammar for an EU4 savefile,
although not in Python, since Python doesn't have convenient grammar
tools available. This might change in the future, which would be very
convenient.)
This actually reminds me of some of the discussions regarding what
ended up becoming f-strings. You have the same "dict or variable?"
consideration, but the other way around:
def spam():
bird = "Norwegian Blue"
volts = 4e6
return "{volts}V insufficient to voom {bird}".format(**locals())
Python gives us some tools for switching viewpoints between "this is
data" and "this is code", and your parenthetical comment about
metaprogramming actually fits into that too (and believe you me, it
hurts when I'm stuck in a language without it!).
> In this case, we are looking to auto-extract variable from a dict -- you
> can't even start to write that code unless you know what the keys in the dict
> are -- if that's the case, then you know (at least part of) the schema, and
> you can use dataclasses, etc, and get your code.
>
Yeah, but why write a dataclass and then write the code, instead of
just writing the code? There are exceptions, of course; if you're
parsing something that simply doesn't *have* all the information, and
you have to go "take four bytes, that's an integer called Volts, take
bytes until you get a \0, that's an ASCII string called Bird, take
four bytes, we don't know what they are", then it makes perfect sense
to make a dataclass (again, have done this); but when the file can be
parsed without any external references, I'd rather do that, and stay
generic.
> So: I say, keep your data in dicts, and if you want to load a code object
> with that data, do it in a clearly defined way.
>
Exactly what the OP wanted, except instead of loading *a* code object,
loading *several* code objects at once, to avoid the repetition. :)
ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GI52OQJZ2FCPQQBWYS7FCHAN2ZCMCOPV/
Code of Conduct: http://python.org/psf/codeofconduct/
