VerbalExpressions/PythonVerbalExpressions

Get rid of VerEx() and "from" import

Mahi opened this issue · 3 comments

Mahi commented

I personally dislike the current behavior of:

from verbalexpressions import VerEx

foo = VerEx().find(...).anything_but(...)

As opposed to an arguably more Pythonic way:

import verbalexpressions as verex

foo = verex.find(...).anything_but(...)

I would like to contribute and implement the functionality in question, but I need to know first that it would be a welcome change -- else I'd be just wasting everyone's time.

What do you guys think, would it be cleaner to implement it to support module scope function calls? Obviously each call to these module scope functions would still create a new VerEx object internally.

jehna commented

The VerEx format is originally copied from Javascript implementation, which originates from the Javascript's native RegRxp object writing format.

I agree lowercase format would look more pythonic.

jehna commented

On the other hand, you could see verbalexpressions as a "regular expression builder", and thus imitating a string builder.

In this case the Python implementation should be something like:

ve = new VerEx()
ve.first('http://')
ve.maybe('www.')
ve.then('google.com')

...like compared to e.g. Java's StringBuilder

Mahi commented

Maybe it's just me, but I find the string building way very unpythonic. It just makes sense to have this instead:

ve = VerEx()
ve = ve.first('http://')
ve = ve.maybe('www.')
ve = ve.then('google.com')

Yes, it's longer, but also more clear and explicit. This is also how SQLAlchemy works -- a very similar library but for building SQL instead of regex.

Also, not supporting the string builder would allow something like this:

generic_ve = VerEx().first('http://').maybe('www.').then('example.com/')
videos_ve = generic_ve.then('videos')
images_ve = generic_ve.then('images')
documents_ve = generic_ve.then('documents')

With the string building example of yours, documents_ve would end up being videosimagesdocuments