[Python-ideas] Exposing regular expression bytecode

[Jonathan Goble]

On Tue, Feb 16, 2016 at 2:28 AM, Andrew Barnert <abarnert at yahoo.com> wrote:
> On Feb 15, 2016, at 22:36, Jonathan Goble <jcgoble3 at gmail.com> wrote:
>>
>>> On Tue, Feb 16, 2016 at 1:15 AM, Andrew Barnert <abarnert at yahoo.com> wrote:
>>> Isn't the regex module intended to replace the re module "one of these days", once it's actually whipped into stdlibable shape? If so, it seems like it would be better to help Matthew finish that than to add to the re module.
>>
>> As I said roughly 24 hours ago, I'd like to see this in core now
>> (meaning 3.6) because of its usefulness and (I presume) its
>> simplicity. The regex module has been "intended" to replace re for
>> what seems like (and probably has been) years, and could take several
>> more years at this pace.
>
> Sorry; I was assuming it was close because it almost made it into 3.3 and then again 3.4. But I guess the alternative position--that almost but not quite making 3.3 and 3.4 and then not even being mentioned for 3.5--implies that it may not be that near-future, even if you were to help with it.

That's precisely what I was getting at. :-)

> Anyway, assuming it's not that complicated, and you did the work, the only negative is that it might encourage people to write code that depends on re that regex can't be backward-compatible with. And at this point, that doesn't seem like much of a negative. (At the very least, nobody's made a good argument for it being a major negative.)

I would imagine that a change this simple could be easily made to
regex as well as re. In other words, I'm not opposed to having the
change made in regex; I just want to see it in re at the same time.

As for doing the work, I'm willing to look into that possibility, but
I had never, ever written C code until last month, and I know nothing
about the Python/C API. Literally all I've done in C is a fork and
extension of Lua's pattern matching [1]; considering a feature for
that is what led me to inspect Python's re internals and made me
realize that exposing the code could be very beneficial.

[1] https://github.com/jcgoble3/lua-matchext

>> As such, you're
>> not leaving a good first impression on newbie me
>
> On a personal note: please keep in mind that I'm just some random guy, like you, and so are many other people on this list. Please don't hold anything I say against the core devs, any more than you'd want something you say to represent them. It can be frustrating to push ideas through -ideas--but if you think of the long-term consequences of keeping Python simple and conservative vs. keeping the discussion fair to new ideas, it helps with the frustration. I hope I haven't contributed to pushing you away from contributing to Python, because it needs people willing to do the work and put together complete ideas, with complete implementations.

I understand, and probably shouldn't have added that last paragraph,
but it is frustrating to argue against something and then have the
same thing thrown back at me without counter-argument. I guess I'm
just annoyed that I haven't gotten any substantive comments regarding
the usefulness of it, while other threads are highly active (e.g.
generator unpacking). Perhaps I should be a bit more patient; patience
has never been one of my positive qualities. :-P

> I hope I haven't contributed to pushing you away from contributing to Python, because it needs people willing to do the work and put together complete ideas, with complete implementations.

You haven't. :-) And again, I'm willing to do some coding work on
this, but it may take some time for me to learn my way around the
Python/C API, as a cursory look at the docs immediately shows that
it's vastly different from the Lua/C API that I've recently become
accustomed to.