PHP: Facebook. Python: ? Ruby: ?
thanks, I've always wondered about that.
to the downvoters: thank you for letting the world see the hatred.
A few things to remember while coding in Python
91–100 of 146 posts
Re: A few things to remember while coding in Python
#92Earlier quoted context omitted.
Agreed. It could be written much more clearly in my opinion like this: [varname] = [x for x in l if predicate_with_single_truth_value(x)]
I had to check that on the REPL. I'm surprised that even works and I can't think of a good reason why should list syntax be allowed as a lvalue, in addition to tuple syntax.
It's called destructuring assignment. It's been around for a while.
Re: A few things to remember while coding in Python
#93isn't items more efficient than iteritems when you are going to go over all the items for sure on a short list?
No, never. The items method generates an intermediate list.
Re: A few things to remember while coding in Python
#94Earlier quoted context omitted.
What's that lambda thingo in the middle then? Pretty sure that's another function, redefined every time your function is called.
Yes, the lambda creates the function. Note that defvar does not. So there is still only one function being defined here.
Ok, I see now.
You've still got that &optional argument though. I don't see a huge amount of difference from a semantic point of view between that and the Python version though (ie. if x == None: ...).
Re: A few things to remember while coding in Python
#95Overall, this is a nice post. There are two quibbles though. 1). For the most part, "c = collections.Counter()" is almost always better than "c = defaultdict(int)" * Counter only supplies missing values rather than automatically inserting them upon lookup. * The Counter version is much clearer about what it is trying to do. The defaultdict version is cryptic to the uninitiated (understanding it entails knowing that i…
Unfortunately, Counter is not available before 2.7, so for many people it's a bit too early to require it.
Re: A few things to remember while coding in Python
#96Earlier quoted context omitted.
Not only is it overly-verbose and ultimately unnecessary (as shown by the alternative that follows in the article) but this mechanism is actually broken. For instance if "freqs" were data given to you from somewhere else and "freqs[c]" happened to have a type that cannot legally have 1 added to it, you'd want to see this error. The "except:" however will absorb any and all exception types and respond to all of them b…
Also, raising exceptions used to be quite slow, which could hurt for a sparse counting set. Don't know whether that's still the case.
Also Exceptions should be used in "exceptional" circumstances and not as part of normal flow.
Re: A few things to remember while coding in Python
#97Earlier quoted context omitted.
It might work the same depending on your use of it but it's not the same. In that instance L will become a blank list if it is equal to None, zero, or a zero length string. There are many cases where this wouldn't affect anything, but there can also be instances where that will cause you to define L as a blank list when you really wanted to keep L's value. I think it's always better to be explicit and test for the va…
Ah. These are the little assumptions that keep blowing off my feet. Thanks.
It is these cases that brought the ternary operator to Python:
def f(x=None): x if x is not None else []Re: A few things to remember while coding in Python
#98Earlier quoted context omitted.
I had to check that on the REPL. I'm surprised that even works and I can't think of a good reason why should list syntax be allowed as a lvalue, in addition to tuple syntax.
It's called destructuring assignment. It's been around for a while. http://dunsmor.com/lisp/onlisp/onlisp_22.html
I mean why would you want to allow both list and tuple syntax for exactly the same semantics, when either of them would be enough.
Re: A few things to remember while coding in Python
#99Earlier quoted context omitted.
Well, yes, but I'd also like to think that code should raise the level of the programmers reading it...You should avoid gratuitous complexity I have a different set of policies than most programmers, which arises from my observation that our field's priorities are out of whack with the actual cost-benefit. Our greatest costs involve understanding systems, so our first priority should typically be to produce readable…
I have a different set of policies than most programmers, which arises from my observation that our field's priorities are out of whack with the actual cost-benefit. What metrics do you use to determine if code is readable or not? What metrics do you use to determine "actual cost-benefit"?
What metrics do you use to determine "actual cost-benefit"?
Well, if one were to take into account hard metrics for every 4 line snippet of code, then I'm not sure enough would get done fast enough. In the context of everyday programming and of the 3 examples I quoted, it's enough to ask yourself questions like: what would a newbie understand? What would an average programmer recognize immediately? If there's a quick obvious answer to either of those questions, and no onerous externalities involved, then that's what you write. (The code being 10X longer or too slow or too likely to contain bugs would be an onerous externality.)
This isn't to say that metrics aren't useful here. The question is how to apply them at a low enough cost. In a large company, perhaps one could A/B test variations on coding standards. In a diverse group of small programming shops with internally consistent coding standards or styles, one might gather metrics on bugs per line of code versus features of coding styles.
Something to think about. It's not as if metrics are commonly used to make these decisions now. Either edicts come from on high, or the local alpha-coder declarers what's best in her/his experience.
Re: A few things to remember while coding in Python
#100Overall, this is a nice post. There are two quibbles though. 1). For the most part, "c = collections.Counter()" is almost always better than "c = defaultdict(int)" * Counter only supplies missing values rather than automatically inserting them upon lookup. * The Counter version is much clearer about what it is trying to do. The defaultdict version is cryptic to the uninitiated (understanding it entails knowing that i…
Unfortunately, Counter is not available before 2.7, so for many people it's a bit too early to require it.
This. On reading this post, I ran to my computer to replace defaultdict(int) with Counter in some of my code, only to find that I couldn't use it yet.