On Mon, 7 Feb 2022 at 15:17, Christopher Barker <python...@gmail.com> wrote:
> Using Chris's example:
>
>> for {codec_type, width, height} in info["streams"]:
>> if codec_type == "video":
>> ...
>> This would be extremely convenient, and it doesn't really work with
>> dataclasses.
>
>
> First, how does this work now? This?
>
> for stream in info["streams"]:
> if stream['codec_type'] == "video":
> ....
>
> Is that so bad? as you have hard_coded codec_type, I suppose it's a bit more
> kludgy, but if the codec_type was in a variable, it would be more convenient.
>
Yes, and it's not hugely terrible, which is why I'm not pushing hard
for this sort of unpacking. (To be honest, I don't use it much in JS
either.)
> As for dataclasses, this is what i mean by "code" vs "data" -- if you know
> when you are writing the code exactly what key (fields, etc) you expect , and
> you want to be able to work with that data model as code (e.g. attribute
> access, maybe some methods, then you do:
>
>
> In [10]: @dataclass
> ...: class Stream:
> ...: codec_type : str
> ...: width: int
> ...: height: int
>
> And if you have that data in a dict (say, from JSON, then you can extract it
> like this:
>
> In [11]: stream_info = {'codec_type': 'video',
> ...: 'width': 1024,
> ...: 'height': 768,
> ...: }
>
> In [12]: stream = Stream(**stream_info)
>
> In [13]: stream
> Out[13]: Stream(codec_type='video', width=1024, height=768)
>
> That only works if you dict is in exactly the right form, but that would be
> the case anyway.
One very *very* important aspect of a huge number of JSON-based
protocols is that they absolutely will not break if new elements are
added. In other words, I look at the things I'm interested in, but
those streams also have a ton of other information (frame rate,
metadata, pixel format), which could get augmented at any time, and I
should just happily ignore the parts I'm not looking for. Making that
work with dataclasses (a) is even more boilerplate, and (b) would
obscure the relationship between the dataclass and the JSON schema.
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".
> Granted, that's a lot of code for a quickscript, but if it's a quick script,
> just work with the dict.
>
Which is exactly the OP's view. Work with the dict. But preferably,
make it easier to work with the dict.
> IN practice, it's not so simple when you have a more nested data structure,
> but I don't think this proposal would help with that, and it's not hard to
> build that on top of dataclasses either, see Pydantic, or attrs, or my own
> half-baked flexi project:
>
> https://github.com/PythonCHB/flexi
>
> (note: half-baked because the public project is not well tested nor
> documented, but I am using this very code in a pretty substantial system with
> a very highly nested structure:
>
> https://adios.orr.noaa.gov
>
> (and the code: https://github.com/NOAA-ORR-ERD/adios_oil_database)
>
If your data structure is incredibly rigid, you can take advantage of
sequence unpacking, and it'll work really nicely:
for x, y, z in data["points_3d"]: ...
IMO it's not unreasonable to want the same kind of flexibility for
named data. The trouble is, it would end up quite complicated, which
inevitably means we're going to come back to match/case syntax.
There have been thoughts thrown around in the past of having a "match
assignment" concept. The OP is far from the first to notice the
parallel. Maybe that's what we should be looking at - but the biggest
question is syntax. What should it look like?
# A different type of assignment operator?
{codec_type, width, height} $= info["streams"]
# A special assignment target?
match {codec_type, width, height} = info["streams"]
# A special assignment source?
{codec_type, width, height = match info["streams"]
# Something else?
I'm not a fan of any of these, but maybe someone can figure out a
better way to write it. It's one of those things where, if it existed
in the language, I would certainly use it, but it's not something that
causes all that much pain.
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/QY5U5X7WVXGMGHPXMW2FIK52RH7MULOM/
Code of Conduct: http://python.org/psf/codeofconduct/
