Re: [OT] Usage of U+00B6 PILCROW SIGN (was: generator slides review and Python doc (+/- text bug))
On Tuesday, February 4, 2014 8:51:25 PM UTC+5:30, jmf wrote: Useless and really ugly. Evidently one can do worse: http://www.pip-installer.org/en/latest/installing.html#requirements -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Usage of U+00B6 PILCROW SIGN (was: generator slides review and Python doc (+/- text bug))
Le jeudi 6 février 2014 13:23:03 UTC+1, Rustom Mody a écrit : On Tuesday, February 4, 2014 8:51:25 PM UTC+5:30, jmf wrote: Useless and really ugly. Evidently one can do worse: http://www.pip-installer.org/en/latest/installing.html#requirements or http://cx-freeze.readthedocs.org/en/latest/index.html -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Usage of U+00B6 PILCROW SIGN (was: generator slides review and Python doc (+/- text bug))
On Thu, Feb 6, 2014 at 11:23 PM, Rustom Mody rustompm...@gmail.com wrote: On Tuesday, February 4, 2014 8:51:25 PM UTC+5:30, jmf wrote: Useless and really ugly. Evidently one can do worse: http://www.pip-installer.org/en/latest/installing.html#requirements Aside from using a little chain link icon rather than a typographer's symbol, that looks exactly the same. How's it worse? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Usage of U+00B6 PILCROW SIGN (was: generator slides review and Python doc (+/- text bug))
On Tue, Feb 4, 2014 at 1:51 AM, wxjmfa...@gmail.com wrote: I got it. If I'm visiting a page like this: http://docs.python.org/3/tutorial/index.html#the-python-tutorial 1) To read the page, I'm scrolling down. 2) When I have finished to read the page, I scroll up (or scroll back/up) to the top of the page until I see this feature and the title. 3) I click on this feature. 4) The title, already visible, moves, let's say, 2cm higher. ...? Those links aren't for navigation. They're so you can discover anchor links in the page and pass them to someone else. For instance, if I want to point someone to the section of the tutorial that talks about reading and writing files, I could just give them this link: http://docs.python.org/3/tutorial/inputoutput.html#reading-and-writing-files, instead of pointing them to the main page and instructing them to scroll down until they see Section 7.2 I was able to discover that link by opening the page, highlighting the section header with my mouse, then clicking the pilcrow. That gives me the anchor link to that section header. -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Usage of U+00B6 PILCROW SIGN (was: generator slides review and Python doc (+/- text bug))
Le mardi 4 février 2014 15:39:54 UTC+1, Jerry Hill a écrit : On Tue, Feb 4, 2014 at 1:51 AM, wxjmfa...@gmail.com wrote: I got it. If I'm visiting a page like this: http://docs.python.org/3/tutorial/index.html#the-python-tutorial 1) To read the page, I'm scrolling down. 2) When I have finished to read the page, I scroll up (or scroll back/up) to the top of the page until I see this feature and the title. 3) I click on this feature. 4) The title, already visible, moves, let's say, 2cm higher. ...? Those links aren't for navigation. They're so you can discover anchor links in the page and pass them to someone else. For instance, if I want to point someone to the section of the tutorial that talks about reading and writing files, I could just give them this link: http://docs.python.org/3/tutorial/inputoutput.html#reading-and-writing-files, instead of pointing them to the main page and instructing them to scroll down until they see Section 7.2 I was able to discover that link by opening the page, highlighting the section header with my mouse, then clicking the pilcrow. That gives me the anchor link to that section header. Useless and really ugly. -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Usage of U+00B6 PILCROW SIGN (was: generator slides review and Python doc (+/- text bug))
2014-02-04 wxjmfa...@gmail.com: Le mardi 4 février 2014 15:39:54 UTC+1, Jerry Hill a écrit : Useless and really ugly. I think this whole discussion is rather useless instead, why do you care since you're not going to use this tool anyway? -- https://mail.python.org/mailman/listinfo/python-list
generator slides review and Python doc (+/- text bug)
generator slides review and Python doc I do not know what tool is used to produce such slides. When the mouse is over a a text like a title (H* ... \H* ???) the text get transformed and a colored eol is appearing. Example with the slide #3: Even numbers becomes Even numbers§ with a visible colored §, 'SECTION SIGN' I noticed the same effect with the Python doc since ? (long time). Eg. The Python Tutorial appears as The Python Tutorial¶ with a visible colored ¶, 'PILCROW SIGN', blueish in Python 3, red in Python 2.7.6. And in plenty third party Python docs using probaly the same tool as the official Python doc. The eol glyph may vary and may not be a § or a ¶. Windows, Firefox and others. The .chm files do not seem to be affected. jmf -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review and Python doc (+/- text bug)
- Original Message - generator slides review and Python doc I do not know what tool is used to produce such slides. When the mouse is over a a text like a title (H* ... \H* ???) the text get transformed and a colored eol is appearing. Used to get a link to the given chapter/section... Works as intended. Sphinx features the same thing, it can be disabled. JM Note : the links provided in the OP example are broken though -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review and Python doc (+/- text bug)
On 02/03/2014 06:59 AM, wxjmfa...@gmail.com wrote: generator slides review and Python doc I do not know what tool is used to produce such slides. What slides? What web site are you referring to? A little context wouldn't hurt. -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review and Python doc (+/- text bug)
On 03/02/2014 13:59, wxjmfa...@gmail.com wrote: [...] I noticed the same effect with the Python doc since ? (long time). Eg. The Python Tutorial appears as The Python Tutorial¶ with a visible colored ¶, 'PILCROW SIGN', blueish in Python 3, red in Python 2.7.6. Hint: try clicking the ¶. -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review and Python doc (+/- text bug)
2014-02-03 wxjmfa...@gmail.com: generator slides review and Python doc I do not know what tool is used to produce such slides. When the mouse is over a a text like a title (H* ... \H* ???) the text get transformed and a colored eol is appearing. Example with the slide #3: Even numbers becomes Even numbers§ with a visible colored §, 'SECTION SIGN' I noticed the same effect with the Python doc since ? (long time). Eg. The Python Tutorial appears as The Python Tutorial¶ with a visible colored ¶, 'PILCROW SIGN', blueish in Python 3, red in Python 2.7.6. And in plenty third party Python docs using probaly the same tool as the official Python doc. The eol glyph may vary and may not be a § or a ¶. Windows, Firefox and others. The .chm files do not seem to be affected. jmf -- https://mail.python.org/mailman/listinfo/python-list I just saw now this mail you didn't reply to my email correctly.. Anyway I use this: https://github.com/nyergler/hieroglyph And I just use sphinx + RST to generate the slides, the raw source is here: https://raw2.github.com/AndreaCrotti/generators/master/index.rst -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review and Python doc (+/- text bug)
Le lundi 3 février 2014 18:42:36 UTC+1, Rotwang a écrit : On 03/02/2014 13:59, wxjmfa...@gmail.com wrote: [...] I noticed the same effect with the Python doc since ? (long time). Eg. The Python Tutorial appears as The Python Tutorial¶ with a visible colored ¶, 'PILCROW SIGN', blueish in Python 3, red in Python 2.7.6 Hint: try clicking the ¶. I never was aware of this feature. Is it deliverate? It gives to me the feeling of a badly programmed html page, especially if this sign does correspond to an eol! jmf -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review and Python doc (+/- text bug)
On Tue, Feb 4, 2014 at 5:37 AM, wxjmfa...@gmail.com wrote: Le lundi 3 février 2014 18:42:36 UTC+1, Rotwang a écrit : On 03/02/2014 13:59, wxjmfa...@gmail.com wrote: Hint: try clicking the ¶. I never was aware of this feature. Is it deliverate? It gives to me the feeling of a badly programmed html page, especially if this sign does correspond to an eol! Very deliberate, and very useful. I don't know why that sign should correspond to a line end; I grew up with it representing paragraph, which is close to what it means here. (Well, that and Ctrl-T, since it was character 20 on those old systems.) Yes, it does sometimes get a little distracting as the mouse moves over and away, but it would be more confusing to have it always shown, and I don't know of any better way to do it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review and Python doc (+/- text bug)
On 03/02/2014 18:37, wxjmfa...@gmail.com wrote: [...] Hint: try clicking the ¶. I never was aware of this feature. Is it deliverate? Do you mean deliberate? Of course it is. It gives to me the feeling of a badly programmed html page, especially if this sign does correspond to an eol! Why on Earth would the sign correspond to an EOL? The section sign and pilcrow have a history of being used to refer to sections and paragraphs respectively, so using them for permalinks to individual sections of a web page makes perfect sense. -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review and Python doc (+/- text bug)
Le lundi 3 février 2014 19:55:26 UTC+1, Rotwang a écrit : On 03/02/2014 18:37, wxjmfa...@gmail.com wrote: [...] Hint: try clicking the ¶. I never was aware of this feature. Is it deliverate? Do you mean deliberate? Of course it is. It gives to me the feeling of a badly programmed html page, especially if this sign does correspond to an eol! Why on Earth would the sign correspond to an EOL? The section sign and pilcrow have a history of being used to refer to sections and paragraphs respectively, so using them for permalinks to individual sections of a web page makes perfect sense. Sorry. I should have written end of paragraph or section. Having said this, that's because these signs are usually used to signal an end of ...', that I find these signs as link not really meaningful. jmf -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review
2014-02-03 Terry Reedy tjre...@udel.edu: On 2/2/2014 5:40 AM, andrea crotti wrote: In general, use assert (== AssertionError) to check program logic (should never raise). Remember that assert can be optimized away. Use other exceptions to check user behavior. So I believe that ValueError is appropriate here. I think I also questioned the particular check. Yes that's right thanks fixed it 'Generator functions', which you labeled 'generators', are functions, not iterators. The generators they return (and the generators that generator expressions evaluate to) are iterators, and more. type(a for a in 'abc') class 'generator' I am not sure whether 'specialized' or 'generalized' is the better term. Well it's true that they are functions, but they also behaved differently than functions. I've read there has been some debate at that time whether to create a different keyword to define generators or not, in the end they didn't but it wouldn't be wrong imho.. This was mainly to explain how something like for el in [1, 2, 3]: print(el) can work, But it is no longer has that *does* work. All the builtin xyz collection classes have a corresponding xyz_iterator class with a __next__ method that knows how to sequentially access collection items. We do not normally see or think about them, but they are there working for us every time we do 'for item in xyz_instance:' [].__iter__() list_iterator object at 0x035096A0 In Python one could write the following: class list_iterator: def __init__(self, baselist): self.baselist = baselist self.index = -1 # see __next__ for why def __iter__(self): return self def __next__(self): self.index += 1 return self.baselist[self.index] Yes maybe that's a much better example to show thank you. Yes this is intentionally buggy. The thing is that I wanted to show that sometimes generating things makes it harder to debug, and delays some errors, which are anyway there but would come up immediately in case of a list creation. I could not find a better non artificial example for this, any suggestion is welcome.. slide 1 - def recip_list(start, stop): lis [] for i range(start, stop): list.append(1/i) return lis for x in recip_list(-100, 3): # fail here print x immediate traceback that include the for line slide 2 --- def recip_gen(start, stop): for i in range(start, stop): yield 1/i for x in recip_gen(-100, 3): print x # fail here after printing 100 lines ... delayed traceback that omits for line with args that caused problem That's already better, another thing which I just thought about could be this (which actually happened a few times): def original_gen(): count = 0 while count 10: yield count count += 1 def consumer(): gen = original_gen() # lis = list(gen) for n in gen: print(n * 2) if I uncomment the line with lis = list(gen) it won't print anything anymore, because we have to make sure we only loop over ONCE. That maybe is a better example of possible drawback? (well maybe not a drawback but a potential common mistake) -- https://mail.python.org/mailman/listinfo/python-list
[OT] Usage of U+00B6 PILCROW SIGN (was: generator slides review and Python doc (+/- text bug))
Rotwang sg...@hotmail.co.uk writes: Why on Earth would the [“¶”, U+00B6 PILCROW SIGN] correspond to an EOL? The section sign and pilcrow have a history of being used to refer to sections and paragraphs respectively, so using them for permalinks to individual sections of a web page makes perfect sense. Symbols commonly have multiple meanings, derived from usage. URL:https://en.wikipedia.org/wiki/Pilcrow#Contemporary_use -- \ “Progress might have been all right once, but it's gone on too | `\long.” —Ogden Nash | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review
On 2/3/2014 5:22 PM, andrea crotti wrote: That's already better, another thing which I just thought about could be this (which actually happened a few times): def original_gen(): count = 0 while count 10: yield count count += 1 def consumer(): gen = original_gen() # lis = list(gen) for n in gen: print(n * 2) if I uncomment the line with lis = list(gen) it won't print anything anymore, because we have to make sure we only loop over ONCE. That maybe is a better example of possible drawback? (well maybe not a drawback but a potential common mistake) A couple of days ago I made a similar error. Stdlib code a = list(f(iterable1)) return g(a) # g just need an iterable The return value is buggy. Insert for i in a: print(i) to debug. Notice that g does not need a concrete list. Delete list wrapper. Return value goes away. Because I did other things between the last two steps, I did not immediately make the connection and was initially puzzled. Deleting debug code made things work again. Using itertools.tee would have done the same. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Usage of U+00B6 PILCROW SIGN (was: generator slides review and Python doc (+/- text bug))
Le lundi 3 février 2014 23:56:43 UTC+1, Ben Finney a écrit : Rotwang sg...@hotmail.co.uk writes: Why on Earth would the [¶, U+00B6 PILCROW SIGN] correspond to an EOL? The section sign and pilcrow have a history of being used to refer to sections and paragraphs respectively, so using them for permalinks to individual sections of a web page makes perfect sense. Symbols commonly have multiple meanings, derived from usage. URL:https://en.wikipedia.org/wiki/Pilcrow#Contemporary_use -- \ Progress might have been all right once, but it's gone on too | `\long. --Ogden Nash | _o__) | Ben Finney I got it. If I'm visiting a page like this: http://docs.python.org/3/tutorial/index.html#the-python-tutorial 1) To read the page, I'm scrolling down. 2) When I have finished to read the page, I scroll up (or scroll back/up) to the top of the page until I see this feature and the title. 3) I click on this feature. 4) The title, already visible, moves, let's say, 2cm higher. ...? Having a pilcrow to signal or to display an end of paragraph is one thing. Using a pilcrow as a link seems to me very strange. Especially if the target of that link has nothing to with paragraph, but with section! jmf -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Usage of U+00B6 PILCROW SIGN (was: generator slides review and Python doc (+/- text bug))
On Tue, Feb 4, 2014 at 5:51 PM, wxjmfa...@gmail.com wrote: 2) When I have finished to read the page, I scroll up (or scroll back/up) to the top of the page until I see this feature and the title. 3) I click on this feature. 4) The title, already visible, moves, let's say, 2cm higher. At which point your URL bar shows a hash link to this exact section, which you can then copy and paste into an email, for instance. That's what it's good for. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review
2014-02-02 Terry Reedy tjre...@udel.edu: On 2/1/2014 9:12 AM, andrea crotti wrote: Comments: The use is assert in the first slide seem bad in a couple of different respects. Why is it bad? It's probably not necessary but since we ask for a range it might be good to check if the range is valid. Maybe I should raise ValueError instead for a better exception? The use of 'gen_even' before it is defined. Well this is because l'm saying that I wish I had something like this, which I define just after. It might be confusing if it's not defined but I thought it's nice to say what I would like to do and then actually define it, what do you think? A generator expression evaluates (better than 'yields') to a generator, not just an iterator. Ok thanks fixed The definition of 'generator' copies the wrong and confused glossary entry. Generator functions return generators, which are iterators with extra behavior. I understood instead that it was the opposite, a generator is a specialized iterator, so it would be still correct that it returns an iterator, is that wrong? I would leave out For loop(2). The old pseudo-getitem iterator protocol is seldom explicitly used any more, in the say you showed. This was mainly to explain how something like for el in [1, 2, 3]: print(el) can work, assuming defining an object list-like that just implements __getitem__. It's not probably how it's implemented for lists but I thought it could clarify things.. In 'Even numbers', I have no idea what the complication of next_even() is about. Just because I wanted to find a simple way to get the next even (in case I pass an odd start number). I could also do inline but I thought it was more clear.. 'Lazyness drawbacks' overflow_list is bizarre and useless. overflow_gen is bizarre and buggy. If you are intentionally writing buggy code to make a point, label it as such on the slide. Yes this is intentionally buggy. The thing is that I wanted to show that sometimes generating things makes it harder to debug, and delays some errors, which are anyway there but would come up immediately in case of a list creation. I could not find a better non artificial example for this, any suggestion is welcome.. Iterators just produce values. Generators can consume as well as produce values, which is why they can act as both iterators and coroutines. Well is not more clear to call them in a different way since they do quite a different job as coroutines or generators? (I see this done quite often) Thanks a lot for the great feedback -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review
2014-02-01 Miki Tebeka miki.teb...@gmail.com: My 2 cents: slide 4: [i*2 for i in range(10)] Well this is not correct in theory because the end should be the max number, not the number of elements. So it should be [i*2 for i in range(10/2)] which might be fine but it's not really more clear imho.. slide 9: while True: try: it = next(g) body(it) except StopIteration: break Changed it thanks slide 21: from itertools import count, ifilterfalse def divided_by(p): return lambda n: n % p == 0 def primes(): nums = count(2) while True: p = next(nums) yield p nums = ifilterfalse(divided_by(p), nums) Thank you that's nicer, but ifiilterfalse is not in Python 3 (could use filter of course). -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review
The slides are updated now 2014-02-02 andrea crotti andrea.crott...@gmail.com: 2014-02-01 Miki Tebeka miki.teb...@gmail.com: My 2 cents: slide 4: [i*2 for i in range(10)] Well this is not correct in theory because the end should be the max number, not the number of elements. So it should be [i*2 for i in range(10/2)] which might be fine but it's not really more clear imho.. slide 9: while True: try: it = next(g) body(it) except StopIteration: break Changed it thanks slide 21: from itertools import count, ifilterfalse def divided_by(p): return lambda n: n % p == 0 def primes(): nums = count(2) while True: p = next(nums) yield p nums = ifilterfalse(divided_by(p), nums) Thank you that's nicer, but ifiilterfalse is not in Python 3 (could use filter of course). -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review
Sorry left too early, the slides are updated with the fixes suggested, thanks everyone. https://dl.dropboxusercontent.com/u/3183120/talks/generators/index.html#1 For me the biggest problem is still: - to find some more interesting example that is easy enough to explain - to find a better order in which explain things, to tell a clear story in a way 2014-02-02 andrea crotti andrea.crott...@gmail.com: The slides are updated now 2014-02-02 andrea crotti andrea.crott...@gmail.com: 2014-02-01 Miki Tebeka miki.teb...@gmail.com: My 2 cents: slide 4: [i*2 for i in range(10)] Well this is not correct in theory because the end should be the max number, not the number of elements. So it should be [i*2 for i in range(10/2)] which might be fine but it's not really more clear imho.. slide 9: while True: try: it = next(g) body(it) except StopIteration: break Changed it thanks slide 21: from itertools import count, ifilterfalse def divided_by(p): return lambda n: n % p == 0 def primes(): nums = count(2) while True: p = next(nums) yield p nums = ifilterfalse(divided_by(p), nums) Thank you that's nicer, but ifiilterfalse is not in Python 3 (could use filter of course). -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review
andrea crotti wrote: 2014-02-01 Miki Tebeka miki.teb...@gmail.com: My 2 cents: slide 21: from itertools import count, ifilterfalse def divided_by(p): return lambda n: n % p == 0 def primes(): nums = count(2) while True: p = next(nums) yield p nums = ifilterfalse(divided_by(p), nums) Thank you that's nicer, It may be nice, but is probably less efficient because of the lambda function calls that replace the if expression in your def exclude_multiples(n, ints): for i in ints: if (i % n) != 0: yield i but ifiilterfalse is not in Python 3 (could use filter of course). ifilterfalse() isn't gone in Python3, it just was renamed to filterfalse(). -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review
Thank you that's nicer, but ifiilterfalse is not in Python 3 (could use filter of course). It was renamed to filterfalse - http://docs.python.org/3.3/library/itertools.html#itertools.filterfalse -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review
Thanks everyone for your feedback. The talk I think went well, maybe I was too fast because I only used 21 minutes. From the audience feedback, there were some questions about my Buggy code example, so yes probably it's not a good example since it's too artificial. I'll have to find something more useful about that or just skip this maybe. For possible generators drawbacks though I could add maintanability, if you start passing generators around in 3-4 nested levels finding out what is the original source of can be difficult. I'm also still not convinced by the definitions, which I tried now to make clear and ay something like: - and iterator defines *how you iterate* over an object (with the __next__ method) - an iterable defines *if you can iterate* over an object (with the __iter__ method) And when I do something like this: class GenIterable: def __init__(self, start=0): self.even = start if is_even(start) else start + 1 def __iter__(self): return self def __next__(self): tmp = self.even self.even += 2 return tmp it basically means that the a GenIterable object is iterable (because of __iter__) and the way you iterate over it is to call the next method on the object itself (since we return self and we define __next__). That seems clear enough, what do you think? I might give this talk again so feedback is still appreciated! -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review
On 2/2/2014 5:40 AM, andrea crotti wrote: 2014-02-02 Terry Reedy tjre...@udel.edu: On 2/1/2014 9:12 AM, andrea crotti wrote: Comments: The use is assert in the first slide seem bad in a couple of different respects. Why is it bad? It's probably not necessary but since we ask for a range it might be good to check if the range is valid. Maybe I should raise ValueError instead for a better exception? In general, use assert (== AssertionError) to check program logic (should never raise). Remember that assert can be optimized away. Use other exceptions to check user behavior. So I believe that ValueError is appropriate here. I think I also questioned the particular check. The use of 'gen_even' before it is defined. Well this is because l'm saying that I wish I had something like this, which I define just after. It might be confusing if it's not defined but I thought it's nice to say what I would like to do and then actually define it, what do you think? In commenting on the slides, I did not know what you would say to supplement them. A generator expression evaluates (better than 'yields') to a generator, not just an iterator. Ok thanks fixed The definition of 'generator' copies the wrong and confused glossary entry. Generator functions return generators, which are iterators with extra behavior. I understood instead that it was the opposite, a generator is a specialized iterator, 'Generator functions', which you labeled 'generators', are functions, not iterators. The generators they return (and the generators that generator expressions evaluate to) are iterators, and more. type(a for a in 'abc') class 'generator' I am not sure whether 'specialized' or 'generalized' is the better term. I would leave out For loop(2). The old pseudo-getitem iterator protocol is seldom explicitly used any more, in the say you showed. /say/way/ This was mainly to explain how something like for el in [1, 2, 3]: print(el) can work, But it is no longer has that *does* work. All the builtin xyz collection classes have a corresponding xyz_iterator class with a __next__ method that knows how to sequentially access collection items. We do not normally see or think about them, but they are there working for us every time we do 'for item in xyz_instance:' [].__iter__() list_iterator object at 0x035096A0 In Python one could write the following: class list_iterator: def __init__(self, baselist): self.baselist = baselist self.index = -1 # see __next__ for why def __iter__(self): return self def __next__(self): self.index += 1 return self.baselist[self.index] but the C version should use a static pointer into the object address array, 'Lazyness drawbacks' overflow_list is bizarre and useless. overflow_gen is bizarre and buggy. If you are intentionally writing buggy code to make a point, label it as such on the slide. Yes this is intentionally buggy. The thing is that I wanted to show that sometimes generating things makes it harder to debug, and delays some errors, which are anyway there but would come up immediately in case of a list creation. I could not find a better non artificial example for this, any suggestion is welcome.. slide 1 - def recip_list(start, stop): lis [] for i range(start, stop): list.append(1/i) return lis for x in recip_list(-100, 3): # fail here print x immediate traceback that include the for line slide 2 --- def recip_gen(start, stop): for i in range(start, stop): yield 1/i for x in recip_gen(-100, 3): print x # fail here after printing 100 lines ... delayed traceback that omits for line with args that caused problem -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
generator slides review
I'm giving a talk tomorrow @Fosdem about generators/iterators/iterables.. The slides are here (forgive the strange Chinese characters): https://dl.dropboxusercontent.com/u/3183120/talks/generators/index.html#3 and the code I'm using is: https://github.com/AndreaCrotti/generators/blob/master/code/generators.py and the tests: https://github.com/AndreaCrotti/generators/blob/master/code/test_generators.py If anyone has any feedback or want to point out I'm saying something stupid I'd love to hear it before tomorrow (or also later I might give this talk again). Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review
On Saturday, February 1, 2014 6:12:28 AM UTC-8, andrea crotti wrote: I'm giving a talk tomorrow @Fosdem about generators/iterators/iterables.. The slides are here (forgive the strange Chinese characters): https://dl.dropboxusercontent.com/u/3183120/talks/generators/index.html#3 and the code I'm using is: https://github.com/AndreaCrotti/generators/blob/master/code/generators.py and the tests: https://github.com/AndreaCrotti/generators/blob/master/code/test_generators.py If anyone has any feedback or want to point out I'm saying something stupid I'd love to hear it before tomorrow (or also later I might give this talk again). Thanks My 2 cents: slide 4: [i*2 for i in range(10)] slide 9: while True: try: it = next(g) body(it) except StopIteration: break slide 21: from itertools import count, ifilterfalse def divided_by(p): return lambda n: n % p == 0 def primes(): nums = count(2) while True: p = next(nums) yield p nums = ifilterfalse(divided_by(p), nums) Another resource you can point to is http://www.dabeaz.com/generators/ Good luck. -- https://mail.python.org/mailman/listinfo/python-list
Re: generator slides review
On 2/1/2014 9:12 AM, andrea crotti wrote: I'm giving a talk tomorrow @Fosdem about generators/iterators/iterables.. The slides are here (forgive the strange Chinese characters): https://dl.dropboxusercontent.com/u/3183120/talks/generators/index.html#3 and the code I'm using is: https://github.com/AndreaCrotti/generators/blob/master/code/generators.py and the tests: https://github.com/AndreaCrotti/generators/blob/master/code/test_generators.py If anyone has any feedback or want to point out I'm saying something stupid I'd love to hear it before tomorrow (or also later I might give this talk again). Comments: The use is assert in the first slide seem bad in a couple of different respects. The use of 'gen_even' before it is defined. A generator expression evaluates (better than 'yields') to a generator, not just an iterator. The definition of 'generator' copies the wrong and confused glossary entry. Generator functions return generators, which are iterators with extra behavior. I would leave out For loop(2). The old pseudo-getitem iterator protocol is seldom explicitly used any more, in the say you showed. In 'Even numbers', I have no idea what the complication of next_even() is about. 'Lazyness drawbacks' overflow_list is bizarre and useless. overflow_gen is bizarre and buggy. If you are intentionally writing buggy code to make a point, label it as such on the slide. Iterators just produce values. Generators can consume as well as produce values, which is why they can act as both iterators and coroutines. @monocle -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
