On Tue, 15 May 2018 08:04:21 -0500
"Edward K. Ream" <edream...@gmail.com> wrote:
> On Tue, May 15, 2018 at 6:55 AM, Terry Brown <terrynbr...@gmail.com>
> wrote:
>
> > What about a namedtuple?
>
> That or a bunch. Just to be clear, the code itself may change to
> make this moot.
Realized after I posted that may have some memory impact, possibly not
an issue / very minor.
> Another possibility, which I often favor, is to unpack the tuple in
> place:
>
> item1, item2, ... itemN = aTuple
> <<use items 2 and 4 >>
>
> This pattern appears already in other places in Vitalije's code.
>
> Edward
We've discussed this before I think, but returning tuples can be a real
pain for extensibility. Changing
return foo, bar
to
return foo, bar, etc
breaks all clients, whereas changing
return {'foo': x, 'bar': y}
to
return {'foo': x, 'bar': y, 'etc': z}
is very unlikely to break anything.
but if dicts are a performance issue a named tuple might be a good
balance.
Veering off topic I wish there was a more general solution for dot
access to dict members, I understand all the arguments against, but
often writing mathematical expressions...
col = (pos['x'] - grid['minx']) / (grid['maxx'] - grid['minx']) * grid['cols']
vs.
col = (pos.x - grid.minx) / (grid.maxx - grid.minx) * grid.cols
Cheers -Terry
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
