[Antoine] > ... > Well, it's a question of cost / benefit: does it make sense to optimize > something that will be dwarfed by other factors in real world > situations?
For most of my career, a megabyte of RAM was an unthinkable luxury. Now I'm running on an OS that needs a gigabyte of RAM just to boot. So I'm old enough to think from the opposite end: "does it make sense to bloat something that's already working fine?". It's the "death of a thousand cuts" (well, this thing doesn't matter _that_ much - and neither does that, nor those others over there ...) that leads to a GiB-swallowing OS and a once-every-4-years crusade to reduce Python's startup time. For examples ;-) > ... > That said, assuming you think this is important (do you?), Honestly, it's more important to me "in theory" to oppose unnecessary bloat (of all kinds). But, over time, it's attitude that shapes results, so I'm not apologetic about that. > we're left with the following constraints: > - it would be nice to have this PEP in 3.4 > - 3.4 beta1 and feature freeze is in approximately one week > - switching to the PREFETCH scheme requires some non-trivial work on the > current patch, work done by either Alexandre or me (but I already > have pathlib (PEP 428) on my plate, so it'll have to be Alexandre) - > unless you want to do it, of course? > > What do you think? I wouldn't hold up PEP acceptance for this. It won't be a disaster in any case, just - at worse - another little ratchet in the "needless bloat" direction. And the PEP has more things that are pure wins. If it's possible to squeeze in the variable-length encoding, that would be great. If I were you, though, I'd check the patch in as-is, just in case. I can't tell whether I'll have time to work on it (have other things going now outside my control). _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
