Something you did in the REPL made me think of another video idea. I’d love to see a video on if or when you think it’s ok to perform imports conditionally or in the middle of a file. I think SQL Alchemy does it, but I don’t see it often. Thanks for the vids.
The latter sounds like a bad idea for a few reasons, and the only time I can think of I've seen conditional imports are if it's only relevant for type checking, or at work where (we need py2 compatibility) it depends on the python version. (IE `from six.moves import range` when in python2, but in py3 just use standard first party range)
Always fun to watch your "pythonologues" - often get to see you use tools I rarely see or understand like 'dis'. I'd like to know more of your take on the differences between the behavior of lists and tuples for very large collections. I imagine a ~16 byte difference doesn't matter much when you approach a list vs tuple of kilobyte or megabyte size. Also, I know you made a comment that tuples can be mutated but I'd love to see the ways you know of outside of say a) monkey patching the tuple object and b) updating a mutable object held as one of the elements of a tuple and what that really means from a reasoning perspective (for instance being that tuples are still not recommended to have as a default value of a function parameter). Also-Also, I'd love your take on type hinting your functions to be more amenable to passing in tuples vs say lists/sets for those occasions that you only want to iterate. I've been on the structural subtyping tick for a little bit but you probably have a more informed opinion. Also-Also-Alsooo would love you know more gotchas wrt tuples when coming from a list-only background. I got bit a couple times when I thought I could just do tuple comprehensions (only to learn I was really creating a lazy generator).
yeah it's basically monkeypatching -- using ctypes to mess with refcounts and then they're actually mutable after that -- all bets are off on things working though :) the size isn't the big thing but yes as things get larger it is less impactful (although often a list will have slightly less than double the current size as empty capacity) general rule of thumb is to have the least specific parameter typing (Sequence / Iterable / etc.) and a concrete return value (list / tuple / frozenset / etc.) yeah parens don't make tuples -- there's a video in the description with more on that
One big reason I don't use tuples: typing variable-length tuples is annoying. list[T] is much easier than tuple[T, ...]. I guess the solution would be Sequence[T] anyway?
Curious if you'd talk about or do a breakdown on how to create custom infix operators in python? Just a potentially fun exploration was thinkin about🧐, and I enjoy your way of teaching unique topics 🙂
Hi, I'm recently trying to make python a static type language. I'm trying mypy (vscode extension) + pydantic + pylance (vscode extension). I'm partly new to python, so what is the best practice? Thanks.
Python is not a statically typed language. I'm not sure what these vscode extensions provide as functionality but Python really only has type annotations. You have to do any explicit type checking yourself, you can possibly do this using decorators. With decorators you can do any type checking or manipulation prior to calling your function.
It took me a while to "get" tuples, how the position is meaningful for destructuring, pattern matching, etc. in a way that it really isn't with lists. The third thing is always the kind of thing that goes in that third slot, rather than just one of many that could be shifted left or right.
You can clearly see that the tupled print was a few nanoseconds faster. Seriously, though, I often find myself having to rewrite tuples as lists because being mutable turns out to be useful after all. So usually I only use tuples if I'm 100% sure it will never be mutable and if this fact is relevant to the code. If the list is too big and needs to be fast, I'll use Numpy's ndarrays or Panda's dataframes.
If "lists are slow" is a problem enough that you're going to solve it with ndarrays, and you're not writing mathematical code, you should probably come up with a different solution.
Aside from a small speed advantage, why is immutability good? I constantly find myself needing to append elements to lists in a wide variety of situations. I can't think of a single time when immutable lists would make the code easier to understand.
Tuples and lists are semantically different, though. I wouldn't just switch from lists to tuples just because of some performance gains which, most of the time, are not going to solve any real bottlenecks. Unless it's pretty obvious that this has become a bottleneck, in which case I could do the switch depending on the situation.
I feel like immutability can mean less speed though... Because if you want to change an immutable object, you can't, so you create a copy with the change you wanted rather than an append or at_index or something. This is coming from a primarily C programmer though, and I haven't immerged myself in this world of immutability yet.
i too use tuples too if mutetablity is not needed, i espically love the NamedTuple from typing, since i can access things via name attrubties
Something you did in the REPL made me think of another video idea. I’d love to see a video on if or when you think it’s ok to perform imports conditionally or in the middle of a file. I think SQL Alchemy does it, but I don’t see it often. Thanks for the vids.
I have a few on that -- ua-cam.com/video/yJyo-K7wW2g/v-deo.html ua-cam.com/video/PXu3KCMT3l4/v-deo.html
The latter sounds like a bad idea for a few reasons, and the only time I can think of I've seen conditional imports are if it's only relevant for type checking, or at work where (we need py2 compatibility) it depends on the python version. (IE `from six.moves import range` when in python2, but in py3 just use standard first party range)
@@anthonywritescode haha! nice, I figured as much.
Always fun to watch your "pythonologues" - often get to see you use tools I rarely see or understand like 'dis'.
I'd like to know more of your take on the differences between the behavior of lists and tuples for very large collections. I imagine a ~16 byte difference doesn't matter much when you approach a list vs tuple of kilobyte or megabyte size.
Also, I know you made a comment that tuples can be mutated but I'd love to see the ways you know of outside of say a) monkey patching the tuple object and b) updating a mutable object held as one of the elements of a tuple and what that really means from a reasoning perspective (for instance being that tuples are still not recommended to have as a default value of a function parameter).
Also-Also, I'd love your take on type hinting your functions to be more amenable to passing in tuples vs say lists/sets for those occasions that you only want to iterate. I've been on the structural subtyping tick for a little bit but you probably have a more informed opinion.
Also-Also-Alsooo would love you know more gotchas wrt tuples when coming from a list-only background. I got bit a couple times when I thought I could just do tuple comprehensions (only to learn I was really creating a lazy generator).
yeah it's basically monkeypatching -- using ctypes to mess with refcounts and then they're actually mutable after that -- all bets are off on things working though :)
the size isn't the big thing but yes as things get larger it is less impactful (although often a list will have slightly less than double the current size as empty capacity)
general rule of thumb is to have the least specific parameter typing (Sequence / Iterable / etc.) and a concrete return value (list / tuple / frozenset / etc.)
yeah parens don't make tuples -- there's a video in the description with more on that
@@anthonywritescode loved the insight on the pattern relating to abstractions/concretions wrt input and output!
One big reason I don't use tuples: typing variable-length tuples is annoying. list[T] is much easier than tuple[T, ...]. I guess the solution would be Sequence[T] anyway?
Curious if you'd talk about or do a breakdown on how to create custom infix operators in python? Just a potentially fun exploration was thinkin about🧐, and I enjoy your way of teaching unique topics 🙂
Hi, I'm recently trying to make python a static type language. I'm trying mypy (vscode extension) + pydantic + pylance (vscode extension). I'm partly new to python, so what is the best practice? Thanks.
Python is not a statically typed language. I'm not sure what these vscode extensions provide as functionality but Python really only has type annotations. You have to do any explicit type checking yourself, you can possibly do this using decorators.
With decorators you can do any type checking or manipulation prior to calling your function.
Thank you. Would love a video of why sys.getsizeof is not great 🙂
I have to work on my habit of using lists when I could use a tuple instead.
It took me a while to "get" tuples, how the position is meaningful for destructuring, pattern matching, etc. in a way that it really isn't with lists. The third thing is always the kind of thing that goes in that third slot, rather than just one of many that could be shifted left or right.
I do wish various serialization defaulted to tuples vs. list. Like json.
They are also more aesthetically pleasing. 😀
Immutable dict, you mean mappingproxy, or rather MappingProxyType from types module
it's not actually immutable -- it's a proxy (and you can still mutate it through the proxy in some cases!)
@@anthonywritescode there may be a chance for them to write an immutable version of dict in c, if enough people need it
You can clearly see that the tupled print was a few nanoseconds faster. Seriously, though, I often find myself having to rewrite tuples as lists because being mutable turns out to be useful after all. So usually I only use tuples if I'm 100% sure it will never be mutable and if this fact is relevant to the code. If the list is too big and needs to be fast, I'll use Numpy's ndarrays or Panda's dataframes.
"fast" and "ndarray" is certainly a take :)
If "lists are slow" is a problem enough that you're going to solve it with ndarrays, and you're not writing mathematical code, you should probably come up with a different solution.
❤❤❤❤❤❤❤
Aside from a small speed advantage, why is immutability good? I constantly find myself needing to append elements to lists in a wide variety of situations. I can't think of a single time when immutable lists would make the code easier to understand.
Tuples and lists are semantically different, though. I wouldn't just switch from lists to tuples just because of some performance gains which, most of the time, are not going to solve any real bottlenecks. Unless it's pretty obvious that this has become a bottleneck, in which case I could do the switch depending on the situation.
if you watched the video that's not the important part
I feel like immutability can mean less speed though... Because if you want to change an immutable object, you can't, so you create a copy with the change you wanted rather than an append or at_index or something. This is coming from a primarily C programmer though, and I haven't immerged myself in this world of immutability yet.
sure in places where you actually want mutability use it -- that's not the message here though