On 25 June 2013 20:19, Anders Hovmöller <boxed@killingar.net> wrote:
Just a side idea, maybe what you want is not new syntax but a linter? Knock together a script that runs through your code and tells you about any oddities it finds, thus guaranteeing that your stuff does indeed match up. As an added bonus, you could plug that into your source control system so you get an alert before you can commit - not sure how you do that in Mercurial but I'm sure you can (I've only ever done it with git). Makes it really easy to catch problems.
I've thought about that but rejected it because then I'd have to change all these functions to be keyword arguments. In an example I just scrolled to randomly this changes a function call from 368 characters to 627! I believe there are several worse examples :(
With my suggestion at least that function call would only go up to 595 without changing local variable names. If I also add the feature to my suggestion that "foo(bar=something.bar)" == "foo(=something.bar)" (which is pretty horrible!), I can get it down to 500 and still use keyword arguments. And there'a few superflous Nones that I can get rid of if I use keyword arguments, but only 5, which in this case doesn't change much.
Writing these numbers gives me the feeling that it's indeed this code base that is pathological :P
Unfortunately, it sounds like that may be the case. The subprocess.Popen constructor is probably the most pathological "Swiss army function" in the standard library, and even that would struggle to hit 300 characters for a single function call (maybe if you had some long variable names to pass in, or wrote a long command line in place as a list or string literal). With function signatures like that, you may even want to build the keyword argument mapping programmatically, and then call the end result as: function_with_crazy_signature(**kwargs) It's not *that* uncommon for even subprocess.Popen to be called that way (or else for it to be wrapped in a helper class or closure that supplies some of the parameters). Building up to the final call with functools.partial is another way to potentially manage interacting with that kind of complicated API. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia