7 ms·
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, usin
by Walkman 11y ago
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...
- mydpy 11y agoThese 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.
- pixelmonkey 11y agoI'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)
- Walkman 11y agothat's totally acceptable in this case.
- euphemize 11y ago> 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.
- Walkman 11y ago> 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).
- pixelmonkey 11y agoI'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.
- Walkman 11y agoIf you don't use "if item" properly, it's bad code, not just style choice.
- moonchrome 11y ago>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
- andybak 11y agoYep. If you want meaningful names then do it explicitly: def shuffle(*args): cards = args Much less likely to catch someone out.
- kevinastone 11y agoIf 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.
- encoderer 11y agoBut it's not pythonic to care if something is a "Card" or not. All that matters is if looks and acts like a Card.
- Scarblac 11y agoI'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.
- andybak 11y ago>> 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?
- Walkman 11y agoyou are right
- kevinastone 11y agoI 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.