Thank you so much, this all clear for me now
--
https://mail.python.org/mailman/listinfo/python-list
tpqnn...@gmail.com wrote:
def fg(args):
if not args:
yield ""
return
for i in args[0]:
for tmp in fg(args[1:]):
yield i + tmp
return
The final return is redundant, since there is an implicit return
at the end, just like an ordinary function. The other one is just
perfor
Thanks for your detail explanation, my problem may be the 'return' keyword. I
confuse at the point that return come after yield keyword, I wonder what if in
case this code do not have the 1st return. So, when i try to delete the 1st
return, the code run with error (the list out of range).
This
On Tue, 1 Nov 2016 12:39 am, tpqnn...@gmail.com wrote:
> I have some confuse about the recursive generator where the code mixing
> Yield and return keywork as below. I understand that "return" keywork just
> raise StopIteration exception but can not understanding in depth, so,
> could some one exp
On Tue, Nov 1, 2016 at 1:50 AM, wrote:
>
> Please see the exampl I just got it below, this is the Tower of Hanoi with
> recursive generator but it do not have the 'return' here, do you have the
> advice for this term:
>
> def A001511():
> yield 1
> b=1
> for x in A001511():
>
Hi Chris,
Please see the exampl I just got it below, this is the Tower of Hanoi with
recursive generator but it do not have the 'return' here, do you have the
advice for this term:
def A001511():
yield 1
b=1
for x in A001511():
yield x+1
yield 1
trial=A001511()
for
On Tue, Nov 1, 2016 at 1:03 AM, wrote:
> Hi ChrisA,
>
> Thank you so much for sharing this point, I just concern to the point that:
> normally, I found that the generator (it may be recursive generator also) do
> not apply the "return" keyword, just the yield only. But when I delete one or
> b
Hi ChrisA,
Thank you so much for sharing this point, I just concern to the point that:
normally, I found that the generator (it may be recursive generator also) do
not apply the "return" keyword, just the yield only. But when I delete one or
both of "return" keyword above, the code do not actio
On Tue, Nov 1, 2016 at 12:39 AM, wrote:
> I have some confuse about the recursive generator where the code mixing Yield
> and return keywork as below. I understand that "return" keywork just raise
> StopIteration exception but can not understanding in depth, so, could some
> one explain me abo
On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan wrote:
>
> Short story: the subject says it all, so if you have an answer already,
> fire away. Below is the long story of what I'm using it for, and why I
> think it needs to be recursive. It may even be of more general
> interest in terms of filteri
On 27 November 2013 10:25, John O'Hagan wrote:
> On Tue, 26 Nov 2013 10:33:06 +
> Oscar Benjamin wrote:
>
> I simplified it a bit more to this:
>
> def word_sequences(prepend, target, subwords):
> """subwords is a list of lists of subwords grouped by length,
> in order of length""
On Tue, 26 Nov 2013 10:33:06 +
Oscar Benjamin wrote:
> On 26 November 2013 06:18, John O'Hagan
> wrote:
> >
[...]
> >
> > def _multicombs(prepend, words, r, chkstr):
> > """chkstr is the string of remaining availalable characters"""
> > if r == 0:
> > yield prepend, chkstr
>
On 26 November 2013 06:18, John O'Hagan wrote:
>
> Thanks, that is exactly the type of thing I was after. Although it is
> actually slower as is than a hack like
>
> def imulticombs(it, n):
> last = ()
> for i in itertools.combinations(it,n):
> if i > last:
> yield i
>
On Mon, 25 Nov 2013 12:15:15 +
Oscar Benjamin wrote:
> On 21 November 2013 13:01, John O'Hagan
> wrote:
> > In my use-case the first argument to multicombs is a tuple of words
> > which may contain duplicates, and it produces all unique
> > combinations of a certain length of those words, eg
On 21 November 2013 13:01, John O'Hagan wrote:
> In my use-case the first argument to multicombs is a tuple of words
> which may contain duplicates, and it produces all unique combinations
> of a certain length of those words, eg:
>
> list(multicombs(('cat', 'hat', 'in', 'the', 'the'), 3))
>
> [('
On Fri, 22 Nov 2013 22:33:29 -0800
Dan Stromberg wrote:
> On Fri, Nov 22, 2013 at 4:58 PM, John O'Hagan
> wrote:
>
> > On Thu, 21 Nov 2013 12:59:26 -0800
> > Dan Stromberg wrote:
> >
> > > On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan
> > > wrote:
> > >
> > > >
> > > > Short story: the subject
On Sat, 23 Nov 2013 04:23:42 +
MRAB wrote:
> On 23/11/2013 00:58, John O'Hagan wrote:
> > On Thu, 21 Nov 2013 12:59:26 -0800
> > Dan Stromberg wrote:
> >
> >> On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan
> >> wrote:
> >>
> >> >
> >> > Short story: the subject says it all, so if you have an
On Fri, Nov 22, 2013 at 4:58 PM, John O'Hagan wrote:
> On Thu, 21 Nov 2013 12:59:26 -0800
> Dan Stromberg wrote:
>
> > On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan
> > wrote:
> >
> > >
> > > Short story: the subject says it all, so if you have an answer
> > > already, fire away. Below is the lo
On 23/11/2013 00:58, John O'Hagan wrote:
On Thu, 21 Nov 2013 12:59:26 -0800
Dan Stromberg wrote:
On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan
wrote:
>
> Short story: the subject says it all, so if you have an answer
> already, fire away. Below is the long story of what I'm using it
> for, a
On Thu, 21 Nov 2013 18:14:41 -0800 (PST)
James wrote:
> On Thursday, November 21, 2013 5:01:15 AM UTC-8, John O'Hagan wrote:
[...]
> > > On 21 November 2013 06:46, John O'Hagan
> >
> > > wrote:
> >
[...]
> >
> > > > def multicombs(it, r):
> >
> > > > result = it[:r]
> >
> > > >
On Thu, 21 Nov 2013 12:59:26 -0800
Dan Stromberg wrote:
> On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan
> wrote:
>
> >
> > Short story: the subject says it all, so if you have an answer
> > already, fire away. Below is the long story of what I'm using it
> > for, and why I think it needs to be
On Thursday, November 21, 2013 5:01:15 AM UTC-8, John O'Hagan wrote:
> On Thu, 21 Nov 2013 11:42:49 +
>
> Oscar Benjamin wrote:
>
>
>
> > On 21 November 2013 06:46, John O'Hagan
>
> > wrote:
>
> > >
>
> > > I found a verbal description of such an algorithm and came up with
>
> > > thi
On Thu, 21 Nov 2013 11:42:49 +
Oscar Benjamin wrote:
> On 21 November 2013 06:46, John O'Hagan
> wrote:
> >
> > I found a verbal description of such an algorithm and came up with
> > this:
> >
> > def multicombs(it, r):
> > result = it[:r]
> > yield result
> > while 1:
> >
On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan wrote:
>
> Short story: the subject says it all, so if you have an answer already,
> fire away. Below is the long story of what I'm using it for, and why I
> think it needs to be recursive. It may even be of more general
> interest in terms of filteri
On 21 November 2013 06:46, John O'Hagan wrote:
>
> I found a verbal description of such an algorithm and came up with
> this:
>
> def multicombs(it, r):
> result = it[:r]
> yield result
> while 1:
> for i in range(-1, -r - 1, -1):
> rep = result[i]
> if
On Sun, 21 Oct 2012 17:40:41 -0700, David wrote:
> If I have one "yield" in function, the function will become generator,
Almost correct. The function becomes a *generator function*, that is, a
function that returns a generator object.
Sometimes people abbreviate that to "generator", but that i
On Monday, October 22, 2012 7:59:53 AM UTC+8, Terry Reedy wrote:
> On 10/21/2012 7:29 PM, David wrote:
>
> > I have a tree-like data structure, the basic elements are hash tables,
>
> > and they are grouped into lists, like [[{'a':1},[{'b':2}]]].
>
> > And I want to flat the lists and visit hash
On 10/21/2012 7:29 PM, David wrote:
I have a tree-like data structure, the basic elements are hash tables,
and they are grouped into lists, like [[{'a':1},[{'b':2}]]].
And I want to flat the lists and visit hash table one by one, like {'a':1},
{'b':2}.
But my program didn't work as I wish. When
On 2008-02-13, Erich <[EMAIL PROTECTED]> wrote:
> On Feb 12, 5:15 am, Ben C <[EMAIL PROTECTED]> wrote:
>> I think this works OK, but it seems a bit odd. Is there something more
>> "Pythonic" I should be doing?
>
> I have a similar tree to the one you describe here at work. I have a
> visit function
On Feb 12, 5:15 am, Ben C <[EMAIL PROTECTED]> wrote:
> I think this works OK, but it seems a bit odd. Is there something more
> "Pythonic" I should be doing?
I have a similar tree to the one you describe here at work. I have a
visit function that is very similar to yours, but takes function
argume
On 2008-02-12, Paul Hankin <[EMAIL PROTECTED]> wrote:
> On Feb 12, 10:17 pm, Ben C <[EMAIL PROTECTED]> wrote:
>> On 2008-02-12, Paul Rubin <> wrote:
>>
>> > Paul Hankin <[EMAIL PROTECTED]> writes:
>> >> def genDescendants(self):
>> >> return chain([self], *[child.genDescendants()
>> >>
On Feb 12, 10:17 pm, Ben C <[EMAIL PROTECTED]> wrote:
> On 2008-02-12, Paul Rubin <> wrote:
>
> > Paul Hankin <[EMAIL PROTECTED]> writes:
> >> def genDescendants(self):
> >> return chain([self], *[child.genDescendants()
> >> for child in self.children])
>
> > That is scary. It generate
On 2008-02-12, Paul Rubin <> wrote:
> Paul Hankin <[EMAIL PROTECTED]> writes:
>> def genDescendants(self):
>> return chain([self], *[child.genDescendants()
>> for child in self.children])
>
> That is scary. It generates an in-memory list the size of the
> whole subtree, at every level.
Paul Hankin <[EMAIL PROTECTED]> writes:
> def genDescendants(self):
> return chain([self], *[child.genDescendants()
> for child in self.children])
That is scary. It generates an in-memory list the size of the
whole subtree, at every level. Total memory consumption is maybe
even quadr
On 2008-02-12, Paul Hankin <[EMAIL PROTECTED]> wrote:
> On Feb 12, 11:15 am, Ben C <[EMAIL PROTECTED]> wrote:
>> Suppose I have an object containing an array called children. I can
>> therefore build a tree out of such objects.
>> The best I came up with so far is :
>>
>> def genDescendents(sel
On Feb 12, 11:15 am, Ben C <[EMAIL PROTECTED]> wrote:
> Suppose I have an object containing an array called children. I can
> therefore build a tree out of such objects.
> The best I came up with so far is :
>
> def genDescendents(self):
> for child in self.children:
> yield
36 matches
Mail list logo