15:00:41 <sdoran> #startmeeting Ansible Core Public IRC Meeting https://github.com/ansible/community/issues/495
15:00:41 <zodbot> Meeting started Thu Oct  3 15:00:41 2019 UTC.
15:00:41 <zodbot> This meeting is logged and archived in a public location.
15:00:41 <zodbot> The chair is sdoran. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:41 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting_https://github.com/ansible/community/issues/495'
15:01:04 <sdoran> #topic https://github.com/ansible/ansible/pull/53488
15:01:27 <sdoran> cyberpear: What would you like to discuss on this PR?
15:06:00 * cyberpear waves
15:06:27 <cyberpear> wondering if we can resurrect it to enable using the dict() functionality as a filter
15:09:46 <cyberpear> that way it can be used in a "pipeline" without having to wrap the whole thing in a function syntax
15:10:43 <bcoca> it was rejected since dict() function exists in jinja2 .. we did add backwards compat for versions of jinja2 that didn't have it
15:10:59 <sdoran> This is just an interface change, not adding functionality.
15:11:01 <cyberpear> would make it possible to do `"{{ mykeys | zip(myvar) | dict }}"` instead of `"{{ dict(mykeys | zip(myvar)) }}"`
15:11:17 <jtanner> why is that better?
15:11:50 <bcoca> cyberpear: if you can convince those that voted against it, go ahead, idc either way, i do think its redundant so i wont vote for it
15:11:57 <cyberpear> when the "pipeline" gets long, it gets confusing with lots of extra params.  Left to right evaluation is easiest to read
15:12:16 <cyberpear> s/params/parens//
15:14:15 <cyberpear> would also allow use in a list comprehension, which doesn't work for me today
15:14:32 <cyberpear> if I try to map('dict'), I get `no filter named 'dict'`
15:15:21 <bcoca> even if accepted, i would push for name change to_dict to distinguish from dict() function
15:15:21 <cyberpear> `"{{ mykeyslists | map('zip', myvarslists) | map('dict') | list }}"` <- gives `no filter named 'dict'`
15:15:42 <jtanner> well, making a filter named the same as a python keyword seems fraught with peril ... it would need to be something like to_dict even if we did take it, imo
15:15:50 <cyberpear> to_dict is fine
15:16:24 <cyberpear> I can't see a way to make the above list comprehension example work with the existing built-in dict() function
15:16:51 <cyberpear> I want a list of dict, not just a dict
15:18:27 <sdoran> `dict2items` doesn't work?
15:19:31 <cyberpear> sdoran: no, that creates dicts with just 2 items
15:19:47 <bcoca> it kind of does but  key and value are the keys of the dict
15:20:03 <bcoca> not what most expect from dict()/to_dict
15:20:21 <jtanner> map is a pita, i typically replace the whole expression with a custom filter
15:20:49 <nitzmahone> I've run into needs for this too- so long as to_dict filter stays an extremely thin wrapper over dict() without a lot of "value add" I could probably be convinced to +1 it
15:21:06 <cyberpear> (map is built-in and doesn't require extra dependencies)
15:21:32 <bcoca> cyberpear: i think he jsut gets perl flashbacks with map()
15:22:17 <bcoca> feel free to use my closed PR (or not) if you want to implement to_dict
15:22:50 <bcoca> he .. or  |map
15:22:51 <cyberpear> when I try to use the dict() construct with map, I get `unhashable type: 'list'`
15:23:11 <sdoran> #chair jtanner nitzmahone bc
15:23:11 <zodbot> Current chairs: bc jtanner nitzmahone sdoran
15:23:14 <bcoca> to_map
15:23:15 <jtanner> cause map is looking for an attribute or key and then failing when it can find neither
15:23:17 <sdoran> #chair bcoca
15:23:17 <zodbot> Current chairs: bc bcoca jtanner nitzmahone sdoran
15:24:22 <bcoca> jtanner: no, it looks for a filter, for attributes you need to use attribute= option
15:24:33 <jtanner> tbh, i think if ansible needs a to_dict, jinja probably "needs" it too
15:24:35 <cyberpear> `{{ dict(myvar | map('zip', mykeys) ) }}` does not work, even w/ `|list` added
15:24:38 <bcoca> list|map('filter', attribute=)
15:25:03 <bcoca> jtanner: i dont disagree
15:25:30 <nitzmahone> jtanner I actually agree with that, but even if Jinja gets one, we couldn't use it for years (see also the equalto test)
15:25:48 <bcoca> sigh ... to_json|from_json ... would get you what you want .. but its fugly
15:25:54 <sdoran> Yeah, I was just wondering why Jinja doesn't include a `dict` filter.
15:26:00 * nitzmahone shudders
15:26:03 <bcoca> they includ e adict function
15:26:06 <jtanner> yeah, i'm saying we could carry it until jinja gets it and it's eventually in the various distros
15:26:17 <bcoca> nitzmahone: im not going to write example .. since it would haunt me
15:26:25 <nitzmahone> Lol
15:26:39 <bcoca> |mapping
15:26:53 <bcoca> ^ to avoid dict confusion and use a jinja2 'normalized' term
15:27:30 <nitzmahone> Let the bikeshedding commence 😉
15:27:35 <jtanner> to_dict
15:27:46 <bcoca> no need to fight, you can make multiple aliases to same
15:27:50 <bcoca> see relpath/realpath
15:27:58 <jtanner> unfrackpath is all i know
15:29:42 <bcoca> did we make that into a filter?
15:30:00 * bcoca was tempted to rename that function, but ended up liking the name
15:30:00 <jtanner> no, but i love the name
15:30:08 <bcoca> GET OUT OF MY BRAIN
15:30:13 <jtanner> you first
15:30:21 <cyberpear> calling it dict seems fine to me if it's just an alias for the built in
15:30:36 <cyberpear> but to_dict is fine to
15:30:44 <bcoca> to_dict/mapping
15:31:08 <bcoca> caause people will ask for 'short version' .. but if mapping is there, to_dict is already 'the short version'
15:31:11 <nitzmahone> Yeah, colliding with an already defined function that's mapped on seems like a recipe for trouble down the line
15:31:18 * bcoca is a lazy typist and thinks like lazy typists
15:31:22 <cyberpear> then we could have from_dict and unzip to undo the operation :P
15:32:13 <bcoca> dct
15:32:18 <jtanner> soon enough well make jinja a comple replication of python ...
15:32:30 <bcoca> we are well on our way
15:32:32 <nitzmahone> ... with much jankier syntax
15:32:56 <jtanner> could just rip out jinja completely and make direct call to `exec()` also =)
15:33:07 <cyberpear> heh
15:33:21 <nitzmahone> Just write `(code) | python_eval` and be done with it
15:33:33 <jtanner> exec technically
15:33:38 <nitzmahone> Yeah
15:34:17 <nitzmahone> You can basically do that already if you know what you're doing...
15:34:34 <nitzmahone> <.<
15:34:40 <jtanner> >.>
15:34:56 <jtanner> to_exec
15:35:10 * nitzmahone quits
15:35:12 <sdoran> shhhhh ;)
15:35:21 * jtanner braces for many more months of cve discussion
15:37:02 <nitzmahone> s/months/lifetimes/
15:37:58 <bcoca> nitzmahone:   lookup('pipe' ....
15:38:28 <sdoran> So seems like we're ok adding a `to_dict` filter so long as it remains  a pretty thin wrapper over Python's `dict()`.
15:38:32 <nitzmahone> That's the "easy" way ;)
15:38:34 * cyberpear tries to avoid that
15:39:03 <sdoran> I'll go ask in the Jinja chat why they don't offer a `dict` filter. I couldn't find anything in issues and PRs.
15:39:12 * bcoca writes unsafe_eval_no_really_dont_use this filter
15:39:38 <bcoca> sdoran++
15:39:58 <nitzmahone> Probably because most people are using full templates, not just expressions, which makes it easier to do imperative stuff
15:40:11 <sdoran> cyberpear: You can submit a PR (with tests 😁) and we'll review it.
15:40:18 <sdoran> Anything else on this topic?
15:40:31 <cyberpear> ok, thanks
15:40:37 * bcoca was hoping to bikeshed for another 30mins ...
15:40:56 <nitzmahone> Meeting's not over yet ;)
15:41:01 <sdoran> #topic open floor
15:42:09 <sdoran> If there are no more topics, I'll close in one minute.
15:45:39 <sdoran> Thanks everyone for participating!
15:45:41 <sdoran> #endmeeting