Twitter | Search | |
Raymond Hettinger
Python core developer. Freelance programmer/consultant/trainer. Husband to Rachel. Father to Matthew.
3,089
Tweets
372
Following
50,821
Followers
Tweets
Raymond Hettinger 9h
Replying to @ounyeki
The length depend on both the slice and the sequence: >>> p = 'abcdefghi' >>> q = 'abcde' >>> s = slice(1, 10, 2) >>> len(p[s]) 4 >>> len(q[s]) 2
Reply Retweet Like
Raymond Hettinger Jun 17
Replying to @micoo_w
Modern dicts are more compact than they've ever been. Looping forward or backward uses views, so there is no copying.
Reply Retweet Like
Raymond Hettinger Jun 17
Replying to @PatrickBKelley
OrderedDict is still there but is less relevant than before. It has some operations that dict() doesn't and can be better at intensive reordering operations. It's also useful for cross-version code that has to run on Python 3.5.
Reply Retweet Like
Raymond Hettinger Jun 16
Replying to @Shav457
The main benefit of changes like this is that the language is cleaner and easier to learn when it has fewer special cases and special rules such as "you can use a continue-statement anywhere in a for-loop except for a finally-clause". Each language wart removed is progress :-)
Reply Retweet Like
Raymond Hettinger Jun 16
3.8 news: Given that dictionaries retain insertion order, it now makes sense to let them optionally iterate in reverse order. # Show entries from most recent to least recent for k, v in reversed(d.items()): print(f'{k} \N{long rightwards arrow} {v}')
Reply Retweet Like
Raymond Hettinger Jun 16
Replying to @cyphernormie
for line in somefile: if line.startswith('#'): continue if not line: continue if 'done' in line: break process(line)
Reply Retweet Like
Raymond Hettinger Jun 16
3.8 news: You can now use "continue" statements in a "finally" clause.
Reply Retweet Like
Raymond Hettinger Jun 16
Replying to @MrTheSaw
I'm not sure what you mean by "=" always being wrong. AFAICT, the two operators are never substitutable for one another.
Reply Retweet Like
Raymond Hettinger Jun 16
Replying to @badukaire
The essential point is that compilers could effortlessly generate the best opcode, even without the ++ operator in the language. I'm pretty sure the ++ operator was there for humans, not for the machine.
Reply Retweet Like
Raymond Hettinger Jun 16
Replying to @Cristi_Neagu
On my end the challenge is to express in a tweet something that likely warrants an entire blog post. That said, I could have still gotten my idea across without referring to SVMs (support vector machines) or decision boundaries, words that reflect how I think about the problem.
Reply Retweet Like
Raymond Hettinger Jun 16
Replying to @Cristi_Neagu
Here's the story on this one. Soon Python 3.8 will be released. It adds new operator to the language. We all need to think about when and how to use it. That includes "the average Python programmer" because soon you will see examples of it popping up everywhere.
Reply Retweet Like
Raymond Hettinger Jun 16
Replying to @badukaire
I don't think that explanation is likely. Generating an INC instruction from "x = x + 1 or x += 1" is one of the easiest compiler tasks. It is more likely that ++ exists to allow humans to concisely express looping idioms and fundamental pointer operations.
Reply Retweet Like
Raymond Hettinger Jun 16
Replying to @raymondh
The := assignment expression operator (walrus operator) is new. There is no PEP 8 guidance for it, nor are there known best practices. Learning when it helps and when it hurts is more important than learning what it does. We should collectively start thinking about that now.
Reply Retweet Like
Raymond Hettinger Jun 16
Replying to @raymondh
Put the question another way: Are the good uses of := more of a win than the good uses of ++? And are the opaque and confusing uses of ++ worse than those for := ?
Reply Retweet Like
Raymond Hettinger Jun 16
Replying to @raymondh
Some things := has in common with ++: * Potential for making code more concise or expressive * Statement like behavior in expressions * Primarily targeted at secondary side-effects in larger expressions
Reply Retweet Like
Raymond Hettinger Jun 16
Replying to @DewiKoning @wesmckinn
Try "Python for Data Analysis" by
Reply Retweet Like
Raymond Hettinger Jun 16
SVM challenge: Find the decision boundary that expresses why the := assignment expression operator is considered a good idea and why a ++ operator would be considered a bad idea. Exploring these concepts gets to the heart of what makes Python pythonic.
Reply Retweet Like
Raymond Hettinger Jun 16
Replying to @andy_behrens
Or if you really cared about readabilty, perhaps avoid the walrus operator altogether. But hey, tastes vary.
Reply Retweet Like
Raymond Hettinger Jun 16
Replying to @andy_behrens
PEP 8 suggests 'if n:' over 'if n == 0'. Aversion to negation suggests 'p if c else n' rather than 'n if not c else p'. Putting the crux of the problem first suggests focusing on the recurrence rather than the corner case. Substance over form suggests not worrying about it.
Reply Retweet Like
Raymond Hettinger Jun 15
Replying to @jcchurch
At least you didn't say C++. That would have been mean ;-)
Reply Retweet Like