[Python-Dev] Accepting PEP 3154 for 3.4?

Tim Peters tim.peters at gmail.com
Tue Nov 19 02:17:24 CET 2013


[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).


More information about the Python-Dev mailing list