1. Function length being 2 is great, but unnecessarily breaking it down isn't always useful, you have to think of readability too 2. Return from the function when the jobs done 3. In a func, define variables when you are about to use them rather than defining them all at the top 4. Use variable name as _ or ignored when you want to ignore a value 5. Use meaningful func/variable names 6. Explicit returns are better than implicit returns 7. Don't forcefully implement a new feature that you just learnt
I'm a big big fan of Jack's "Stop Writing Classes" and it's great to find another talk up to the standard of that one... both these talks apply to the other languages as much as they do to Python too.
types are useful for code that will change, or code that other people will use later. I once came into a plain javascript rest API and i had no idea what data was passed around to what functions. I had to read nearly the entire codebase to safely make changes. Typescript gives you this information directly, as well as providing information about what will break if you make a change. Just change something, and click the compiler error links that show up in the console. Types aren't as much about the code that you write, as they are about the code you and others WILL write or change in the future when you have forgotten about it.
I didn't understand what he meant in one of the examples of "The gun in the mantle" bit @15:30 . def call_api(retries=MAX_RETRIES): Did he meant to we should avoid using variables for keyword arguments? If so we lose a bit of the semantics by adding a constant directly on the code, and I don't think that's a good practice for easier code review.
What he was saying is don't pre-define all of your variables up front - if you know 1/2 way down you have a loop which does a partial_sum of the input, don't define your sum variable at the top of the function. you should set your sum to zero literally just before the loop.
and if there is 3 configs with the same name? you will all 3 configs, he say'd that if there a config with 2 same name we need to return error, because something go wrong
Ga men not OP and I know this is a year late. Personally I like the new annotations for code completion in my editor. If I tell it what input type I am expecting for a variable I can quickly access methods for that type.
my man on the podium just said "I don't pass the wrong types in my functions", which made my head spin. That's like saying "I don't make mistakes". Type annotations make your code infinitely more readable, and it complements unit tests in a way that nothing else can. Here's a talk from the same pycon: ruclips.net/video/pMgmKJyWKn8/видео.html
Being stuck and not knowing what to do for 10 years after we stopped writing classes we finally know how to write some code
1. Function length being 2 is great, but unnecessarily breaking it down isn't always useful, you have to think of readability too
2. Return from the function when the jobs done
3. In a func, define variables when you are about to use them rather than defining them all at the top
4. Use variable name as _ or ignored when you want to ignore a value
5. Use meaningful func/variable names
6. Explicit returns are better than implicit returns
7. Don't forcefully implement a new feature that you just learnt
I'm a big big fan of Jack's "Stop Writing Classes" and it's great to find another talk up to the standard of that one... both these talks apply to the other languages as much as they do to Python too.
types are useful for code that will change, or code that other people will use later. I once came into a plain javascript rest API and i had no idea what data was passed around to what functions. I had to read nearly the entire codebase to safely make changes. Typescript gives you this information directly, as well as providing information about what will break if you make a change. Just change something, and click the compiler error links that show up in the console. Types aren't as much about the code that you write, as they are about the code you and others WILL write or change in the future when you have forgotten about it.
Ironically, this talk is like three times longer than it needs to be.
I don't know, some of those "good" examples are far harder for me to read.
At 20:18 The ignored parameter thing isn't really wise when you call functions with keyword arguments, as you will break the callers.
you can now make the first argument positional-only, don't know if it's convenient, but at least it won't be ambiguous
I didn't understand what he meant in one of the examples of "The gun in the mantle" bit @15:30 .
def call_api(retries=MAX_RETRIES):
Did he meant to we should avoid using variables for keyword arguments? If so we lose a bit of the semantics by adding a constant directly on the code, and I don't think that's a good practice for easier code review.
What he was saying is don't pre-define all of your variables up front - if you know 1/2 way down you have a loop which does a partial_sum of the input, don't define your sum variable at the top of the function. you should set your sum to zero literally just before the loop.
at 12:00, it can be a tad simpler.
[config] = get_host_configs(matching=[name])
return config
and if there is 3 configs with the same name? you will all 3 configs, he say'd that if there a config with 2 same name we need to return error, because something go wrong
[config] = # does fail if you don't have exactly one element.
you are right, sorry i don't know about that, thats cool
If you wouldn't mind, could you break-down this solution for me? I'm relatively new and can't understand this.
it's called unpacking and there are many articles around on it, enjoy. treyhunner.com/2018/03/tuple-unpacking-improves-python-code-readability/
How do you avoid "if" in your code?
is polymorphism really replace "if" ?
overusing ternary expressions is one.
The github repo does not exist yet..
github.com/PyCon/pycon-archive
The slides link does not have any content, I get "PyCon 2018 hasn't published any talks."
Are the slides in the GH repo ?
Typing is a great feature. You probably just don't understand why.
Please enlighten me?
Ga men not OP and I know this is a year late. Personally I like the new annotations for code completion in my editor. If I tell it what input type I am expecting for a variable I can quickly access methods for that type.
my man on the podium just said "I don't pass the wrong types in my functions", which made my head spin. That's like saying "I don't make mistakes".
Type annotations make your code infinitely more readable, and it complements unit tests in a way that nothing else can. Here's a talk from the same pycon: ruclips.net/video/pMgmKJyWKn8/видео.html
Job done, i got bored after 9 minutes and stopped watching.
Who tf told him to give speeches? Give this guy a bed so he can sleep.