Did you mean to take this off-list? I hope not, as I'm bringing it back on. On Tue, Sep 11, 2018 at 8:09 AM, Anders Hovmöller <boxed@killingar.net> wrote:

I've spent this whole thread thinking: "who in the world is writing code with a lot of spam=spam arguments? If you are transferring that much state in a function call, maybe you should have a class that holds that state? Or pass in a **kwargs dict?

Kwargs isn’t good because it breaks static analysis which we really want.

well, Python isn't a static language, and I personally have my doubts about trying to make it more so -- but that makes it sound like we need some solution for type annotations, rather than executable code. But see my other note -- I do agree that a well specified function signature is a good thing.

for .format() -- that's why we now have f-strings -- done.

Not really no. F-strings can’t be used for many strings if you need to localize your app. If you don’t have that need then yes f-strings are great and I’m fortunate to work on an app where we don’t need to but we shouldn’t dismiss people who have this need.

Darn -- I hope this was brought up in the original f-string conversation.

for templates -- are you really passing all that data in from a bunch of variables?? as opposed to, say, a dict? That strikes me as getting code and data confused (which is sometimes hard not to do...)

Yes. For example we have decorators on our views that fetch up objects from our DB based on url fragments or query parameters and then pass to the function. This means we have all access control in our decorators and you can’t forget to do this because a view without access control decorators are stopped by a middleware. So several of variables are there before we even start the actual view function.

hmm -- this is a bit of what I mean by mixing data and code -- in my mind a database record is more data than code, so better to use a dict than a class with attributes matching teh fields. However, I also see the advantage of mixing the code -- providing additional logic, and pre and post processing, like it sounds like you are doing. But python is a nifty dynamic language -- could your views have an "as_dict" property that provided just the fields in the existing instance? If you were in Stockholm I’d offer you to come by our office and I could

show some code behind closed doors :)

As it happens, I am much closer than usual -- in the Netherlands, but still not Stockholm :-) - CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov