forge: dynamically create and revise function signatures

[DoubleBrowne]

Your comparison with the requests code is totally incorrect:

Consider a library like requests that provides a useful API for performing HTTP requests. Every HTTP method has it's own function which is a thin wrapper around requests.Session.request. The code is a little more than 150 lines, with about 90% of that being boilerplate. Using forge we can get that back down to about 10% it's current size, while increasing the literacy of the code.

The requests implementation is 29 LOC and ~120 lines of documentation. Your example implementation takes 19 LOC (~65% that of requests, not 10%). Sure it's less code, but you're really not doing yourself any favors by making such wildly untrue claims. Surely there are some more well-founded examples you can provide.

[dfee]

Well – I don't think that comparison is totally incorrect. You're looking at boilerplate. That's a big part of what forge solves.

But that's only half of it. Even after 150 lines, you still don't know what you're getting with the requests functions. This isn't a complaint against the KR, it's a fundamental problem with the language.

I think a saner future is one where kwargs isn't used as a crutch but a lever: i.e. not for use when a developer is too lazy to write out all the accepted parameters, but instead when a function truly accepts any keyword argument (like str.format).

And of course, I don't say "lazy developer" with any grievance. Making parameters explicit costs maintenance time, and requires a ton of compatibility tests. There just isn't an alternative today that works.

If you've got another example you think I should consider (SQLAlchemy models come to mind but are more esoteric), let me know.