Hello! My name is Thomas and I'm a nerd. I like tech and gadgets and speculative fiction, and playing around with programming. It's not my day job, but I'm working on making it a side gig :)
One thing you see all the time from people with previous programming experience is trying to make "C-style" for loops iterating over indices and subscripting the list, i.e. for i in range(len(list)) instead of the idiomatic for item in list.
Hello! My name is Thomas and I'm a nerd. I like tech and gadgets and speculative fiction, and playing around with programming. It's not my day job, but I'm working on making it a side gig :)
Oh, and generally working against the language and its idioms by shoehorning things into place instead of picking an appropriate data structure or language construct from the outset.
Examples:
Wanting dicts to be ordered instead of using OrderedDict (this is changed in Python 3.7+).
Looping through dicts and accessing elements by key instead of using the appropriate iterator.
Using for loops and indexing to access parts of lists instead of using slices.
We created an OrderedDict, but the constructor was using **kwargs which means the arguments we passed to it were stored in a regular dict and got reordered before OrderedDict.__init__ could store them in order.
With Python 3.6+, the **kwargs stores the arguments in the same order they were written, and the OrderedDict construction works as expected:
Technically dicts have been ordered since 3.6 on (C)Python, it's just that in 3.7 they decided that to be call "Python 3.7" any implementation has to have the insertion order.
So, dicts in Python 3.6+ are ordered only in the official version, which means that you might have portability issues if you depend on that behavior, but in 3.7+ you are garanteed they will be ordered, regardless of the implementation.
Hello! My name is Thomas and I'm a nerd. I like tech and gadgets and speculative fiction, and playing around with programming. It's not my day job, but I'm working on making it a side gig :)
Hello! My name is Thomas and I'm a nerd. I like tech and gadgets and speculative fiction, and playing around with programming. It's not my day job, but I'm working on making it a side gig :)
enumerate is a great tool and it's what you should use when you actually need the index for something, but most of the time people don't really need the index.
And there's a better way to use it:
forindex,valueinenumerate(foo):# voilà, the values are already unpacked# into two handy variables!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
One thing you see all the time from people with previous programming experience is trying to make "C-style" for loops iterating over indices and subscripting the list, i.e.
for i in range(len(list))instead of the idiomaticfor item in list.Oh, and generally working against the language and its idioms by shoehorning things into place instead of picking an appropriate data structure or language construct from the outset.
Examples:
Wanting dicts to be ordered instead of using OrderedDict (this is changed in Python 3.7+).
Looping through dicts and accessing elements by key instead of using the appropriate iterator.
Using for loops and indexing to access parts of lists instead of using slices.
Things like that.
dictordering is important because keyword arguments are stored in a dict. Consider this:We created an
OrderedDict, but the constructor was using**kwargswhich means the arguments we passed to it were stored in a regulardictand got reordered beforeOrderedDict.__init__could store them in order.With Python 3.6+, the
**kwargsstores the arguments in the same order they were written, and theOrderedDictconstruction works as expected:A little detail on ordered dicts:
Technically dicts have been ordered since 3.6 on (C)Python, it's just that in 3.7 they decided that to be call "Python 3.7" any implementation has to have the insertion order.
So, dicts in Python 3.6+ are ordered only in the official version, which means that you might have portability issues if you depend on that behavior, but in 3.7+ you are garanteed they will be ordered, regardless of the implementation.
Difference with Python 2:
Yep, that's what I meant by 3.7 being different on that point.
I see a lot of this when people want to use the index to do something instead of using
for i in enumerate(foo)which returns(index, value)enumerateis a great tool and it's what you should use when you actually need the index for something, but most of the time people don't really need the index.And there's a better way to use it: