Comment by Walkman | Hacker News Reader

Comment by Walkman | Hacker News Reader

Parent Full thread

This guy got a bunch of things wrong:

> encode = lambda x: x.encode("utf-8", "ignore")

Why not rather call it s (short for str)?

> With tuple unpacking, using _ as a throwaway label is also OK.

Use __ (double underscore) instead so it won't clash with the gettext convention:

    from django.utils.translation import ugettext as _

> always use args and kwargs for variable argument lists
No, no, no, no, no! Why not clarify what are those accepted arguments?
What the following code is doing?
def shuffle(*args): # do something
It shuffles SOMETHING.
And this?
def shuffle(*cards): # do something
It shuffles CARDS. Big difference IMO.
> Use parens (...) for fluent APIs
I don't like that.
> Use implicit continuations in function calls
PEP8 suggest: "The preferred place to break around a binary operator is after the operator, not before it."
Following this logic, this should be:
return set((key.lower(), val.lower()) for key, val in mapping.iteritems())
(for at the end of the first line)
> Rarely create your own exception types
> ... and when you must, don't make too many.
Sorry but that's plain stupid.
> if item vs if item is not None
Yes, you should absolutely care. Not all the times, but sometimes a "NULL" value is different than a filled, but empty value. See zero. It's falsy, but totally acceptable input...

View on HN

I'm "this guy" who "got a bunch of things wrong" :)
Style guides are opinionated, and not everyone will agree. I intentionally made the style guide part of a Github repository so I could consider feedback from the community, and I've already incoporated plenty. As I mention below in the thread, I think you have a good point about "args" vs "cards" for your shuffle example.
Re: "The preferred place to break around a binary operator is after the operator, not before it", I think you mis-read this PEP8 suggestion. A binary operator is something like "and" or "+", not the "for" keyword inside a listcomp.
Re: your other disagreements, they amount to style choices of their own. When a style guide picks between two ways of doing things, there will inevitably be detractors, and I am OK with that.

If you don't use "if item" properly, it's bad code, not just style choice.

>No, no, no, no, no! Why not clarify what are those accepted arguments?
> What the following code is doing?
def shuffle(args): # do something
It's misusing the args - you shouldn't be using args/kwargs there in the first place - they should be used for forwarding and things like that - eg. you're writing a generic function decorator and things like that.
If you want a collection to operate on "cards" then pass cards as a collection, if you want to operate on abstract function parameters use args/kwargs

Yep.
If you want meaningful names then do it explicitly:
def shuffle(*args): cards = args
Much less likely to catch someone out.

If that method only accepted Cards, that's more confusing and not something visible to a code hinter that will supply the method signature. `*cards` is more explicit when the expected parameter is a variable number of card parameters.

But it's not pythonic to care if something is a "Card" or not. All that matters is if looks and acts like a Card.

I've never agreed with that. Without a good definition of what exactly it means to "look and act like a Card", large projects can easily get several slightly different definitions of what a Card is like, and nobody knows exactly which methods to use where (so what exactly do I need to implement so my class is a "file-like object"?). Horrible.
I call it smurf typing. If it smurfs like a smurf, smurfs like a smurf and possibly smurfs like a smurf, we consider it a smurf. Good luck with that information.

I think it's valid to use a more specific parameter for vararg to indicate the type of parameters.
for example:
def ping(*servers):
But please don't deviate from args and kwargs for the generic case (like kw or kargs), it ruins more finely tuned muscle memory.

These are good points. I can't speak for pixelmonkey, but I bet he would appreciate if you sent him a pull request with your feedback. I don't know how noisy the conversation about Python style guidelines is right now, but could be worth it.

I'd gladly accept a PR on the issue raised re: "args" vs "cards" for the shuffle function. When I wrote the guideline on using the names "args" and "kwargs", I was thinking more about cases where you have to proxy both, e.g.
class SomeClass(SomeOtherClass): def __init__(self, *args, **kwargs): # some logic super(SomeClass, self).__init__(*args, **kwargs)

that's totally acceptable in this case.

> This guy got a bunch of things wrong:
> I don't like that.
Not sure how "not liking something" equates getting things wrong, but I agree with most of what the author mentioned.
Using 'x' or 's' for a short lambda makes no difference. 's' could be anything, like 'x'. Unless you're specifically using django, there's no point in renaming _. Agreed with you on the argument lists and exceptions.
Python doesn't have NULL, I think you meant None.

> Unless you're specifically using django, there's no point in renaming _
Consistency? Accidental overwriting gettext alias? Don't forget it's also the last result in the interactive interpreter...
> Python doesn't have NULL, I think you meant None.
I meant "NULL" (with quotes).

>> Use parens (...) for fluent APIs > I don't like that.
And I can't stand '/' line continuations and much prefer the paren style. Quite happy to agree to disagree but you did start your post with "This guy got a bunch of things wrong" - so you should maybe be stricter about the distinction between what you truly regard as 'wrong' and what you just respectfully disagree with?

you are right

Reply on news.ycombinator.com