[Python-ideas] New pattern-matching library (was: str.split with multiple individual split characters)

[geremy condra]

On Tue, Mar 1, 2011 at 3:22 PM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Mar 1, 2011 at 2:50 PM, geremy condra <debatem1 at gmail.com> wrote:
>> On Tue, Mar 1, 2011 at 1:23 PM, Guido van Rossum <guido at python.org> wrote:
>>> On Tue, Mar 1, 2011 at 12:25 PM, Tal Einat <taleinat at gmail.com> wrote:
>>>> On Tue, Mar 1, 2011 at 9:53 PM, geremy condra <debatem1 at gmail.com> wrote:
>>>>>
>>>>> It's unfortunate that there isn't a good way to do this kind of
>>>>> long-range work within the auspices of Python. I can imagine a number
>>>>> of projects like this that fail to attract interest due to low
>>>>> perceived chances of success and a dearth of community feedback.
>>>>
>>>> Once a good library had a solid foundation, it could plug itself into some
>>>> widely used Python programs and gain publicity and support from there,
>>>> before pushing for inclusion in the stdlib.
>>>>
>>>> A good example is Django's URL mapping, which currently uses regexps. I
>>>> think it would be possible to get Django to support an alternate pattern
>>>> matching method, in addition to regexps, since this would make learning
>>>> Django easier for developers who don't grok regexps.
>>>
>>> Ah, but geremy is complaining about work that cannot be done as a
>>> library, e.g. syntax changes. This is because I suggested a better
>>> approach to matching would probably require syntax changes. I don't
>>> have an answer -- it may be easier to create a whole new language and
>>> experiment with matching syntax than it is to get a PEP approved for a
>>> matching syntax extension to Python... That's just how it goes for
>>> mature languages. Try getting new syntax added to C++, Java or
>>> JavaScript... :-)
>>
>> Erm... this actually isn't what I was talking about at all. I was
>> basically just saying that I think it would be good if Python had
>> better tools to bring attention to issues that might be considered for
>> inclusion if a better way could be found.
>
> Ok, sorry. But that sounds so general as to be devoid of meaning. Can
> you clarify your wish with a few examples?

Well, you've noticed yourself how many times the same ideas and
questions show up on python-ideas, and how often people think they're
the first ones to come up with it. You've also noted that there are
more productive problems that people interested in contributing could
solve. ISTM that there may be an opportunity to kill two birds with
one stone in that.

Specifically, I'd suggest starting by putting together a wishlist and
a do-not-want-list from some of the core devs and putting it in a
prominent place on python.org. That should be fairly easy, and if it
doesn't seem to be getting the amount of traffic that it would need to
succeed there are a number of good ways to tie it in to other venues-
adding tickets to the bug tracker, putting it in a newsletter, having
this list spit back an email mentioning it whenever someone starts a
new thread, mentioning it on slashdot, etc. It might also be a good
way to take advantage of the sprints board, by specifically asking
groups that have done successful sprints in the past to look at these
ideas and see if they can come up with good ways to solve them. None
of that requires a huge outlay of cash or resources.

If this was successful, it might be a good idea to look at providing
some in-Python support for those working on the wishlist items. With
the hg transition already underway it seems like this should be fairly
easy- just create an hg repo for the project in question and link it
to a page on PyPI. Depending on the size of the project, amount of
interest, timescale, and stage of maturity development discussion
could take place either on the wiki, here, stdlib-sig, in their own
google group, etc. Again, nothing requiring substantial outlay or
time. The only investment required would be the effort of marketing
the list as a whole.

>From there, it would just be a question of what direction to take. I
can envision a lot of projects like this or Raymond Hettinger's idea
for a stats module eventually seeing inclusion, but there are also a
lot of possible tools where maintaining a relationship similar to the
Apache Foundation and its projects might be for the best.

I suspect it goes without saying, but I'd be happy to help out with
this, and especially with PyCon coming up its a good time to put many
eyes on problems like these.

Geremy Condra