For my personal Python projects I set a hard limit in the 94-96 range. That's wide enough that I actualy adhere to it instead of just ignoring it.
PEP8's and Google style guide's limits of 79 and 80 are way to narrow for a language with 4 space identation. However PEP says that "it is okay to increase the line length limit up to 99 characters" while Google's 80 is just a soft limit that can be broken in certain cases like long URLs.
My personal opinion is that `list_` is among the worst possible variable names (together with `bar` and `foo`). It's non-descriptive, ugly, hard to recognize, looks scary to beginners and maybe worst of all it's easy to forget the underscore when typing.
Yes, although there is a saying that "every generator is an iterator, but not every iterator is a generator". But then again generator has a bunch of methods (close, gi_frame, gi_yieldfrom, throw, gi_code, gi_running, send) that iterators don't have... I really don't know if <iter> is correct enough here, or should I use <genr> (that I don't use anywhere else and could be confusing).
Because it's rendered directly from README.md.
That way it's easier for me, because I don't have to render it every time I make a change (I make a lot of little edits all the time), and project's Github page (https://github.com/gto76/python-cheatsheet) always has the same content as webpage.
It's quite annoying to have to enable JS for 3 different domains just to see something other than a blank page. It also prevents non-JS browsers and retrievers from seeing content.
If you were to use e.g. org-mode for the source document, you could easily export to HTML automatically when the file is saved.
You could also easily use a git hook to run e.g. pandoc to convert md to HTML automatically.
There are many ways of automatically exporting HTML when you save the md source file. Please use one.
I think this behavior will only be working starting from Python 3.6, as the dictionary obtained by calling `dict.fromkeys()` before this would not keep the ordering [1]
I love that talk. Raymond Hettinger is a gem. What I took from that is the implementation does preserve order but it isn't guaranteed yet and in theory it could change.
His talks are good, except that every time he asks a stupid rhetorical question of the audience I’m overwhelmed with the urge to wang¹ a tomato at him.
In Python 3.6+, dictionaries preserve insertion order. This is done by storing the keys, values (and cached hash values) in a separate array, and the hashtable is a succinct array of indexes into this array. This results in more compact dictionaries, which are also a bit faster because of it's cache friendliness. Preserving insertion order is a happy side effect of this. This optimization can also be applied to Python sets, but it hasn't been done yet.
I am personally not a fan of details like this creeping into the language spec. CPython is not the only Python. This kind of spec creates unnecessary challenges for Micropython, for example. And of course there is Cython and others. It makes no sense to me that this should be in the language spec — you are essentially specifying a built in minefield of implementation bugs.
Cpython took this implementation detail from pypy (so it was already going to be the case in the two most used python implementations).
The reason being that the ordered dict ends up being faster than non-ordered, and people will rely on this implementation detail, so they added it to the spec to make that okay.
I'm not sure what you're trying to imply. If it's regarding the order, you're wrong. The keys returned by either `keys()` or by `__iter__` are returned in arbitrary order [1].
PEP8's and Google style guide's limits of 79 and 80 are way to narrow for a language with 4 space identation. However PEP says that "it is okay to increase the line length limit up to 99 characters" while Google's 80 is just a soft limit that can be broken in certain cases like long URLs.