[Python-ideas] Keyword only argument on function call

[Chris Barker]

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 at 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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180911/cecb3fc3/attachment.html>