I don't think that expression was meant to evaluate to True - they were just reminding themselves that you can increment by an amount using += in Python.
This list of full of basic stuff though, and people who were referring to this would write insainly non-idiomatic Python, but hey, you gotta start somewhere.
When I went to doing Python full time (after having built stuff in it on and off for years) it took me a good 6 months before I was able to write idiomatic Python. That's with over 15 years development experience and actively reading lots of nice Python code to try to reach the same level.
Reading something like this reminds me of the gulf between, "can code in Python" and "writes nice code in Python".
I do have to apologize for that piece of code... I wrote it down more of a reminder... I didn't check the syntax if it works. I guess not. It will be fixed.
I don't even know why this is on the front page. It's incomplete, inaccurate and just very low quality. And it's strange that they would use this font for code.
So it's not equivalent to matching [0-9]+, which some people might expect. It's quite nice i think, because apparently int() supports Unicode numeric characters too (i didn't know this):
Right - `isdigit` checks for membership in unicode class Nd. So the other decimal digits you quote work. Similarly `int()` supports the same values. `isdigit` doesn't support Nl or No class digits (not even ones corresponding to decimal digits, like Ⅳ).
I don't know if it is possible to construct an example where `isdigit` would return True but `int` would fail. It wouldn't surprise me, either way, but at the least the failure case isn't obvious.
The real problem is the converse `"1.23".isdigit()` returns False, where 1.23 is a number, so it doesn't 'check number'. And `int("-23")` works, but `"-23".isdigit()` is False. You could argue it 'checks non-negative integer'.
I happened upon a stack exchange answer a while back, accepted, that failed because of this bug.
In general the Python way to check if one thing can be converted into another is to try, and trap the error.
I'm hoping this is some sort of late april fools post? This cheat sheet is stuff no python programmer would need to look up, and even then, manages to get a few things wrong.
Imagine you're interviewing someone for an intro-level full stack position, where they'd be writing JavaScript and Python.
You ask them a whiteboard coding question -- something about manipulating strings or implementing simple searching. Let's ignore the debate of whether this is a productive technique for interviews for now. You ask for Python in this question since you've already covered JavaScript.
The candidate can't remember what the "str" type is called, or how to find substrings in a string, or the difference between "==" and "is" for objects. They ask you to remind them if "join" is a method on sequences or on strings. They write "length()" when they mean "len()".
We've discussed at length on HN the challenges of whiteboard coding. "Nobody's favorite IDE is their conference room whiteboard".
But I feel that, even through the flawed medium of the whiteboard, I'm seeing symptoms of the candidate not really "knowing" Python to the degree I would expect of someone who applied for a job writing it.
None of the people I work with who write Python would ever forget one of these basics. I think they recognize that the ultimate "efficiency" isn't a cheat sheet on your wall, but rather learning and internalizing these tools by repeatedly using them.
Forgive me for setting up what I recognize to be a straw-man argument. Not everyone who writes Python was hired for their ability to do it. Maybe the candidate is a stellar JavaScript developer, and their only Python weaknesses are with the syntax and standard library. Perhaps a cheat sheet is an effective way to bridge the gap between "learning" and "internalizing" a language's features.
Nonetheless, I'd like to hear people's thoughts on the hypothetical situation above (or another better one, if you feel the one I've chosen is biased or misses the point).
I definitely get what you're saying, but it really depends on whether you're hiring someone to be a Python expert, or someone to be a great software developer. If you need a Python expert (someone who knows the ins and outs of the language right off the bat), you're absolutely right. If you need more generally just a great software developer though, as long as they can show they're a great programmer in a couple different languages and paradigms, whether or not they remember the specifics of how to do String operations in Python, is irrelevant. They can learn that pretty easily.
It also depends on whether or not the job in question asked for tons of Python experience as a requirement, or if software development experience was required but only familiarity with Python specifically.
> The candidate can't remember what the "str" type is called, or how to find substrings in a string, or the difference between "==" and "is" for objects. They ask you to remind them if "join" is a method on sequences or on strings. They write "length()" when they mean "len()".
If you're going to disqualify people for these kinds of errors, you're going to lose a lot of great and experienced candidates, and only hire the ones who have taken considerable amount of time to practice memorizing library functions and language quirks for whiteboard coding.
At any given moment, I can probably go back and forth between 2 or 3 languages.
I can probably "whiteboard code" in one language only.
Anything other than that has a few days of ramp up until I'm back to where I used to be.
This doesn't mean that I don't know a certain language. It means that in order to be a good programmer, my brain needs to temporarily forget a lot of things. Especially if I go back and forth between different languages.
Memorization isn't proof of internalization. Especially when you're neglecting the fact that programs work with IDEs, and are used to typing code with keyboards (and not pencils and whiteboard markers).
Someone mixing up length() and len() doesn't prove he isn't experienced or productive in python. It proves that he isn't experienced or productive in whiteboard coding.
I am not even at an intermediate level of Python and I knew all of the content, either I am better than I thought I am or this cheat sheet is a joke. I'd say it's the latter.
If anyone is new to Python and looking for a more complete set of cheat sheets, I recently developed a set aimed at beginners. Rather than simply list syntax, there's a brief summary of many core concepts in Python. I thought this might be more helpful to true beginners than a set of sheets that focus purely on syntax.
Overview of cheat sheets, and links to individual cheat sheets:
While the author of the post makes it clear that this is for developers, I think this kind of cheat sheet has some value for non-developers. Stuff like recognizing how to run a python script, how to enter the python shell, etc... all sounds like really trivial stuff that we should all know, but if I gave a crash course in Python to someone who primarily used Excel to do data analysis and parsing and whatnot, then this cheat sheet would be useful (I think). It's the little reminders that act as bridges between the gap of learning and internalizing something, as jake-low mentions.
I probably wouldn't give them this PDF, but I imagine I would give them a markdown file that illustrates many of these same reminders with examples and caveats.
It's confusing that the author specifically says that the startup works with Python and Django, because I agree that a Python developer shouldn't need a reminder that `python <file.py>` runs the python script (and in fact in that space I would have instead made a note about `python`/`python3`) but I want to try to take the value from this, rather than pile on with the crowd deriding it.
20 comments
[ 3.1 ms ] story [ 14.3 ms ] thread`(a += b) == a + b` is not true, a += b is not an expression.
`str.is_digit()` doesn't 'check number', it checks if the string is entirely composed of unicode digit codepoints.
`dict(col)` doesn't work for a general collection `dict([1,2,3])` for example.
Are these really the things people forget the most coming from another language? Not try/raise/except/finally? Negative indices?
If it works, it works, good on you for making it (and making it look good), but in general, it seems to be a bit insubstantial.
This list of full of basic stuff though, and people who were referring to this would write insainly non-idiomatic Python, but hey, you gotta start somewhere.
When I went to doing Python full time (after having built stuff in it on and off for years) it took me a good 6 months before I was able to write idiomatic Python. That's with over 15 years development experience and actively reading lots of nice Python code to try to reach the same level.
Reading something like this reminds me of the gulf between, "can code in Python" and "writes nice code in Python".
Solution: b == 0
What do you mean?
I don't know if it is possible to construct an example where `isdigit` would return True but `int` would fail. It wouldn't surprise me, either way, but at the least the failure case isn't obvious.
The real problem is the converse `"1.23".isdigit()` returns False, where 1.23 is a number, so it doesn't 'check number'. And `int("-23")` works, but `"-23".isdigit()` is False. You could argue it 'checks non-negative integer'.
I happened upon a stack exchange answer a while back, accepted, that failed because of this bug.
In general the Python way to check if one thing can be converted into another is to try, and trap the error.
The poll on that page shows an overwhelming majority (>75%) of people are ambivalent or skeptical of a Python cheat sheet.
You ask them a whiteboard coding question -- something about manipulating strings or implementing simple searching. Let's ignore the debate of whether this is a productive technique for interviews for now. You ask for Python in this question since you've already covered JavaScript.
The candidate can't remember what the "str" type is called, or how to find substrings in a string, or the difference between "==" and "is" for objects. They ask you to remind them if "join" is a method on sequences or on strings. They write "length()" when they mean "len()".
We've discussed at length on HN the challenges of whiteboard coding. "Nobody's favorite IDE is their conference room whiteboard".
But I feel that, even through the flawed medium of the whiteboard, I'm seeing symptoms of the candidate not really "knowing" Python to the degree I would expect of someone who applied for a job writing it.
None of the people I work with who write Python would ever forget one of these basics. I think they recognize that the ultimate "efficiency" isn't a cheat sheet on your wall, but rather learning and internalizing these tools by repeatedly using them.
Forgive me for setting up what I recognize to be a straw-man argument. Not everyone who writes Python was hired for their ability to do it. Maybe the candidate is a stellar JavaScript developer, and their only Python weaknesses are with the syntax and standard library. Perhaps a cheat sheet is an effective way to bridge the gap between "learning" and "internalizing" a language's features.
Nonetheless, I'd like to hear people's thoughts on the hypothetical situation above (or another better one, if you feel the one I've chosen is biased or misses the point).
It also depends on whether or not the job in question asked for tons of Python experience as a requirement, or if software development experience was required but only familiarity with Python specifically.
If you're going to disqualify people for these kinds of errors, you're going to lose a lot of great and experienced candidates, and only hire the ones who have taken considerable amount of time to practice memorizing library functions and language quirks for whiteboard coding.
At any given moment, I can probably go back and forth between 2 or 3 languages. I can probably "whiteboard code" in one language only. Anything other than that has a few days of ramp up until I'm back to where I used to be. This doesn't mean that I don't know a certain language. It means that in order to be a good programmer, my brain needs to temporarily forget a lot of things. Especially if I go back and forth between different languages.
Memorization isn't proof of internalization. Especially when you're neglecting the fact that programs work with IDEs, and are used to typing code with keyboards (and not pencils and whiteboard markers).
Someone mixing up length() and len() doesn't prove he isn't experienced or productive in python. It proves that he isn't experienced or productive in whiteboard coding.
Overview of cheat sheets, and links to individual cheat sheets:
- http://ehmatthes.github.io/pcc/cheatsheets/README.html
All cheat sheets in the set, in one pdf:
- https://github.com/ehmatthes/pcc/raw/master/cheat_sheets/beg...
I don't use Python that often so something like this is perfect to refresh each time and to avoid doing anything unidiomatic.
'Learn X in Y' is also a useful site for this sort of thing.
I probably wouldn't give them this PDF, but I imagine I would give them a markdown file that illustrates many of these same reminders with examples and caveats.
It's confusing that the author specifically says that the startup works with Python and Django, because I agree that a Python developer shouldn't need a reminder that `python <file.py>` runs the python script (and in fact in that space I would have instead made a note about `python`/`python3`) but I want to try to take the value from this, rather than pile on with the crowd deriding it.