>> Now that you've spent so much time with this patch, can't you thinkYes, but barely.
>> of a faster way of doing this?
> Well firstly, you could replace Quoter (the class) with a "quoter"
> function, which is nested inside quote. Would calling a nested function
> be faster than a method call?
Yes, it would be tremendously faster, since the method would be called
>> I wonder if mapping a defaultdict wouldn't work.
> That is a good idea. Then, the "function" (as I describe above) would be
> just the inside of what currently is the except block, and that would be
> the default_factory of the defaultdict. I think that should speed things up.
only once per byte value (for each value of 'safe'), and if that byte
is repeated in the input, further occurrences will use the __getitem__
function of the defaultdict, which is implemented in C.
That's very wise. But a first-order approximation of the speed of
> I'm very hazy about what is faster in the bytecode world of Python, and
> wary of making a change and proclaiming "this is faster!" without doing
> proper speed tests (which is why I think this optimisation could be
> delayed until at least after the core interface changes are made).
something is often "how many functions/methods implemented in Python
(i.e. with def or lambda) does it call?"
That's fine, as long as we have closure before beta3, which is next Wednesday.
> But I'll have a go at that change tomorrow.
> (I won't be able to work on this for up to 24 hours).