Brilliant or insane code?
111–114 of 114 posts
Re: Brilliant or insane code?
#112Earlier quoted context omitted.
Exactly, I would be very surprised if the zip version was faster. One of the first steps to optimization in python is moving everything you can to generators and using of itertools. The OP's question of is this genius or bad is clear in that regard: it is bad, due to not being the proper optimization direction, but it is interesting.
That is a common misconception. Moving to iterators adds a function call while list creation in C is quite fast. Every case has to be tested for performance.
Maybe I'm doing crazy stuff, though!
Re: Brilliant or insane code?
#113Earlier quoted context omitted.
That is a common misconception. Moving to iterators adds a function call while list creation in C is quite fast. Every case has to be tested for performance.
I always thought the reason iterators are used in preference to lists was due to the memory advantages, not the performance.
Re: Brilliant or insane code?
#114 """Parses an array of xyz points and returns a array of point dictionaries."""
'Only, it doesn’t really. It takes an iterable of points...and returns an iterable of 3-tuples of groupped points'
The wrongness of it would cause me to double-take, because even if I were familiar with this usage, it isn't what the comment suggests is happening. A docstring more like: """Parses an iterable of values [x,y,z,x,y,z...] and returns an iterable of 3-tuples: [(x,y,z),(x,y,z)...]"""
Would be a lot more clear by simple virtue of truth, even if it didn't explain the code step by step.