Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #92102 > unrolled thread
| Started by | Cameron Simpson <cs@zip.com.au> |
|---|---|
| First post | 2015-06-05 09:04 +1000 |
| Last post | 2015-06-06 12:10 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Find in ipython3 Cameron Simpson <cs@zip.com.au> - 2015-06-05 09:04 +1000
Re: Find in ipython3 Cecil Westerhof <Cecil@decebal.nl> - 2015-06-06 12:10 +0200
| From | Cameron Simpson <cs@zip.com.au> |
|---|---|
| Date | 2015-06-05 09:04 +1000 |
| Subject | Re: Find in ipython3 |
| Message-ID | <mailman.183.1433459104.13271.python-list@python.org> |
On 04Jun2015 13:09, Michael Torrie <torriem@gmail.com> wrote: >Why not use Python for what it's good for and say pipe the results of >find into your python script? Reinventing find poorly isn't going to >buy you anything. And several others made similar disparaging remarks. I think you're all missing some of the point of Cecil's approach. I suspect Cecil is a bit like me; he's writing various well understood simple external tools in Python as an aid to learning Python and its toolbox. As an added bonus one gets a deeper understanding of the nuances of the external tools as well, by debugging issues in implementing them. The point isn't always to make the shortest route to a result; Cecil clearly already knows how to invoke the find command, for example. Sometimes the point is to understand the path to the result in more detail. That may not be Cecil's objective, but I've certainly benefitted from writing my own version of things that already exist. Obviously you can't do that for everything, life is too short, but you can do it for things of interest and as a binus you can end up with a feature not available with the standard tool. Cheers, Cameron Simpson <cs@zip.com.au> You should never bet against anything in science at odds of more than about 10^12 to 1. - Ernest Rutherford
[toc] | [next] | [standalone]
| From | Cecil Westerhof <Cecil@decebal.nl> |
|---|---|
| Date | 2015-06-06 12:10 +0200 |
| Message-ID | <87zj4dp2pl.fsf@Equus.decebal.nl> |
| In reply to | #92102 |
On Friday 5 Jun 2015 01:04 CEST, Cameron Simpson wrote:
> On 04Jun2015 13:09, Michael Torrie <torriem@gmail.com> wrote:
>> Why not use Python for what it's good for and say pipe the results
>> of find into your python script? Reinventing find poorly isn't
>> going to buy you anything.
>
> And several others made similar disparaging remarks. I think you're
> all missing some of the point of Cecil's approach.
My first experience with this newsgroup was very positive. Lately I
found some remarks not really encouraging (to use a British way of
talking). I am glad with this remark.
> I suspect Cecil is a bit like me; he's writing various well
> understood simple external tools in Python as an aid to learning
> Python and its toolbox. As an added bonus one gets a deeper
> understanding of the nuances of the external tools as well, by
> debugging issues in implementing them.
Yes, this is part of what I am doing: learning to work with Python.
But it is more. If I use shell functions like:
!find ~ -iname '*python*.pdf'
then I have to switch between different way of working. Now I can use:
find('~', '.*python.*.pdf', True)
so I do not have to switch my thinking.
And I can use:
results = find('~', '.*python.*.pdf', True)
to do something with it.
At the moment the problem is that my Python variant takes 5 times as
much time as the shell version. Not a real big problem, but something
to think about.
And as someone said: this will also work in Windows. No plus for me,
but maybe for someone else.
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.python
csiph-web