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 <bo...@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.bar...@noaa.gov
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
