-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Commit
- Loading branch information
There are no files selected for viewing
5 comments
on commit ce0e70a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this function is somehow not needed. The user can collect the yields manually via list (and the common python programmer should know that).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
python stdlib usually has such mini-wrappers but I think I agree, I prefer having only iterators and converting to list manually as needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just a simplyfication that makes code stay out of the way so scrutinizer is happy :)
Anyway, I if you both support that opinion, I will:
- remove find, rfind and find all and stay with finditer. One can use
lfind, *sth, rfind = finditer()
andfindall = list(finditer())
- provide a faster position_unescaped
- adapt to your style for tests for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you need a find-method that returns indices? You can use MatchObject
s, they also contain this kind of information. I think unescaped_search_for()
would cover this need, if you need to yield indices you can wrap then unescaped_search_for()
inside a new generator that just returns the match.start()
or match.end()
(these func's contain the matching positions).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the position_unescaped
(that I would rename to is_position_unescaped
to expose the boolean character of this function) is not so bad, you can extend it by start/stopping parameters or implement a manual look-behind to make it more effective. It's especially useful if passages of a string handle escapes and some not.
Squash this change with the previous commit to correct the line ending issue.