Re: Extract the space group generators from Bilbao Crystallographic Server.

tack and numpy.hstack with proper care with > multiple dimensions to specify what axis they will combine on. > > But doing the full (home)work for you is ... Thank you for your analysis and comments. Best, Zhao > -Original Message- > From: Python-list On > Behalf Of

RE: Extract the space group generators from Bilbao Crystallographic Server.

.@gmail.com Cc: Python List Subject: Re: Extract the space group generators from Bilbao Crystallographic Server. It's good to include what you want to see as output, but it's important to also include what you have as input. It's also good to include what you've coded so far.

Re: Extract the space group generators from Bilbao Crystallographic Server.

It's good to include what you want to see as output, but it's important to also include what you have as input. It's also good to include what you've coded so far. It's considered good etiquette to give it a try yourself before asking the list. On Thu, Jul 14, 2022 at 1:03 PM hongy...@gmail.com

Extract the space group generators from Bilbao Crystallographic Server.

I'm trying to extract the matrix data of "ITA-Setting F d -3 m [origin 1]" listed here [1], and then building an augmented matrix for each of them by adding the last row as "[0, 0, 0, 1]". In short, the following form is the ultimate-desired result: [[[1, 0, 0, 0], [0, 1, 0, 0], [0, 0,1, 0], [

Re: Reducing "yield from" overhead in recursive generators

On 23/03/22 11:44 am, Rathmann wrote: So that sounds like the original CPython implementation had an O(depth) component, but with a lower constant factor than the current version? Yes, but so much lower that I would expect it to be unmeasurable. -- Greg -- https://mail.python.org/mailman/list

Re: Reducing "yield from" overhead in recursive generators

on. > This was evidently seen as more important than having efficient > resumption of nested generators. So that sounds like the original CPython implementation had an O(depth) component, but with a lower constant factor than the current version? (Of course, since Python limits recursion

Re: Reducing "yield from" overhead in recursive generators

ception. > This was evidently seen as more important than having efficient > resumption of nested generators. I would have thought that it would be possible to do both sets of pointer/accounting. One that supports your original fast implementation and add to that the info to do the trace bac

Re: Reducing "yield from" overhead in recursive generators

tion. > This was evidently seen as more important than having efficient > resumption of nested generators. > > I'm not sure exactly how it works now, but I believe it involves > re-executing the YIELD_FROM bytecode in each generator down the > chain whenever a resumption occurs.

Re: Reducing "yield from" overhead in recursive generators

t just ran down a chain of C pointers to find the currently active one. At some point this was changed, I think so that all the frames would show up in the traceback in the event of an exception. This was evidently seen as more important than having efficient resumption of nested generators. I&

Re: Reducing "yield from" overhead in recursive generators

wn (and I just missed it.) > > C) Potentially useful for the niche case of deeply recursive > > generators? > I would go with B' + C. It seems there is a resemblance with the trampoline > technique > in order to eliminate tail recursion. I know the people of macropy have > wri

Re: Reducing "yield from" overhead in recursive generators

Op 18/03/2022 om 04:14 schreef Rathmann: ... ```python def recursive_generator_driver(g): """g is a generator object, which is likely to call other generators""" stack = [g] while True: g = stack[-1] try: val = next(g)

Reducing "yield from" overhead in recursive generators

Summary: I am looking for feedback on a potential technique for coding recursive generators. Often times the most convenient algorithms for creating a sequence of results are recursive, while the most convenient interface for the consumption of those results is an iterator. PEP 380 introduced

Re: Fun Generators

ve a couple points where I might do some "fun > things" with python. Said students have been learning some python3. > >> I'm soliciting any *fun* generators people may have seen or written? > Not so much the cool or clever ones. Or the mathematical ones (e.g. f

Re: Fun Generators

>> with python. Said students have been learning some python3. >> I'm soliciting any *fun* generators people may have seen or written? Not so >> much the cool or clever ones. Or the mathematical ones (e.g. fib). Something >> more inane and "fun". But still show

Re: Fun Generators

On 2021-04-23 7:34 AM, Travis Griggs wrote: Doing an "industry experience" talk to an incoming class at nearby university tomorrow. Have a couple points where I might do some "fun things" with python. Said students have been learning some python3. I'm soliciting an

Fun Generators

Doing an "industry experience" talk to an incoming class at nearby university tomorrow. Have a couple points where I might do some "fun things" with python. Said students have been learning some python3. I'm soliciting any *fun* generators people may have seen or writt

Re: Question about generators

On 2021-03-06 8:21 AM, Frank Millman wrote: Hi all This is purely academic, but I would like to understand the following - >>> >>> a = [('x', 'y')] >>> >>> s = [] >>> for b, c in a: ...   s.append((b, c)) ... >>> s [('x', 'y')] This is what I expected. >>> >>> s = [] >>> s.append(((

Re: Question about generators

On Sat, Mar 06, 2021 at 08:21:47AM +0200, Frank Millman wrote: > [...] > I understand the concept that a generator does not return a value until you > call next() on it, but I have not grasped the essential difference between > the above two constructions. > > TIA for any insights. > > Frank Mill

Re: Question about generators

tween append and extend. I suspect that the heart of your confusion actually has nothing to do with generators. -- Alan Bawden -- https://mail.python.org/mailman/listinfo/python-list

Question about generators

Hi all This is purely academic, but I would like to understand the following - >>> >>> a = [('x', 'y')] >>> >>> s = [] >>> for b, c in a: ... s.append((b, c)) ... >>> s [('x', 'y')] This is what I expected. >>> >>> s = [] >>> s.append(((b, c) for b, c in a)) >>> s [ at 0x019FC3F863C0>]

Re: Asynchronous generators

Jonathan Gossage wrote at 2020-6-23 14:04 -0400: >-- >I am attempting to learn how to use asyncio and I have been unable to find >any documentation or Internet posts that give information on the principles >underlying asyncio ... I am almost sure to have read an asyncio tutorial found via "python.

Re: Asynchronous generators

e: > -- > I am attempting to learn how to use asyncio and I have been unable to find > any documentation or Internet posts that give information on the principles > underlying asyncio, let alone any examples showing how asynchronous > generators should be used. I have built a toy prog

Asynchronous generators

-- I am attempting to learn how to use asyncio and I have been unable to find any documentation or Internet posts that give information on the principles underlying asyncio, let alone any examples showing how asynchronous generators should be used. I have built a toy program to test trying to

Re: Using generators in Django

se records > doing some calculation and storing the processed data in some other > database. The skeleton code looks like this > > > I need to know whether the use of generators is correct here, in the sense > that would it have any performance issues. The point that I am having >

Using generators in Django

, **kwargs): project = (args[0], args[1]) project_id = MyProject.filter(...).id for need in fetch_needs(project_id): ``` I need to know whether the use of generators is correct here, in the sense that would it have any performance issues. The point that I am

RE: dealing with infinite generators

that are effectively somewhat hidden loops. A list comprehension is a hidden loop as are its cousins like a dictionary comprehension and of course generators in general. But unlike explicit loops, these constructs may not easily allow you to specify additional code. Yes, you probably can using

dealing with infinite generators

[SPECULATION ALERT] I found it interesting as people discussed how one gets the length of something set up to follow the iterator protocol and especially anything that is effectively infinite. It is possible in python to set a value of "inf" using methods like this: >>> x = float("inf") >>> x i

Re: Generators, generator expressions, and loops

Steve, On 17/11/18 03:52, Steve Keller wrote: I have looked at generators, generator expressions, and iterators and I try to get more familiar with these. 1. How would I loop over all (with no upper bound) integers or all powers of two, for example? In C it would be for (int i = 0; ; i

Re: Re: Generators, generator expressions, and loops

Lovely, succinct answers. On 17/11/2018 2:44 AM, Ian Kelly wrote: On Fri, Nov 16, 2018 at 7:57 AM Steve Keller wrote: I have looked at generators, generator expressions, and iterators and I try to get more familiar with these. 1. How would I loop over all (with no upper bound) integers or

Re: Generators, generator expressions, and loops

> On 16 Nov 2018, at 14:54, Steve Keller wrote: > More elegant are generator expressions but I cannot think of a way > without giving an upper limit: > >for i in (2 ** i for i in range(100)): >... > > which looks ugly. Also, the double for-loop (and also the two loops > in the

Re: Generators, generator expressions, and loops

Try itertools.count() . On Fri, Nov 16, 2018 at 12:08 PM Steve Keller wrote: > Cancel ill-formated article > -- > https://mail.python.org/mailman/listinfo/python-list > -- Santiago Basulto.- Co-founder @ rmotr.com -- https://m

Re: Generators, generator expressions, and loops

On Fri, Nov 16, 2018 at 7:57 AM Steve Keller wrote: > > I have looked at generators, generator expressions, and iterators and > I try to get more familiar with these. > > 1. How would I loop over all (with no upper bound) integers or all > powers of two, for example? &g

Generators, generator expressions, and loops

Cancel ill-formated article -- https://mail.python.org/mailman/listinfo/python-list

Generators, generator expressions, and loops

I have looked at generators, generator expressions, and iterators and I try to get more familiar with these. 1. How would I loop over all (with no upper bound) integers or all powers of two, for example? In C it would be for (int i = 0; ; i++) { ... } or for (int i = 1; ; i *= 2

Generators, generator expressions, and loops

I have looked at generators, generator expressions, and iterators and I try to get more familiar with these. 1. How would I loop over all (with no upper bound) integers or all powers of two, for example? In C it would be for (int i = 0; ; i++) { ... } or for (int i = 1; ; i *= 2

So assignment expressions in generators…

Self correction: assignment expressions in generator comprehensions inside a function body. -- https://mail.python.org/mailman/listinfo/python-list

So assignment expressions in generators…

…will normally issue STORE_DEREF opcodes for the assignment? This is what I understand from reading PEP-572, just wanted to ask whether I got it right. Example of what I'm referring to: def f(): return ( (s := x*x) for x in range(5)) -- https://mail.python.org/mailman/listinfo/python-list

Re: Garbage collection problem with generators

t; > >> This is reproducible with python2.7, but not in python3.5. I've also > tried > >> with `thread` instead of `gevent`, it still happens. I'm guessing it's > >> related to garbage collection of generators. > >> > >> Did I bump into a pyt

Re: Garbage collection problem with generators

th python2.7, but not in python3.5. I've also tried >> with `thread` instead of `gevent`, it still happens. I'm guessing it's >> related to garbage collection of generators. >> >> Did I bump into a python2 bug? Or am I simply wrong about the way to close >> g

Re: Garbage collection problem with generators

time.sleep(10) > ``` > > When I deliberately times out the request and then check the connections > with `lsof -p process`, I discover that there are *two active > connections*(ESTABLISH) > instead of one. After digging around, it turns out it might not be the > problem wit

Garbage collection problem with generators

be the problem with `requests` at all, but gc related to generators. So I write this script to demonstrate the problem: https://gist.github.com/wooparadog/766f8007d4ef1227f283f1b040f102ef Function `A.a` will return a generator which will raise an exception. And in function `b`, I'm building

Re: PonyORM: generators as a query syntax

On 12/08/2016 07:26 AM, Alex Kaye wrote: > Can you describe some uses or example for using ORM for a Newbie ? Simply put, ORM is a method for making objects that represent records in a database. It's usually done in such a way that the objects are "live." In other words if the object has an attr

PonyORM: generators as a query syntax

I was just made aware of a very interesting ORM project that has been around since about 2013, while listening to a recent episode of the Talk Python To Me podcast. The idea of using generators to build queries is really cool. I'm sure PonyORM has its limitations and drawbacks, as all ORM m

Re: Why generators take long time?

On Tue, 19 Jan 2016 09:24 pm, Oscar Benjamin wrote: > On 19 Jan 2016 10:16, "Steven D'Aprano" wrote: >> >> [steve@ando ~]$ python -m timeit -s "from collections import deque" >> -s "it = iter([i for i in xrange(1000)])" "deque(it, maxlen=0)" >> 100 loops, best of 3: 0.913 usec per loop >>

Re: Why generators take long time?

On Tue, Jan 19, 2016 at 3:19 PM, Jason Swails wrote: > > I use generator expressions when > > - I *might* want to > ​I forgot to finish my thought here. I use generator expressions when I don't want to worry about memory, there's a decent chance of short-circuiting​, or I just want to do some s

Re: Why generators take long time?

On Tue, Jan 19, 2016 at 2:27 AM, Arshpreet Singh wrote: > > I was playing with Generators and found that using Generators time is bit > more than list-comprehensions or I am doing it wrong? > > > Function with List comprehensions: > > def sum_text(number_range): >

Re: Why generators take long time?

On Tuesday, 19 January 2016 15:42:16 UTC+5:30, Steven D'Aprano wrote: > [steve@ando ~]$ python -m timeit -s "from collections import deque" > -s "it = iter([i for i in xrange(1000)])" "deque(it, maxlen=0)" > 100 loops, best of 3: 0.913 usec per loop > > > [steve@ando ~]$ python -m tim

Re: Why generators take long time?

On 19 Jan 2016 10:16, "Steven D'Aprano" wrote: > > [steve@ando ~]$ python -m timeit -s "from collections import deque" > -s "it = iter([i for i in xrange(1000)])" "deque(it, maxlen=0)" > 100 loops, best of 3: 0.913 usec per loop > > > [steve@ando ~]$ python -m timeit -s "from collections i

Re: Why generators take long time?

On Tue, 19 Jan 2016 06:27 pm, Arshpreet Singh wrote: > > I was playing with Generators and found that using Generators time is bit > more than list-comprehensions or I am doing it wrong? Generators may have slightly more overhead than iterating over a list. They save memory, not tim

Re: Why generators take long time?

On Tuesday, 19 January 2016 12:58:28 UTC+5:30, Arshpreet Singh wrote: > I was playing with Generators and found that using Generators time is bit > more than list-comprehensions or I am doing it wrong? > > > Function with List comprehensions: > > def sum_text(number_ran

Why generators take long time?

I was playing with Generators and found that using Generators time is bit more than list-comprehensions or I am doing it wrong? Function with List comprehensions: def sum_text(number_range): return sum([i*i for i in xrange(number_range)]) %timeit sum_text(1) 1 loops, best of 3

Re: list slice and generators

't >> know if there will be a problem with doing in place replace of list >> elements using 2 generators. >> >> # metrics = ['', '0', '10'] >> metrics = [x.metric(name) for x in self._server_per_proc] >> metrics[:] = (conve

Re: list slice and generators

Ian Kelly wrote: > On Wed, Nov 25, 2015 at 10:44 AM, Ian Kelly wrote: >> On Wed, Nov 25, 2015 at 3:07 AM, Peter Otten <__pete...@web.de> wrote: elif name in METRICS_AVG: >>> # writing a function that calculates the average without >>> # materialising the list left as

Re: list slice and generators

Ian Kelly wrote: >>assert metrics > > metrics is always going to be an itertools.chain object at this > assert, so how could the assertion ever fail? Should an assertion ever fail? >From your reaction I conclude that it was puzzling and a comment like # always true in a boolean context would

Re: list slice and generators

On Wed, Nov 25, 2015 at 10:44 AM, Ian Kelly wrote: > On Wed, Nov 25, 2015 at 3:07 AM, Peter Otten <__pete...@web.de> wrote: >>> elif name in METRICS_AVG: >> # writing a function that calculates the average without >> # materialising the list left as an exercise ;) > >

Re: list slice and generators

On Wed, Nov 25, 2015 at 3:07 AM, Peter Otten <__pete...@web.de> wrote: > to get down to one intermediate list. Avoiding the last one is a bit tricky: > > metrics = (converter(x.metric(name)) for x in self._server_per_proc) > metrics = (x for x in metrics if x is not None) > try: > # if there is

Re: list slice and generators

of list > elements using 2 generators. > > # metrics = ['', '0', '10'] > metrics = [x.metric(name) for x in self._server_per_proc] > metrics[:] = (converter(x) for x in metrics) > metrics[:] = (x for x in metrics if x is not None) Both generators ar

list slice and generators

Hi, Do you see any possible dangerous hidden bug in the below code(using python2.7 and python3.4)? My goal is to avoid go through the metrics list twice. But, I don't know if there will be a problem with doing in place replace of list elements using 2 generators. # metrics = ['&

Re: Doubt on generators behavior

On 10/13/2013 4:19 AM, Krishnan Shankar wrote: Hi Friends, I am new to Generators and was learning the same by experimenting. I wrote a small code which is as below. >>> def test_gen(var): ... print "The number is", var ... if var % 2 == 0: ... yie

Re: Doubt on generators behavior

On Sun, 13 Oct 2013 13:49:53 +0530, Krishnan Shankar wrote: > Hi Friends, > > I am new to Generators and was learning the same by experimenting. I > wrote a small code which is as below. > >>>> def test_gen(var): > ... print "The number

Re: Doubt on generators behavior

Krishnan Shankar writes: > Hi Friends, > > I am new to Generators and was learning the same by experimenting. I > wrote a small code which is as below. > > >>> def test_gen(var): > ... print "The number is", var > ... if var % 2 =

Doubt on generators behavior

Hi Friends, I am new to Generators and was learning the same by experimenting. I wrote a small code which is as below. >>> def test_gen(var): ... print "The number is", var ... if var % 2 == 0: ... yield var ... else: ... print "Number is odd&

Re: Slicing iterables in sub-generators without loosing elements

On Tuesday, 2 October 2012 22:13:20 UTC+5:30, Mark Lawrence wrote: > On 02/10/2012 17:12, Ramchandra Apte wrote: > > > On Monday, 1 October 2012 13:47:50 UTC+5:30, Mark Lawrence wrote: > > >> On 01/10/2012 01:58, 8 Dihedral wrote: > > >> > > >>> > > >> > > >>> Your question seems vague

Re: Slicing iterables in sub-generators without loosing elements

y confound us, the > > >> occasional human response would probably muddy the waters sufficiently. > > > > > Are you still not getting the generator part in Python? Do you really > > > test any generator before? > > > > I rest my case :) > &

Re: Slicing iterables in sub-generators without loosing elements

on? Do you really > test any generator before? I rest my case :) I have many problems with generators. Can you tell me more about them? I really need your help. Sometimes, when it is very cold, the diesel freezes and the generator raises StopIteration at the wrong place. -- Steven -- http://mail.python.org/mailman/listinfo/python-list

Re: Slicing iterables in sub-generators without loosing elements

Steven D'Aprano於 2012年10月3日星期三UTC+8上午8時57分20秒寫道： > On Wed, 03 Oct 2012 03:58:02 +1000, Chris Angelico wrote: > > > > > Dihedral might be a bot and might not. I've come to the conclusion that > > > it's not worth trying to find out, given that a good bot can outdo a lot > > > of humans in usefu

Re: Slicing iterables in sub-generators without loosing elements

On Monday, October 1, 2012 4:17:50 PM UTC+8, Mark Lawrence wrote: > On 01/10/2012 01:58, 8 Dihedral wrote: > > > > > > Your question seems vague to me. If you know you are storing > > > only immutable tuples in a list, then the way to iterate is simple. > > > > > > > Does Python have a m

Re: Slicing iterables in sub-generators without loosing elements

On 10/2/2012 1:58 PM, Chris Angelico wrote: On Wed, Oct 3, 2012 at 2:44 AM, Mark Lawrence wrote: What happened to freedom of speech? If I want to talk to a bot, I'll talk to a bot. Besides I'm not convinced it/he/she is a bot. Plus if you read my post carefully, add in several years experien

Re: Slicing iterables in sub-generators without loosing elements

On 02/10/2012 18:58, Chris Angelico wrote: Dihedral might be a bot and might not. I've come to the conclusion that it's not worth trying to find out, given that a good bot can outdo a lot of humans in useful conversation. ChrisA Try telling that to the newbies on the Python tutor mailing lis

Re: Slicing iterables in sub-generators without loosing elements

On Wed, Oct 3, 2012 at 2:44 AM, Mark Lawrence wrote: > What happened to freedom of speech? If I want to talk to a bot, I'll talk > to a bot. Besides I'm not convinced it/he/she is a bot. Plus if you read > my post carefully, add in several years experience of Python the language > and Python th

Re: Slicing iterables in sub-generators without loosing elements

On 02/10/2012 17:12, Ramchandra Apte wrote: On Monday, 1 October 2012 13:47:50 UTC+5:30, Mark Lawrence wrote: On 01/10/2012 01:58, 8 Dihedral wrote: Your question seems vague to me. If you know you are storing only immutable tuples in a list, then the way to iterate is simple.

Re: Slicing iterables in sub-generators without loosing elements

On Monday, 1 October 2012 13:47:50 UTC+5:30, Mark Lawrence wrote: > On 01/10/2012 01:58, 8 Dihedral wrote: > > > > > > Your question seems vague to me. If you know you are storing > > > only immutable tuples in a list, then the way to iterate is simple. > > > > > > > Does Python have a

Re: Slicing iterables in sub-generators without loosing elements

On 1 October 2012 09:19, Mark Lawrence wrote: > On 01/10/2012 01:58, 8 Dihedral wrote: > >> >> Your question seems vague to me. If you know you are storing >> only immutable tuples in a list, then the way to iterate is simple. >> >> > Does Python have a magic method that let's me use mutable

Re: Slicing iterables in sub-generators without loosing elements

On 01/10/2012 01:58, 8 Dihedral wrote: Your question seems vague to me. If you know you are storing only immutable tuples in a list, then the way to iterate is simple. Does Python have a magic method that let's me use mutable tuples? I'd also like immutable lists. Is it worth raising a

Re: Slicing iterables in sub-generators without loosing elements

On Sunday, September 30, 2012 12:15:57 AM UTC+8, Thomas Bach wrote: > Hi, > > > > say we have the following: > > > > >>> data = [('foo', 1), ('foo', 2), ('bar', 3), ('bar', 2)] > > > > is there a way to code a function iter_in_blocks such that > > > > >>> result = [ list(block) for bloc

Re: Slicing iterables in sub-generators without loosing elements

On Sat, Sep 29, 2012 at 09:26:00AM -0700, Paul Rubin wrote: > Thomas Bach writes: > > itertools.groupby(data, lambda (x,y) : x) > > is basically what you want. True! Thanks, Thomas Bach -- http://mail.python.org/mailman/listinfo/python-list

Re: Slicing iterables in sub-generators without loosing elements

On Sat, Sep 29, 2012 at 10:14 AM, Thomas Bach wrote: > Hi, > > say we have the following: > data = [('foo', 1), ('foo', 2), ('bar', 3), ('bar', 2)] > > is there a way to code a function iter_in_blocks such that > result = [ list(block) for block in iter_in_blocks(data) ] > > evaluates to

Re: Slicing iterables in sub-generators without loosing elements

Thomas Bach writes: result = [ [('foo', 1), ('foo', 2)], [('bar', 3), ('bar', 2)] ] > by _only_ _iterating_ over the list (caching all the elements sharing > the same first element doesn't count)? itertools.groupby(data, lambda (x,y) : x) is basically what you want. -- http://mail.python.o

Slicing iterables in sub-generators without loosing elements

Hi, say we have the following: >>> data = [('foo', 1), ('foo', 2), ('bar', 3), ('bar', 2)] is there a way to code a function iter_in_blocks such that >>> result = [ list(block) for block in iter_in_blocks(data) ] evaluates to >>> result = [ [('foo', 1), ('foo', 2)], [('bar', 3), ('bar', 2)] ]

Re: generators as decorators simple issue

On Wed, Sep 12, 2012 at 4:22 AM, pyjoshsys wrote: > The output is still not what I want. Now runtime error free, however the > output is not what I desire. [SNIP] > class Trial(object): > '''class to demonstrate with''' > def __init__(self): > object.__init__(self) > sel

Re: generators as decorators simple issue

so decorators only pass the object and not any instance of the object as the implied argument? Is this right? The idea was to use @setname instead of instance.SetName(instance.__name__). I thought decorators would do this, but it seems not. -- http://mail.python.org/mailman/listinfo/pyth

Re: generators as decorators simple issue

On Wed, 12 Sep 2012 03:22:31 -0700 (PDT), pyjoshsys wrote: The output is still not what I want. Now runtime error free, however the output is not what I desire. def setname(cls): '''this is the proposed generator to call SetName on the object''' try: cls.SetName(cls.__name

Re: generators as decorators simple issue

The output is still not what I want. Now runtime error free, however the output is not what I desire. def setname(cls): '''this is the proposed generator to call SetName on the object''' try: cls.SetName(cls.__name__) except Exception as e: print e finally:

Re: generators as decorators simple issue

Am 12.09.2012 04:28 schrieb j.m.dagenh...@gmail.com: I'm trying to call SetName on an object to prevent me from ever having to call it explictly again on that object. Best explained by example. def setname(cls): '''this is the proposed generator to call SetName on the object''' try:

Re: generators as decorators simple issue

On Sep 12, 12:28 pm, j.m.dagenh...@gmail.com wrote: > def setname(cls): >     '''this is the proposed generator to call SetName on the object''' >     try: >         cls.SetName(cls.__name__) >     finally: >         yield cls A generator is (basically) a callable that acts like an iterator. You'd

Re: generators as decorators simple issue

On Wednesday, 12 September 2012 07:58:10 UTC+5:30, pyjoshsys wrote: > I'm trying to call SetName on an object to prevent me from ever having to > call it explictly again on that object. Best explained by example. > [snip] In your decorator, you are using `yield cls` - it should be `return cls` 99

generators as decorators simple issue

I'm trying to call SetName on an object to prevent me from ever having to call it explictly again on that object. Best explained by example. def setname(cls): '''this is the proposed generator to call SetName on the object''' try: cls.SetName(cls.__name__) finally: yi

Re: Fast recursive generators?

I am thinking the bye code compiler in python can be faster if all known immutable instances up to the executionare compiled immutable objects to be assigned. -- http://mail.python.org/mailman/listinfo/python-list

Re: Fast recursive generators?

En Fri, 28 Oct 2011 15:10:14 -0300, Michael McGlothlin escribió: I'm trying to generate a list of values where each value is dependent on the previous value in the list and this bit of code needs to be repeatedly so I'd like it to be fast. It doesn't seem that comprehensions will work as each

Re: Fast recursive generators?

ot;l = list(do(f,N,x))", but if you do not, you can do "for item in do(f,N,x):" and skip making the list. Generators seem considerably slower than using comprehension or map/filter So what? A saw may cut faster than a hammer builds, but I hope you don't grab a saw when you need

Re: Fast recursive generators?

alue) >        yield value > > ? > For more generality, make func a function of both value and i. > If you need a list, "l = list(do(f,N,x))", but if you do not, you can do > "for item in do(f,N,x):" and skip making the list. Generators seem considerably slower

Re: Fast recursive generators?

On 10/28/2011 2:10 PM, Michael McGlothlin wrote: I'm trying to generate a list of values Better to think of a sequence of values, whether materialized as a 'list' or not. where each value is dependent on the previous value in the list and this bit of code needs to be repeatedly so I'd like

Fast recursive generators?

I'm trying to generate a list of values where each value is dependent on the previous value in the list and this bit of code needs to be repeatedly so I'd like it to be fast. It doesn't seem that comprehensions will work as each pass needs to take the result of the previous pass as it's argument. m

Re: Closing generators

__iter__ and __next__) with lots of other methods. Oh, ok. I never thought about it in that way - and it is not exactly the same: a file object already has its __enter__ and __exit__ methods which serves to avoid using closing(), while a generator object misses them. But thanks for point

Re: Closing generators

On 4/22/2011 4:01 AM, Thomas Rachel wrote: Am 22.04.2011 09:01, schrieb Wolfgang Rohdewald: On Freitag 22 April 2011, Terry Reedy wrote: When returning from the function, g, if local, should disappear. yes - it disappears in the sense that it no longer accessible, but AFAIK python makes n

Re: Closing generators

Am 22.04.2011 09:01, schrieb Wolfgang Rohdewald: On Freitag 22 April 2011, Terry Reedy wrote: When returning from the function, g, if local, should disappear. yes - it disappears in the sense that it no longer accessible, but AFAIK python makes no guarantees as for when an object is destro

Re: Closing generators

On Freitag 22 April 2011, Terry Reedy wrote: > > for i in g: > > if i is not None: > > g.close() > > return i > > When returning from the function, g, if local, should > disappear. yes - it disappears in the sense that it no longer accessible, but AFAIK python makes no guarantees as for when an

Re: Closing generators

On 4/21/2011 9:14 PM, Thomas Rachel wrote: Hi folks, it is possible to close a generator. That is (among others) for the following case: I run a for loop over the iterator, but then I break it. Now I can leave the generator to the GC (which is AFAI have been told a thing which I should not do),

Closing generators

Hi folks, it is possible to close a generator. That is (among others) for the following case: I run a for loop over the iterator, but then I break it. Now I can leave the generator to the GC (which is AFAI have been told a thing which I should not do), or I can clean up myself. Example: f

Re: Generators and propagation of exceptions

On Apr 8, 3:47 pm, r wrote: > I'm already making something like this (that is, if I understand you > correctly). In the example below (an "almost" real code this time, I > made too many mistakes before) all the Expressions (including the > Error one) implement an 'eval' method that gets called by

  1   2   3   4   5   6   7   8   >