141–146 of 146 posts
for i, x in enumerate(numbers):
if odd(x):
del numbers[i]Earlier quoted context omitted.
At which point they will no longer make these mistakes, and thus are more expert. Everyone wins!
Except that you're risking hiring people that know all the trivia but still can't program FizzBuzz properly. The test loses its predictive value.
The example solved this by properly using import mymodule, although this might cause some more problem if your design is wrong, as see in the example. Calling f() from the module ("library") code itself is a very bad idea. Instead one should do this:
a.py:
import b
def f():
return b.x
import a
x = 1
def g():
print a.f()
import a
a.f()Slightly off topic, but does anyone know of a resource that has 'most common mistakes' for different languages all in one place? It's certainly possible to google for blog posts and stack overflow questions to assemble such a list, but it would be handy to have them all in one place. My use case is when interviewing candidates I often ask them to rate themselves on a scale of 1-5 in the languages they know, and then…
While such a resource would make your job easier, it would make the interviewee's job easier still. They'd just have to memorize all the points in the reference.
If such a resource indeed already exists, that is a bad reason not to link us to it.
If such a resource does not already exist, what you say is a bad reason to dissuade someone (who might otherwise be inclined to) from building it.
It's a pretty bad reason to argue against its existence, all around.
Earlier quoted context omitted.
You could easily use a + operator then. I find the behavior surprising. I would expect a syntax error. You get a syntax error if you write two integers next to each other (separated by a space) or two of any other thing but somehow "a" "b" got converted to "ab". If I've discovered it myself I would be tempted to fill a bug report. It goes against Python mantra: "Explicit is better than implicit" It seems someone thou…
Yeah, when I discovered this little "feature" I had a read through that. The folks that use this for blocks of multi-line text are very defensive about the practice. I do understand not wanting to break compatibility though, especially since finding instances of this is hard (which is another reason it shouldn't exist in the first place!). Oh well :)
odd, because we have triple-quotes for that, don't we?
Earlier quoted context omitted.
Yeah, when I discovered this little "feature" I had a read through that. The folks that use this for blocks of multi-line text are very defensive about the practice. I do understand not wanting to break compatibility though, especially since finding instances of this is hard (which is another reason it shouldn't exist in the first place!). Oh well :)
> The folks that use this for blocks of multi-line text are very defensive about the practice. odd, because we have triple-quotes for that, don't we?
With triple quotes you get a string with newlines and indentation in it. While you can not indent the following lines it looks ugly, and you can't do anything about newlines.
Take a look at how F# handles the issue: http://stackoverflow.com/a/14599828
And CoffeeScript: http://coffeescript.org/#strings (apparently implemented relatively recently (https://github.com/jashkenas/coffeescript/issues/3229) and borrowed from LiveScript.
There are other language which support multiline strings (Here docs) with indents stripped via means of syntax, like YAML (with |), Racket (which doesn't do dedenting, but being language it is it's very easy to add) and many shells (with Of course, you can do something like:
foo = """bar
indented at first
and after newline
"""
textwrap.dedent(foo)