| Newsgroups |
gmane.editors.sed.user |
| Message-ID |
<[email protected]> |
Hi Daniel,
> My comment is: Wow! That seems a great accomplishment. And a huge amount of work.
Thanks! A lot of work but also a lot of fun.
> is it feasible to allow multiple -e / -f options
Yes, sure, this is missing.
> Does sed.py allow \< and \> regular expressions?
No. By the way, they are not described in the manual page.
> Also, I assume it does & replacement but did not see it on the list.
It does.
> Does sed.py allow -i flag?
No. Should it be added?
> Why no Linux GNU sed timing for the timing comparisons?
Windows at work and at home and using a live CD to test the working on Linux. So not much time on it. When launching the tests I got a lot of "extra characters after command" errors. I guess this is due to end of line conflicts. I should come back to this.
> Is 3.4 slower in general?
Could be due to the fact that Python 3 uses Unicode as a default.
> From the command line, isn't GNU sed always going to be better
Of course. I don't expect sed.py to be an alternative of GNU sed.
> From within python, is there an advantage of using sed.py vs GNU sed?
sed.py cannot compete with GNU sed from Python neither. If there is an interest for sed.py it could be for educational purposes or to test easily new features as the ones proposed in http://sed.sourceforge.net/grabbag/tutorials/custom_sed.htm http://sed.sourceforge.net/grabbag/tutorials/custom_sed.htm .
> It would perhaps help to have a few examples of python scripts calling GNU sed
This is what does the testing utility to test the working of GNU sed on the test suites.
> PS - functionnality -> functionality
Fixed, thanks!
[Non-text portions of this message have been removed]