Note to Python 3 Users: - izip is just zip - d.iteritems() is just d.items() - To use defaultdict: You have to do the following --> from collections import defaultdict
Woah, did not notice my comment was sitting at 65 likes haha. I now have my own computer programming UA-cam channel! Thanks for commenting Suburban and making me see this!
Rafeh Qazi but in Python 2.7 zip is an iterator? izip,zip or range,xrange why not use iterator for everything and let the programmer choose if he want expand the list?
Javier I'm not sure if this is what you asked for, but you can use "list(range(x))" or "list(zip(x,y))", if you really want to have a list instead of an iterable object.
He reminds me a bit too much of a pastor for me to be completely comfortable, (like from a Pentecostal church or something). Or an unctuous salesman telling us about his schemes. Material was great, though.
@@johncherry108 It's one of his techniques to keep the audience engaged. He is an excellent speaker and he obviously does that on purpose. You might also notice that he asks the audience all the time if they learnt something new, or how many knew that, or what's the problem with this piece of code, etc.. On top of that, he makes me (and I assume other people, too) feel like we are part of the Python family; the core team seems close and approachable and I get a feeling of belonging to this line of developers who transformed the way we think about human programming forever.
The ignored() idiom exists in Python 3.4+ but is called suppress(): # NEW WAY in Python 3.4+: from contextlib import suppress with suppress(OSError): os.remove('foo.txt')
"If you are mutating something while you are iterating over it, you are living in a state of sin and you deserve whatever happens to you" :D loled so hard on this one! 20:20
@@Michael-jq1hl it's not a special character or something. he just wanted to print an arrow, that's it. the characters in single or double quotation marks are interpreted as string. so this statement prints 1 --> greens for example.
@@godfather7339 hey, kind of. I decided that instead of developing I could recruit Python Devs, so that is how I am using the little skill I have acquired. Unfortunately, most Devs think I am like any other recruiter and ignore me xD
at 7:22 it should not for i, color in enumerate(colors): print i,'--->',color[i] but for i, color in enumerate(colors): print i,'--->',color may be printing mistake
I think you do have to have the: print(i,'-->', color [i]) otherwise you will just get all the colours beside each index in a row repeated 4 times. Unless this is just in Python 3?
I literally just watched this a second time for the entertainment value! Raymond Hettinger is hilarious! Not only was watching this a lot of fun, but super-informative and efficient. I'm going to go check out some of his other talks. If I'm gonna learn python, it might as well be from this dude!
"Start open source contributions to project by going in and placing doc strings". This is a brilliant idea! I've wanted to start contributing for so long but didn't feel I have the skills, I'm gonna do this!!!
Note that these functional constructs are now in every mainstream language such as C# and Java. So, it's not that Python has a specific capability, but experienced Python programmers do encourage the use functional constructs. This video is an example.
This lecture is very nice to learn advanced Python programming. After I watched this video, I realize that I have used Python almost like using C. I have used C and C++ as well as Matlab. Hence, I thought that many approaches in Python will be not much different from the conventional languages except specialized keywords. However, I realize that grammars in Python can be different from that in C.
izip() in Python2 is zip() in Python3. Also, you can loop over the longer of the lists. So, import itertools colors = ['red','green,'blue','purple']; shapes =['circle,'triangle','square'] for col, shp in zip_longest(colors,shapes): print( col, '--->', shp) >>> red ---> circle green ---> triangle blue ---> square
First - this is an awesome piece, I didn't knew Raymond Hettinger was to be blamed for so many iterators in python, and I truthfully love this guy now that I know what he did for most of my days! :) There is a small bug in 15:58 onwards due to the missing tgt variable, but the more important thing is that it can get even more beautiful (IMHO) from: def find(seq, target): for i, value in enumerate(seq): if value == target: break else: return -1 return i to this: def find(seq, target): for i, value in enumerate(seq): if value == target: return i return -1 not that the for/else is not nice in some other cases, this was probably just not the right example for it.
This talk is great even after 10 years. Some of the syntax has changed, for example in 2023: at 44:05 the "with ignored" is now from contextlib import suppress with suppress(OSERROR): and the "izip" command is gone, zip now creates a generator.
Most programmers nowadays have just learnt to parrot other people's code without any actual in-depth understanding of what it does or why is its syntax the way it is. Mostly "thanks to" online tutorials, like those on Udemy or alike where blind lead the blind :q I still have people giving me weird looks when I write C++ code like this: if (a == b) do_something(); else do_something_else(); instead of wrapping the functions into braces, because they think that those braces are part of the syntaxt and have to be there. Or if I write something like this: cout
Yeah, there should be a video like this one for every language out there. One can learn much more about how to write clean code from such videos than from any crappy tutorial.
He even said I would fight him on this, but haha, oh man, the comparison functions are something I absolutely *miss*, even if I really agree with almost everything else he said and have been writing idiomatic Python for ages. I ran into a real problem the other day where comparisons were a much cleaner solution than the less obvious and potentially much slower multi-pass sorting: Sorting on multiple keys with independent ascending or descending orders. You can sort a plain tuple without any fuss if you don't mind that every key is ascending or every key is descending. But if you want to mix those, you have to do it in multiple passes, starting from the least significant key to the most significant key, and rely on timsort's stability to get the job done -- or, IMO, cleaner -- if this were Python 2, I could have expressed the comparison function with appropriate ascending/descending signs in a simple if/elif/else return 0 chain, and rapidly expressed both the intent and the functional result quickly. Python 3 even provides a conversion utility that creates wrapper objects on the fly to facilitate this need, which is a bizarrely convoluted way to accomplish what simply allowing either key function or comparison function would have.
This video was the video that got me interested in writing ideomatic Python and iterators. I've revisited it now and then ever since 1. year at uni. Amazing lecturer.
Whenever you have a break in the for loop, just wrap that loop inside a function and return instead of break. If you want to return something else in case the for loop didn't break, just return after that loop. No need for else on the for. A for loop with a break and an else is not as readable as a function which just returns from the loop and after it.
Agreed. However it's not always that easy. For example, if you rely on a lot of state variables inside a complex loop: although factoring it into a function would seem as a great thing to have, it would also mean that you would have to find some way to carry on all that complicated context along with it :q
@@bonbonpony This is exactly what classes are for. Encapsulate all that context inside one class, and have that for loop as a private function. Or if that context is shared, have it inside a named tuple and pass it to the function.
But that's the problem: then you have to PASS it around all the time. And it's not that _all_ of that context is needed _all_ the time. Suppose the loop uses only 50% of it. Then you have to pass the other unneeded 50% of the clutter too. And it will be a mess. (Inb4 you say passing objects is cheap by reference: but it's still a mess.) Classes? No, that's not what classes are for. Classes are not just "big ol' bags for data and functions" (unfortunately, many people think of them that way.) They are means to model real-life objects as new data types, by defining their interfaces. What you meant is more like a _namespace_ or _module_ , but still it doesn't solve the problem - it just moves it somewhere else. Because all that state will now have to be shared between several functions and, as I said, not _every_ function requires _every_ piece of that state at the same time.
Great explanations. And even 3 years late still very useful. One thing though, he says that generator expressions make things faster but when I timeit I get this: ~$ python -m timeit "sum(i**2 for i in xrange(10))" 100000 loops, best of 3: 1.74 usec per loop ~$ python -m timeit "sum([i**2 for i in xrange(10)])" 1000000 loops, best of 3: 1.39 usec per loop
+DeMurker Not reproducible: I got 2.57 for generator and 2.77 for list. But in any case, as you go beyond a 10 element list, you are going to get increasingly large memory and speed problems.
The reason beyond containers over generators affects only at memory level: using zip(iterator1, iterator2) produces a single big object which contains the sum of both containers, since when you use a generator, it only produces an element on each iteration, so you will never have the entire sum of both containers in memory, which is an optimization and faster.
I didn't read all comments but I fount that in 29:12 there is an error, 'namespace = parser.parse_args([])' should not contain an empty array as argument, that way it doesn't take into consideration CLI arguments.
At 41:09 when he explains self-defined defined decorator for LRU cache it has an error. His implementation leads to infinite recursion. Instead of this: def cache(func): saved = {} def newfunc(*args): if args in saved: return newfunc(*args) result = func(*args) saved[args] = result return result return newfunc It should've been: def cache(func): saved = {} def newfunc(*args): if args in saved: return saved[args] result = func(*args) saved[args] = result return result return newfunc
27:50 I think doing this is so common, there should be a group_by(sequence, keyfunc). You could then call it with group_by(names, len). There should also be an index_by(sequence, keyfunc). These functions would be trivial to implement, but nevertheless they are common and useful enough to be put in some standard lib (collections?).
24:20, about the use of get() when counting appearances of color within a list. I am probably not saying anything new, but I did some tests and actually using get() is slower than the naïve "if color not in d". More concise, sure, but more efficient... it doesn't seem so. The defaultdict he mentions later is actually quite faster, even including the time to convert the defaultdict back into a regular dict. Of the alternative ways of doing the counting, I sometimes use a fourth one he doesn't mention, and is almost as fast as the defaultdict. The code would go like this: d = {} for color in colors: try: d[color] += 1 except: d[color] = 1 Of course the relative speed of different methods depends on how many different "color" items we have within the list "colors". The try/except method is more efficient the less distinct colors there are (so less except blocks executed).
@14:21 lambda: f.read(32) is a lot clearer to me than "partial(f.read, 32)" since all we're actually doing is suppressing evaluation of f.read until it's called by iter, the equivalent of quoting in lisp. It threw me for a loop because I think of partial as being used for partial evaluation, something to do with the name I think.
I learned a lot! Then again I don't use Py3 because I use Jython which only 2.7 is stable and a compositing suite that has 2.7 also. The problem with functional programming is (and this video proves it) is that you need to know the function names and what to look for. This means actually bothering to read lots of papers and documentation and then you need to remember them. People aren't very good in remembering things especially non-descriptive. So only people who really dedicated in a language will know these things but Python is an awesome language but it's not a core programming language for most. Which is Java, C# or C++ and there you don't have a lot of functional functions. I love C because it has very few keywords, STL is great but I ALWAYS need to to reread who it works. Functionally very powerful but it's even less descriptive than these functions. So now that I know these situations explained by Raymond I will look them back here and read the docs apply them several times and probably by the 7th or 9th time I will remember it. That is until I don't use Python for 2 years again and forgotten all about them :D
Many (if not most) FP languages offer some sort of modules or namespaces to handle this exact problem of discovery, it's definitely not an issue with the paradigm in general.
I thoroughly enjoyed your presentation! Take the old-fashioned, ugly, slow way of doing things and instead do the new-fangled, beautiful, fast way. I love it!
@@happygimp0 Yes, but that’s typo you will notice when testing. The other one you will not notice, but he is doing the same thing again, when he wanted to do a more elegant solution. So the mistake lies in the very thing he wants to showcase.
This needs updated for Python 3 - I have to go hunting for which of his recommendations are still valid. The video could at least have footnotes that say which still applies in Py3.
Thank you so much for this wonderful lecture. I think this insight might be helpful . As a Novice programer I had a few issues understanding how some of core functions in Python worked and what was because the people who taught me where using derived language examples. Phrases like "if you've code an another language....". But I haven't well time passed I learned the hard way later got to this video and inevitably think that things would been a lot easier for me if this lecture was around.
After over 10 years as a working professionally with Python, Hettinger can still blow my mind and renew my passion towards the language. Anyone knows if the deck of slides is still available anywhere?
17:00 Let A = "the loop ran over a non-empty iterable and there was A break" Let B = "the loop ran over a non-empty iterable and there was NO break" Let C = "the loop ran over an empty iterable" (i.e. there were no iterations) The `else` in `for... else` runs in cases B and C. I need something that runs only in case C. I don't think there is such a thing. If there were, maybe it could be called `emptyloop` or `empty`. A bit of a contrived example: ``` # `node` is a BST node for child in (node.left, node.right): process(child) empty: print(f"{node} is a leaf node") ```
This is great! I have a *much* better understanding of iterators and their purpose now. Thanks, Mr. Hettinger. edit: How did I not know about dictionary comprehensions?!? (21:05) That is AWESOME!!
17:00 What an example of a solution in search of a problem. Just use 'return' more eagerly: def find(seq, target): for i, value in enumerate(seq): if value == target: return i return -1 And if you try to tell me that in some particular scenario you cannot return that early just refactor your code.
@@edauardo3vela Yup, that's right, the main point, though, is that the concept of eager returns can nicely simplify code without using obscure for-else constructs.
15:50, can we argue that is no surprising the [for..else ] loop to be shocking for devs who see it for the first time? It might have even made sense to be the other way around? That is "for x in z" (translated to I am going to iterate over all these elements) or "else" (execute smth if unable to do so). That would be an "else" line tight to the "for" line. Furthermore, we might never have a conditional exit inside the body of the "for", and expect to finish the loop. Then else to what?
Another simple way to calculate count of items in list using dictionary [video time :-24:30] colour =[1,2,1,2,3,3,4,4] d= {} for num in colour : d[num]= colour.count(num)
Note to Python 3 Users:
- izip is just zip
- d.iteritems() is just d.items()
- To use defaultdict: You have to do the following --> from collections import defaultdict
Rafeh Qazi thx for the additional info
Woah, did not notice my comment was sitting at 65 likes haha. I now have my own computer programming UA-cam channel! Thanks for commenting Suburban and making me see this!
You are welcome. I will check out your channel as well! Cheers
Rafeh Qazi but in Python 2.7 zip is an iterator? izip,zip or range,xrange why not use iterator for everything and let the programmer choose if he want expand the list?
Javier I'm not sure if this is what you asked for, but you can use "list(range(x))" or "list(zip(x,y))", if you really want to have a list instead of an iterable object.
10:20 Beautiful syntax highlighting
Lol
I remember my prof for C++ and OOP had every other word/letter in his notes/code highlighted with no common theme whatsoever.
This guy is seriously amazing, love his style of teaching
Pity his ego needs to be continuously stroked with applause.
John Cherry Oh FFS, it's a joke. First rule of becoming a Python programmer: have a sense of humor.
He reminds me a bit too much of a pastor for me to be completely comfortable, (like from a Pentecostal church or something). Or an unctuous salesman telling us about his schemes. Material was great, though.
@@johncherry108 It's one of his techniques to keep the audience engaged. He is an excellent speaker and he obviously does that on purpose. You might also notice that he asks the audience all the time if they learnt something new, or how many knew that, or what's the problem with this piece of code, etc..
On top of that, he makes me (and I assume other people, too) feel like we are part of the Python family; the core team seems close and approachable and I get a feeling of belonging to this line of developers who transformed the way we think about human programming forever.
No wonder why Python is awesome, they have awesome devs :)
The ignored() idiom exists in Python 3.4+ but is called suppress():
# NEW WAY in Python 3.4+:
from contextlib import suppress
with suppress(OSError):
os.remove('foo.txt')
Thanks! I was wondering why I couldn't find it
+
"If you are mutating something while you are iterating over it, you are living in a state of sin and you deserve whatever happens to you" :D loled so hard on this one! 20:20
Hi I have recently started studying python, what is that arrow in print i,'-->',color?
@@Michael-jq1hl it's not a special character or something. he just wanted to print an arrow, that's it. the characters in single or double quotation marks are interpreted as string. so this statement prints 1 --> greens for example.
@@burakozdamar I see, many thanks, I never found the answer to that and now that I see the quotes makes more sense :)
@@Michael-jq1hl it's been a year, hope you are doing with python.
@@godfather7339 hey, kind of. I decided that instead of developing I could recruit Python Devs, so that is how I am using the little skill I have acquired.
Unfortunately, most Devs think I am like any other recruiter and ignore me xD
I’ve been using Python for over a decade (informally trained) and haven’t learned so many great tidbits so quickly in a long time. Awesome talk!
At 44:00, The `with ignored(OSError)` has been renamed to `with suppress(OSError)` and is from the contextlib package.
6 years old but still good advice. Raymond is a great teacher.
@@cirogarcia8958 10 years old, your statement of his statement still stands.
@@GroundZero_US almost 11 now
@@stijnvandensande3579 • and still holds up
Man YT recommended it after 8 yrs
In search of gold I found diamond
at 7:22 it should not
for i, color in enumerate(colors):
print i,'--->',color[i]
but
for i, color in enumerate(colors):
print i,'--->',color
may be printing mistake
I was here to write that. Nice catch.
I was about to make that comment. Either way works the same, but it's exactly what he's been telling us not to do, so clearly a mistake.
Also stopped the video to see if someone has pointed this out already)
Do you think that Raymond is reading these comments?
I think you do have to have the: print(i,'-->', color [i]) otherwise you will just get all the colours beside each index in a row repeated 4 times. Unless this is just in Python 3?
"There's two kinds of people in the world: people who've mastered dictionaries and total goobers." - Raymond Hettinger
Isn’t there are correct?
10 years old video, and it is gold.
Some minor differences, izip is just zip now i guess
I literally just watched this a second time for the entertainment value! Raymond Hettinger is hilarious! Not only was watching this a lot of fun, but super-informative and efficient.
I'm going to go check out some of his other talks. If I'm gonna learn python, it might as well be from this dude!
And how’s yours python 7 years later?
Documented version gist.github.com/JeffPaine/6213790
gratzi
hero, that is you
Dude’s kind of a colossal badass. Not even mad at the Casey Kasem vibe at all. He’s a beast.
Where have I been All this time only to find this GEM right now ??? This video is very great and a MUST WATCH for any pythonista
This dude is off the hook smart.
I think that 'return newfunc(*args)' on line 6 must be replaced by 'return saved[args]' at 41:12
yep. infinite loop
@@lucasfcnunes Stack overflow ;-)
"Start open source contributions to project by going in and placing doc strings". This is a brilliant idea! I've wanted to start contributing for so long but didn't feel I have the skills, I'm gonna do this!!!
Yes, do it. There's a lot of extremely crappy documentation for Python modules :q
At 7:26, it should be
for i, color in enumerate(colors):
print i, '-->', color
Hi I have recently started studying python, what is that arrow in print i,'-->',color?
Michael the arrow is a string
Note that these functional constructs are now in every mainstream language such as C# and Java. So, it's not that Python has a specific capability, but experienced Python programmers do encourage the use functional constructs. This video is an example.
This lecture is very nice to learn advanced Python programming. After I watched this video, I realize that I have used Python almost like using C. I have used C and C++ as well as Matlab. Hence, I thought that many approaches in Python will be not much different from the conventional languages except specialized keywords. However, I realize that grammars in Python can be different from that in C.
I wish this guy was my teacher
+snowblindu he's cocky and not interesting at all
+hd ggoyo pffft, hater. I wish he was my teacher too!
+hd ggoyo He added a lot of the cool stuff to Python so he gets to be cocky.
+riDDimann i was just joking, he looks like a cool dude, chill guys
He is cocky, but he knows his shit. If you are going to be a hater, prove your chops.
izip() in Python2 is zip() in Python3. Also, you can loop over the longer of the lists. So,
import itertools
colors = ['red','green,'blue','purple']; shapes =['circle,'triangle','square']
for col, shp in zip_longest(colors,shapes):
print( col, '--->', shp)
>>>
red ---> circle
green ---> triangle
blue ---> square
First - this is an awesome piece, I didn't knew Raymond Hettinger was to be blamed for so many iterators in python, and I truthfully love this guy now that I know what he did for most of my days! :)
There is a small bug in 15:58 onwards due to the missing tgt variable, but the more important thing is that it can get even more beautiful (IMHO) from:
def find(seq, target):
for i, value in enumerate(seq):
if value == target:
break
else:
return -1
return i
to this:
def find(seq, target):
for i, value in enumerate(seq):
if value == target:
return i
return -1
not that the for/else is not nice in some other cases, this was probably just not the right example for it.
I'm so glad that he said we should rename For as ForEach. I suggested that online some years ago, and boy did I get lambasted by everybody!
Love this guy. I was quite disappointed when it ended. I was so expecting a much much longer video :D
You could read the "What's New" articles instead: docs.python.org/3/whatsnew/index.html
@@ceestimmerman9785 it's not quite the same!
This talk is great even after 10 years.
Some of the syntax has changed, for example in 2023:
at 44:05 the "with ignored" is now
from contextlib import suppress
with suppress(OSERROR):
and the "izip" command is gone, zip now creates a generator.
Very nice. In just 50 minutes I learned moe then in the last month.
Initially I refuse to believe any developer wouldn’t know what “in” semantically means, but then I’m reminded of all the code I’ve seen.
Most programmers nowadays have just learnt to parrot other people's code without any actual in-depth understanding of what it does or why is its syntax the way it is. Mostly "thanks to" online tutorials, like those on Udemy or alike where blind lead the blind :q I still have people giving me weird looks when I write C++ code like this:
if (a == b) do_something();
else do_something_else();
instead of wrapping the functions into braces, because they think that those braces are part of the syntaxt and have to be there. Or if I write something like this:
cout
This is a must see video for an python developer. Fantastic!
this may be the best python video I've seen online
Yeah, there should be a video like this one for every language out there.
One can learn much more about how to write clean code from such videos than from any crappy tutorial.
There's an error on the slide at 7:13 titled 'Looping over a collection and indices'. Last line should be:
print i, '-->', color
Bill Tubbs both have the same meaning brother be it color or colors [i]
Both have the same result but using the color iterator that enumerate creates is 'faster and beautiful' as he points out.
He even said I would fight him on this, but haha, oh man, the comparison functions are something I absolutely *miss*, even if I really agree with almost everything else he said and have been writing idiomatic Python for ages. I ran into a real problem the other day where comparisons were a much cleaner solution than the less obvious and potentially much slower multi-pass sorting: Sorting on multiple keys with independent ascending or descending orders.
You can sort a plain tuple without any fuss if you don't mind that every key is ascending or every key is descending. But if you want to mix those, you have to do it in multiple passes, starting from the least significant key to the most significant key, and rely on timsort's stability to get the job done -- or, IMO, cleaner -- if this were Python 2, I could have expressed the comparison function with appropriate ascending/descending signs in a simple if/elif/else return 0 chain, and rapidly expressed both the intent and the functional result quickly.
Python 3 even provides a conversion utility that creates wrapper objects on the fly to facilitate this need, which is a bizarrely convoluted way to accomplish what simply allowing either key function or comparison function would have.
In python you make your video with audience, clapping, laughing and commenting. Python is fantastic.
This video was the video that got me interested in writing ideomatic Python and iterators. I've revisited it now and then ever since 1. year at uni. Amazing lecturer.
Whenever you have a break in the for loop, just wrap that loop inside a function and return instead of break. If you want to return something else in case the for loop didn't break, just return after that loop. No need for else on the for. A for loop with a break and an else is not as readable as a function which just returns from the loop and after it.
Agreed. However it's not always that easy. For example, if you rely on a lot of state variables inside a complex loop: although factoring it into a function would seem as a great thing to have, it would also mean that you would have to find some way to carry on all that complicated context along with it :q
@@bonbonpony This is exactly what classes are for. Encapsulate all that context inside one class, and have that for loop as a private function.
Or if that context is shared, have it inside a named tuple and pass it to the function.
But that's the problem: then you have to PASS it around all the time.
And it's not that _all_ of that context is needed _all_ the time. Suppose the loop uses only 50% of it. Then you have to pass the other unneeded 50% of the clutter too. And it will be a mess. (Inb4 you say passing objects is cheap by reference: but it's still a mess.)
Classes? No, that's not what classes are for. Classes are not just "big ol' bags for data and functions" (unfortunately, many people think of them that way.) They are means to model real-life objects as new data types, by defining their interfaces. What you meant is more like a _namespace_ or _module_ , but still it doesn't solve the problem - it just moves it somewhere else. Because all that state will now have to be shared between several functions and, as I said, not _every_ function requires _every_ piece of that state at the same time.
Great explanations. And even 3 years late still very useful.
One thing though, he says that generator expressions make things faster but when I timeit I get this:
~$ python -m timeit "sum(i**2 for i in xrange(10))"
100000 loops, best of 3: 1.74 usec per loop
~$ python -m timeit "sum([i**2 for i in xrange(10)])"
1000000 loops, best of 3: 1.39 usec per loop
+DeMurker Not reproducible: I got 2.57 for generator and 2.77 for list. But in any case, as you go beyond a 10 element list, you are going to get increasingly large memory and speed problems.
The reason beyond containers over generators affects only at memory level: using zip(iterator1, iterator2) produces a single big object which contains the sum of both containers, since when you use a generator, it only produces an element on each iteration, so you will never have the entire sum of both containers in memory, which is an optimization and faster.
Do it again, but xrange(1000000) ;-)
I didn't read all comments but I fount that in 29:12 there is an error, 'namespace = parser.parse_args([])' should not contain an empty array as argument, that way it doesn't take into consideration CLI arguments.
This man is technically brilliant and hilarious. Not something you see everyday. Thanks for the nice speech!!
At 41:09 when he explains self-defined defined decorator for LRU cache it has an error. His implementation leads to infinite recursion.
Instead of this:
def cache(func):
saved = {}
def newfunc(*args):
if args in saved:
return newfunc(*args)
result = func(*args)
saved[args] = result
return result
return newfunc
It should've been:
def cache(func):
saved = {}
def newfunc(*args):
if args in saved:
return saved[args]
result = func(*args)
saved[args] = result
return result
return newfunc
Thanks, I was staring at the code confused as to how that could possibly work, because I assumed he was right and I was missing something!
Also pointed out that something wrong with the code. Ran it, and yes, infinite recursion.
this is why i love python, the ways to write clean code.
Amazing talk ! Probably best I've heard in all 26 year I'm coding. A handful of smiles and headful of HQ knowledge. Thank you, Raymond !
27:50 I think doing this is so common, there should be a group_by(sequence, keyfunc). You could then call it with group_by(names, len). There should also be an index_by(sequence, keyfunc). These functions would be trivial to implement, but nevertheless they are common and useful enough to be put in some standard lib (collections?).
I love this man! He should write a book on clean Python code, if he hasn't already.
in enumerste slide, insted of colors[i] use color, thats why we use enumerate for!
Found this to be one of the most useful python talks thus yet on youtube.
24:20, about the use of get() when counting appearances of color within a list. I am probably not saying anything new, but I did some tests and actually using get() is slower than the naïve "if color not in d". More concise, sure, but more efficient... it doesn't seem so. The defaultdict he mentions later is actually quite faster, even including the time to convert the defaultdict back into a regular dict.
Of the alternative ways of doing the counting, I sometimes use a fourth one he doesn't mention, and is almost as fast as the defaultdict. The code would go like this:
d = {}
for color in colors:
try:
d[color] += 1
except:
d[color] = 1
Of course the relative speed of different methods depends on how many different "color" items we have within the list "colors". The try/except method is more efficient the less distinct colors there are (so less except blocks executed).
Man even though this is not quite as relevant to me today, I really love his presentation style
This is probably the best presented programming video I've ever seen. Thanks!
@14:21 lambda: f.read(32) is a lot clearer to me than "partial(f.read, 32)" since all we're actually doing is suppressing evaluation of f.read until it's called by iter, the equivalent of quoting in lisp. It threw me for a loop because I think of partial as being used for partial evaluation, something to do with the name I think.
41:16 it should be "return saved[args]" instead of "return newfunc(*args)"
I m watching 7 years old video and leaning lots of amazing things.... :-) you are really great.
So this man made enumerate()? I love him from now on!
Love Raymond's presentation style.
Yes! It's very entertaining.
I learned a lot! Then again I don't use Py3 because I use Jython which only 2.7 is stable and a compositing suite that has 2.7 also.
The problem with functional programming is (and this video proves it) is that you need to know the function names and what to look for. This means actually bothering to read lots of papers and documentation and then you need to remember them. People aren't very good in remembering things especially non-descriptive.
So only people who really dedicated in a language will know these things but Python is an awesome language but it's not a core programming language for most. Which is Java, C# or C++ and there you don't have a lot of functional functions.
I love C because it has very few keywords, STL is great but I ALWAYS need to to reread who it works. Functionally very powerful but it's even less descriptive than these functions.
So now that I know these situations explained by Raymond I will look them back here and read the docs apply them several times and probably by the 7th or 9th time I will remember it. That is until I don't use Python for 2 years again and forgotten all about them :D
Many (if not most) FP languages offer some sort of modules or namespaces to handle this exact problem of discovery, it's definitely not an issue with the paradigm in general.
I can listen to Mr Hettinger all the time!!!
Thanks for the presentation and your contributions.
"with ignored(OSError)". So cool. TIL. In Python 3, it is called "with suppress(...)". You can list multiple exception types too.
I thoroughly enjoyed your presentation! Take the old-fashioned, ugly, slow way of doing things and instead do the new-fangled, beautiful, fast way. I love it!
very much required for a beginner like and why would someone dislike this ....
Maybe they code in C ;)
The "for i, color in enumarte(colors): print(i, '-->', colors[i])" could be done more beautiful by replacing the colors[i] with color.
7:18
for i, color in enumerate(colors):
print i, '-->', colors[i]
is an example of the dangers of copy and paste, just saying ...
Not his only error, he also used target and then tgt. He didn't test his code, which is a bad sign.
@@happygimp0 Yes, but that’s typo you will notice when testing.
The other one you will not notice, but he is doing the same thing again, when he wanted to do a more elegant solution.
So the mistake lies in the very thing he wants to showcase.
nicely spotted
@@happygimp0 bad sign? It appears he wrote roughly half of what was new in Python 3.
This needs updated for Python 3 - I have to go hunting for which of his recommendations are still valid. The video could at least have footnotes that say which still applies in Py3.
At 07:30, the 2nd line of the 2nd for loop should be:
print i, '->', color # not colors[i] !
nope
43:47 "ignored" is now called "suppress" and it's part of "contextlib" library.
Also I would simplify the code at 13:00 to this (one liner!):
blocks = list(iter(partial(f.read, 32), ''))
Functional programming
Raymond's an entertaining, engaging presenter. Good mix of material here, definitely came away richer for the experience.
What amazing techniques! Why I haven't seen this sooner. Thank you a lots
Thank you for the lecture, sir. I appreciate the review of some critical "dos and don'ts" for beginners.
07:25 Replace colors[i] by color in the lowest line! I am sure that‘s what he meant to write.
Just one video and learned more things worth years... great tips!
Thank you so much for this wonderful lecture. I think this insight might be helpful . As a Novice programer I had a few issues understanding how some of core functions in Python worked and what was because the people who taught me where using derived language examples. Phrases like "if you've code an another language....". But I haven't well time passed I learned the hard way later got to this video and inevitably think that things would been a lot easier for me if this lecture was around.
This presentation is simply awesome !! hands down !!
After over 10 years as a working professionally with Python, Hettinger can still blow my mind and renew my passion towards the language. Anyone knows if the deck of slides is still available anywhere?
Slides: speakerdeck.com/pyconslides/transforming-code-into-beautiful-idiomatic-python-by-raymond-hettinger-1
@@youliyav Nice!! Thanks!
Video uploaded in 2013. C++11 already was in production and range-based loops implemented there.
2018 and I still don't see much of it in real life code written by people :q
17:00
Let A = "the loop ran over a non-empty iterable and there was A break"
Let B = "the loop ran over a non-empty iterable and there was NO break"
Let C = "the loop ran over an empty iterable" (i.e. there were no iterations)
The `else` in `for... else` runs in cases B and C. I need something that runs only in case C. I don't think there is such a thing. If there were, maybe it could be called `emptyloop` or `empty`.
A bit of a contrived example:
```
# `node` is a BST node
for child in (node.left, node.right):
process(child)
empty:
print(f"{node} is a leaf node")
```
I think in cache decorator, `if args in saved`, there should return `saved[args]`
+Wen Flybywind thanks, thought I was going crazy for a second
Thanks - I am totally new to Python and was certain I would never spot an error - but looks like Idid
15:59
*if value == tgt*
is undefined, maybe "target"?
@16:08 => Your parameter is 'target' but then you compare value to 'tgt'
In python 3.5 you can chain dictionaries with {**d1, **d2, **d3} instead of ChainMap(d1, d2, d3)
Tetiana Khotiaintseva That copies the data, not chains.
Update the original dictionaries and see if the chained also gets updated
Still beautiful syntax, thanks)
Looping backwards:
for _ in colors[::1]:
print(_)
This solution is much faster
18:18 it's actually easy to read that as an indentation error. someone might "fix" the code by indenting the else inside the for :|
Holy shit do you work with monkeys? :(
I love the people who make Python! Thanks for this most enlightening talk.
are you a python ninja by now?
@@wasikhan7741 I sure am 😏
Really insightful video. Didn't even notice the time fly by. Already feel better as a Python programmer.
Most of the things which you described, comes from Functional Programming world. like zip, map, pure-impure functions etc etc...
probably best python video ive ever seen
Can't recommend this talk enough. Must watch to take your python chops to the next level.
This is great! I have a *much* better understanding of iterators and their purpose now. Thanks, Mr. Hettinger.
edit: How did I not know about dictionary comprehensions?!? (21:05) That is AWESOME!!
idk, kinda standard stuff in CS
21:00 mutating these dictionaries in a loop:
for k in list(d):
if k.startswith("r"):
del d[k]
and
d = {k: d[k] for k in d if not k.startswith('r')}
17:00 What an example of a solution in search of a problem. Just use 'return' more eagerly:
def find(seq, target):
for i, value in enumerate(seq):
if value == target:
return i
return -1
And if you try to tell me that in some particular scenario you cannot return that early just refactor your code.
yeah, and what about using seq.index(target)?
@@edauardo3vela That requires prior check for `target in seq` otherwise you need try/except around that. Also it assumes seq being a list.
@@dwightk.schrute8696 I see, so the find() can actually be applied to other types of iterables
@@edauardo3vela Yup, that's right, the main point, though, is that the concept of eager returns can nicely simplify code without using obscure for-else constructs.
@@dwightk.schrute8696 I don't see the point then why he presents such an example which can be solved more elegantly using your example
Sophomore CS student here, spent a year in Java and C and been trying to learn python. Currently, my brain is melting
15:50, can we argue that is no surprising the [for..else ] loop to be shocking for devs who see it for the first time? It might have even made sense to be the other way around? That is "for x in z" (translated to I am going to iterate over all these elements) or "else" (execute smth if unable to do so). That would be an "else" line tight to the "for" line. Furthermore, we might never have a conditional exit inside the body of the "for", and expect to finish the loop. Then else to what?
I come back to this every few years. 😅
40:26 that one guy is really enjoying it:)
13:45 realizing this was a milestone in my Python journey
Yes at a bit after 7 the output would be:
0-->r
1-->r
2-->u
3-->l
and not the:
0-->red
1-->green
2-->blue
3-->yellow
he probably intended.
7:30 Shouldn't you be using "color" instead of "colors[i]" in the second one?
i do .NET, but this was a nice glimpse of Python. there are a lot of similarities. i enjoyed the humor too
7:11 Shouldnt it be
for i, color in colors:
print(i, color)
Another simple way to calculate count of items in list using dictionary [video time :-24:30]
colour =[1,2,1,2,3,3,4,4]
d= {}
for num in colour :
d[num]= colour.count(num)
Or even shorter:
d = {c : colours.count(c) for c in colours}