Hacker News Reader

Comment by iandanforth | Hacker News Reader

I like this idea. One piece of feedback, a parameter with a leading underscore feels very odd. In python I interpret leading underscores to indicate the programmer thinks of this as an internal / pseudo-private property. Exposing it through the api makes it "public" which means (to me) that it shouldn't have a leading underscore.

This is especially true if the usecase is common enough to put in the top level examples

View on HN

While I agree, that `_param` generally means private, it is also a common way to allow parameters to be passed into a function where all other parameters are passed directly along via args and *kwargs to avoid naming collisions. An example of this is NamedTuple: https://docs.python.org/3/library/collections.html#namedtupl....

I believe Raymond Hettinger now considers that a mistake, and wishes he had gone with a trailing underscore (param_) instead. A trailing underscore is just as unlikely to lead to a collision, but less confusing.

That's a great call! I'll update this to use trailing underscore in a later version

Updated in latest release to use trailing underscore: https://timothycrosley.github.io/hypothesis-auto/CHANGELOG/ figured it would be the least painful the earlier I did it :)

Great!

It takes a bit of manual juggling, but if you take kwargs anyway you could inspect them to check for the old-style parameters, and use them if they're present, perhaps with a warning. That way you don't have to break compatibility.

Personally, I like how django does it, where one of the kwargs accepts a dict, and that dict is what's passed along as kwargs to the next level.

Reply on news.ycombinator.com