Timeline for Dynamically unpacking Python tuples with structure checking using JIT compilation

Current License: CC BY-SA 4.0

12 events

when toggle format	what		by	license	comment
Jul 30 at 12:43	history	edited	Toby Speight	CC BY-SA 4.0	Code fence and prettify hint
Jul 30 at 8:55	history	edited	user1537366	CC BY-SA 4.0	added 651 characters in body
Jul 30 at 8:39	comment	added	user1537366		@Reinderien I guess you didn't understand what my code was doing. It's creating a function which is cached per structure and running the function. The function does exactly one destructuring assignment. So it definitely isn't "slow" unless you do it only a few times, in which case "slow" doesn't even matter.
Jul 30 at 8:29	vote	accept	user1537366
Jul 30 at 8:28	comment	added	user1537366		@Reinderien it was meant to only handle structures that would have been easily unpacked via a destructuring assignment, so I highly doubt it will hit a stack limit in normal use cases
Jul 30 at 8:24	comment	added	user1537366		@301_Moved_Permanently it's exactly because it's structure-checking and it's (almost) as efficient as possible once the unpacker code is compiled for that particular structure.
Jul 26 at 20:34	history	became hot network question
Jul 26 at 15:11	answer	added	J_H		timeline score: 2
Jul 26 at 13:13	comment	added	301_Moved_Permanently		To expand on the previous comment, why would it be necessary over the much simpler (albeit non-structure checking) `def flat(t): if isinstance(t, tuple): for x in t: yield from flat(x) else: yield t` ?
Jul 26 at 12:12	comment	added	Reinderien		Other than it being "interesting", what is the motivation to do this? It's vulnerable to making the program blow its stack, and will be slow.
Jul 26 at 10:39	history	edited	user1537366	CC BY-SA 4.0	added 2 characters in body
Jul 26 at 10:32	history	asked	user1537366	CC BY-SA 4.0