Has this changed since this talk? Dicts now use hashmaps, so a dict with a few million entries is no different from a dict with a couple. With slots it might be faster because it avoids the dict within the class (pretty sure? I'm still a rookie), but what's the difference really? Either way we're still looking into globals, then the class key/dict key, then the value. Unless I'm missing something. TBH I just don't want a ton of extra code and classes and scopes when a dict is just like.. whatever you want. Plus I do a lot of text parsing, and respond a lot to text-input, so a dict lookup is way faster in this case. {'key': var} is a hashed lookup with no other conversion, whereas classes would require attribute lookups.
This was a very interesting talk. And although I enjoyed the song, I could have done without the 90 seconds of music at the beginning though. Anybody else wondering if the video editor is the lead guitarist of Gramatik?
Great talk! Can somebody point me to the place where I can learn more about Dicts vc Objects memory performance? It realy surprised me to hear thar dicts can use more memory than objects... just like the man who asked a question around 33:40
I am entirely new to Python, but from what I understand, classes are implemented using a dict. For instance .__dict__ will show all of the objects attributes in their internal dictionary form. So, all classes are constructed with dicts, how could a class be faster than a dict? Are you sure this entire presentation isn't just conjecture?
He's a core Python / PyPy developer, so it's certainly not just conjecture. If something exposes a dict-like interface it doesn't mean that it's implemented as one and has the same performance characteristics.
This is ridiculous and spreading mis-information: There is absolutely no good reason why the dict example cannot achieve the same performance as a C struct when used like an object. In python, a Dict is actually semantically simpler than a generic object. CPython and PyPy may not optimize it, but its 100% doable. You need only to look at the engineering behind LuaJit to see an example. This "flaw" is just a PyPy implementation detail. In X months/years from now there will likely be a better implementation that no longer has these restrictions. As always, profile the code: don't memorize this talk as fact. These conclusions are extremely likely to change.
AJBonkoski That's not a PyPy limited implementation detail; the main difference stems from the attribute names being symbols. That implies they get interned, such that they are the same object even if created from different places (for instance, parsing some json). Classes may have further steps, like __slots__, to optimize further. Still, just interning your keys will make a huge difference when you use many similar dicts.
it would have been better to make the connection between pythonic/idiomatic code and specialized code. Either that they are the same, or that specialized code is a subset of pythonic code
Great talk! Can you please re-record all the tech videos where people um and uh ever 5 seconds? Or at least train them to slow down and just say what they're thinking. Cheers
Want speed, use C. Want simple, use python. Want speed wear running shoe, want simple wear slipper. You can make slipper fast, but it wouldn’t worth the effort, just get the running shoe. Python written in easily understand way, is python suppose to be used.
You're talking of CPython and overgeneralising. Dict is faster than before, but the classes that use it to implement dynamic attributes will be too, and classes with slots can be faster still. In particular, the main culprit of slowness tends to be not fitting in cache, and having an extra dictionary for every object will cost in both indirection and space. And that's before taking into account that class attribute names tend to be interned but dictionary keys don't.
Dynamic typing sucks and everyone knows that! So I don't get why don't just drop this stupid idea and make them strongly typed? Like for example TypeScript > JavaScript so why don't you just make JS strongly typed? Or types hints in python!!! You make python dynamically typed, BUT then introduce type hints. It can't be more stupid than that.
![Chino Pacas - Modo Capone (with Drake & Fuerza Regida) [Video Oficial]](http://i.ytimg.com/vi/zjv8TQ0gBkg/mqdefault.jpg)
Skip to 1:34 to really start.
and skip that sick beat? no way!
I feel like this was a lot of high-level choir preaching and sermonizing and not a whole lot of practical instruction on how to program better.
Has this changed since this talk? Dicts now use hashmaps, so a dict with a few million entries is no different from a dict with a couple. With slots it might be faster because it avoids the dict within the class (pretty sure? I'm still a rookie), but what's the difference really? Either way we're still looking into globals, then the class key/dict key, then the value. Unless I'm missing something.
TBH I just don't want a ton of extra code and classes and scopes when a dict is just like.. whatever you want. Plus I do a lot of text parsing, and respond a lot to text-input, so a dict lookup is way faster in this case. {'key': var} is a hashed lookup with no other conversion, whereas classes would require attribute lookups.
he is really excellent at handling questions
This was a very interesting talk. And although I enjoyed the song, I could have done without the 90 seconds of music at the beginning though. Anybody else wondering if the video editor is the lead guitarist of Gramatik?
Great talk!
Can somebody point me to the place where I can learn more about Dicts vc Objects memory performance?
It realy surprised me to hear thar dicts can use more memory than objects...
just like the man who asked a question around 33:40
some of these examples are definetly not pythonic (e.f. adding booleans to count 4 arguments -- don't do that
I'm a bit late but can you explain why and what alternative would be good
I am entirely new to Python, but from what I understand, classes are implemented using a dict. For instance .__dict__ will show all of the objects attributes in their internal dictionary form. So, all classes are constructed with dicts, how could a class be faster than a dict? Are you sure this entire presentation isn't just conjecture?
He's a core Python / PyPy developer, so it's certainly not just conjecture. If something exposes a dict-like interface it doesn't mean that it's implemented as one and has the same performance characteristics.
Everything in Python is an object. Dicts are objects, functions are objects.
Liked the talk, Speaker answers questions like if he was reading the answers haha
This is ridiculous and spreading mis-information: There is absolutely no good reason why the dict example cannot achieve the same performance as a C struct when used like an object. In python, a Dict is actually semantically simpler than a generic object. CPython and PyPy may not optimize it, but its 100% doable. You need only to look at the engineering behind LuaJit to see an example. This "flaw" is just a PyPy implementation detail. In X months/years from now there will likely be a better implementation that no longer has these restrictions. As always, profile the code: don't memorize this talk as fact. These conclusions are extremely likely to change.
AJBonkoski That's not a PyPy limited implementation detail; the main difference stems from the attribute names being symbols. That implies they get interned, such that they are the same object even if created from different places (for instance, parsing some json). Classes may have further steps, like __slots__, to optimize further. Still, just interning your keys will make a huge difference when you use many similar dicts.
In JavaScript dicts are the same as objects and V8 happily optimizes them, so dicts example is definitely a PyPy implementation detail.
it would have been better to make the connection between pythonic/idiomatic code and specialized code. Either that they are the same, or that specialized code is a subset of pythonic code
Great talk! Can you please re-record all the tech videos where people um and uh ever 5 seconds? Or at least train them to slow down and just say what they're thinking. Cheers
Talk starts at 1:53.
interesting talk! need to pypy
NameError in your code at 11:25...
Want speed, use C. Want simple, use python.
Want speed wear running shoe, want simple wear slipper.
You can make slipper fast, but it wouldn’t worth the effort, just get the running shoe.
Python written in easily understand way, is python suppose to be used.
Can someone point to the link of wiki page mentioned by Alex at 32:45 ?
+Ankush Jindal wiki.python.org/moin/TimeComplexity
p60 vid for a tec talk?
I believe in python3.4, dict is faster than classes.
You're talking of CPython and overgeneralising. Dict is faster than before, but the classes that use it to implement dynamic attributes will be too, and classes with slots can be faster still. In particular, the main culprit of slowness tends to be not fitting in cache, and having an extra dictionary for every object will cost in both indirection and space. And that's before taking into account that class attribute names tend to be interned but dictionary keys don't.
Use namedtuples if possible instead.
Is the third asker Steve Yegge? Seems like his voice.
python/django/mysql新教程：
python基础：ruclips.net/video/g6RnSRDjd5M/видео.html
29:30 is that Aja Hammerly ? Sounds like her :D
anyone know what the intro music was?
+captain coconut
Music "Just Jammin'" by Gramatik
infinite loop ? 18:40
yeah, but not too important to the example
Sounds like he's talking with full of saliva in his mouth
Dynamic typing sucks and everyone knows that! So I don't get why don't just drop this stupid idea and make them strongly typed?
Like for example TypeScript > JavaScript so why don't you just make JS strongly typed?
Or types hints in python!!! You make python dynamically typed, BUT then introduce type hints. It can't be more stupid than that.
Up
Python is a tool for scientists to help them write articles.
And that's why trillion-dollar companies are using it on a daily basis... Go be stupid somewhere else.