[Python-ideas] re.compile_lazy - on first use compiled regexes

Chris Angelico rosuav at gmail.com
Thu Mar 28 03:06:42 CET 2013


On Thu, Mar 28, 2013 at 12:56 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On 28/03/13 12:38, Chris Angelico wrote:
>>
>> On Thu, Mar 28, 2013 at 12:25 PM, Steven D'Aprano <steve at pearwood.info>
>> wrote:
>>>
>>> We do this:
>>>
>>> x = Decimal(some_string)
>>> y = x**3
>>> z = x.exp()
>>>
>>> not this:
>>>
>>> y = Decimal(some_string)**3
>>> z = Decimal(some_string).exp()
>>>
>>> hoping that the string will be in a cache and the conversion will be
>>> fast.
>>> So why do we do this?
>>>
>>> result = re.match(some_string, text)
>>> other_result = re.match(some_string, other_text)
>>
>>
>> Would it be better if, instead of:
>>
>> pat = re.compile(some_string)
>>
>> it were spelled:
>>
>> pat = re.RegExp(some_string)
>>
>> ? It'd match Decimal and so on, while still being exactly the same
>> thing ultimately - you turn the textual regex into an object.
>
>
>
> No, you seem to have missed my point.
>
> I don't care whether we have a builder like re.compile() that turns a string
> into a regular expression object, or we use the RegExp type constructor
> directly. What I care about is that we don't recommend that people rely on
> the cache to handle that conversion, as Terry seems to be suggesting.

Yes, that's what I mean. If compile were renamed RegExp and the cache
abolished, would people find this odd, or would they be happy to do
their own compiled-regex retention? I suspect the latter. There could
still be (non-caching) re.match and friends, but it'd be understood
that they are less efficient for multiple usage.

ChrisA



More information about the Python-ideas mailing list